Step 4 - Qualification

You need to learn to walk away from most opportunities

The headline says it all. Just because you COULD do it, doesn’t mean you should. Why? Because everyone else who COULD do it is your competitor on that opportunity, and the first one that went in with a solid USP will kick your ass, every time.

Whilst there are no hard and fast rules to successful qualifications – a lot of it is down to pure experience and gut feeling – there are a few top tips you can take onboard to make sure you’re giving yourself the best chance with every opportunity you keep on the list.

1. Be brutal

If an opportunity doesn’t fit all of your USPs, strongly consider canning it. If you don’t have any USPs, definitely can it. If you don’t like the deadline, or the way they want you to respond, then can it. If you keep it on the list, even if you’ve started your response, and your situation changes, can it.

Unless you have the time to give it, and it meets all of your requirements for being a good opportunity, get rid.

2. Use your proposition to help you

When trying to decide if an opportunity is good for you, your proposition is a key tool to use. Forget that generic elements of a tender requirement that you could definitely do, what you’re looking for are the more specific needs that your product or service can obviously solve in a novel and intuitive way.

Any tenders that make your proposition glow with excitement go onto the maybe pile. Anything else, even if you could do it, gets binned.

3. Never be afraid to walk away. Ever.

No matter how much time you’ve spent on an opportunity, you never stop qualifying it. It might sometimes take you hours to figure out that what you thought was a solid solution to their needs is actually much more commonplace, or not that big a deal for them. Maybe the client sent out some clarifications that completely changed the face of your proposal.

No matter what it is, or how much time it’s swallowed up, unless it’s already basically finished of course, just walk away.

4. Ask questions if you’re unsure

There are definitely no stupid questions (unless the answer is very obviously in the documentation, but the client will still tell you the answer if asked). If you’re unsure of anything, especially if it might impact the quality of your response, then ask it.

You’ll usually see a lot of the same questions being asked immediately, such as:

  • What’s the budget for this project
  • Are the incumbent suppliers bidding, and if not, why not?
  • You mentioned you would prefer PRODUCT X, would you consider PRODUCT Y instead if we can justify the change to you?
  • Can we send through a written proposal as well as answering your pre-defined questions?
  • Do you want all the answers to be in the form provided, or can we break them out into a separate document to make it easier to read?

The list will go on and on, and you’ll learn to recognise them. A lot of them are there to help a supplier who currently fancies the project make up their mind.

For example, the budget question is useful because it lets them know if it’s worth going for, but also gives you a really good steer on what a competitive price might be.

The question around formatting of answers is good to clarify because when the tender does have a set of pre-defined questions to answer, it can often be very messy to put easy to read answers in there….yet some clients will void your submission if you don’t use their exact documents.

Suppliers questioning the preferred solution and if the client is open to alternatives is good because some clients actually don’t care, and some will only accept the solution they’ve asked for. And to be clear, I have sold my preferred solution to a client who initially asked for something else, on more than one occasion, so it’s definitely worth asking for.

Importantly, ask your questions early. It’s easy to miss the deadline with something you didn’t realise was important until it was too late, so by asking your questions well ahead of time, not only can you be sure of clarity, but you also have the opportunity to ask follow-up questions, if you need to.

5. Check the small print to make sure you qualify

Read all the documents carefully, and don’t assume that there isn’t a random one-liner somewhere in a document that completely changes the face of the project you were building in your head. It might be something that changes your solution, or something that actually means you can’t apply for the tender.

Imagine my joy once when I’d spent 2 days on a detailed proposal, only to see – in a completely random section as I was looking for the email address to submit to – a one liner saying that companies needed to have a minimum turnover of 5 million to qualify: something I’d missed up to that point.

6. Check the incumbent, and why the tender exists

For a lot of projects where it’s a continuation of an existing site, product or service, you have to ask yourself why the existing supplier isn’t going to win it. Yes, the client has to list it publicly by default, but an incumbent is always going to have a much more compelling solution to the problem, simply because they understand it in much more detail than anyone else possibly could.

So knowing if they’re bidding is important. It’s also helpful to know if this is a routine replacement, or a tender that’s been forced because of a previous contract failure.

I will state now – it’s entirely possible to beat the incumbents. I’ve done it myself multiple times. It’s just something for you to consider when bidding for work, as some services – hosting being a great example – are much harder to move to a new supplier than to simply stick with teh current one, even if it’s not been plain sailing for them to this point.

7. Check the technology / other such requirements

Tender documents are getting better all the time, with client teams putting more and more effort into creating useful briefs with real requirements and good detail around their must-haves and would-likes, however it’s still possible to find out down the line that they actually have a strong preference for a particular solution, or that their entire network of services currently in use runs on a specific stack…either of which might completely negate your solution.

If such core information is not in the brief, ask for it.

©2025 winBetter