Making a New Technology Purchase: Getting It Right Before You Commit
On a new purchase, the money is won or lost long before the final haggle. It is won or lost in how you define the requirement and how you build the shortlist. Get those right and the price almost looks after itself. Get them wrong and no amount of late negotiation will rescue the deal. Here is how to run the process so the vendor does not run it for you.
Most buyers think the negotiation is the moment at the end, when the quote lands and they push for a discount. By then the important decisions are already made. The requirement is written, the shortlist is set, the internal champion has a favourite, and the vendor knows it. The leverage you think you are about to use has quietly drained away over the previous three months, while you were being helpful and collaborative. This guide is about the part that actually decides the outcome, the early process, and how to run it with the discipline that keeps you in control.
Why the money is won before the haggle
Price is a function of competition and clarity. A vendor quotes aggressively when it believes it might genuinely lose, and quotes lazily when it believes it has already won. Everything that happens before the quote is really a contest over which of those two states the vendor is in when it prices the deal. If you arrive at the quote stage with a single viable option, a requirement written around that option, and a champion who has already said the words "we just want to get this done", you have no leverage left to spend. The haggle is theatre at that point.
The reverse is also true. If two credible vendors both believe they can win right up to the final week, you will get a sharper number from both without saying anything clever at all. So the real skill in a new purchase is not negotiation in the narrow sense. It is keeping genuine competitive tension alive, and keeping control of the requirement, all the way through.
You do not negotiate a good price at the end. You set it up at the start, by controlling the requirement and protecting real competition. The final discount is mostly a reflection of how well you did that, not how hard you pushed in the last meeting.
How vendors write themselves into your spec
A good sales team does not wait to respond to your requirement. It tries to shape the requirement so that its product is the obvious answer and the alternatives look deficient. This is not sinister, it is simply how the job works, and the better the salesperson, the earlier and more gracefully they do it. You should expect it and plan for it.
It usually takes three forms. The first is ghostwriting. A friendly vendor offers to "help you scope this out" or hands you a requirements template, a sample RFP, or an architecture diagram. It is genuinely useful, and it is also quietly built around their differentiators. By the time you publish it, you are evaluating the market against one vendor's feature list. The second is criteria seeding. The vendor pushes a particular evaluation criterion up your priority list, a specific certification, a niche integration, a performance metric, that happens to be where a rival is weak. The third is single sourcing through a champion. The vendor invests heavily in one internal advocate, gives them early access, makes them look good to their boss, and lets that person carry the deal internally so that by the time procurement is involved the decision is emotionally already made.
If a draft requirement contains an oddly specific feature, a named integration, or a performance threshold that nobody internally can quite explain the origin of, ask where it came from. Specifics that no one owns are usually a vendor's fingerprints, placed there to disqualify a rival.
Define the requirement before the vendor does
The single most valuable thing you can do is write the requirement from the business problem, not from any product. Describe the outcome you need, the constraints you genuinely have, and the things that would make a solution fail in your environment. Do that before you take a single sales meeting, even if it is rough. A requirement written in your own words, owned by your own people, is the thing that keeps the whole process honest.
Separate what you actually need from what is merely nice. Vendors thrive on the long wish list, because more requirements means more reasons to upsell and more cover for a higher price. Be ruthless about the difference between a real constraint and a preference. State the requirement in terms a competitor could also meet, not in terms only one product uses. If your requirement reads like a particular product's datasheet, you have already lost the contest and you are simply confirming a decision you did not consciously make.
- Write the problem and the outcome first, in plain language, before any vendor contact.
- Mark every requirement as essential or desirable, and be honest about which is which.
- Express requirements as capabilities and outcomes, not as named features only one vendor has.
- Name the failure conditions, the things that would make a solution unworkable in your environment, because that is where real evaluation happens.
Run a process that creates real tension
Competition only works if the vendors believe it is real. A process that everyone can see is a formality produces formality pricing. So the goal is to keep at least two credible options genuinely live for as long as you can, and to make sure both of them know it. That does not mean being dishonest or stringing along a vendor you will never choose. It means not collapsing to a favourite early, not telling the leading vendor it has won, and not letting your timeline give the game away.
Keep the parallel evaluation symmetrical. Give each shortlisted vendor the same requirement, the same information, the same access and the same deadlines. Asymmetry is itself a signal, and a sharp salesperson reads it instantly. If one vendor is getting more of your time and more of your data, they know they are ahead, and they price accordingly.
1. Define
Before any vendor contact
Write the problem, the outcomes, the real constraints and the failure conditions in your own words. This document is your anchor for the whole process.
2. Shortlist
Keep it genuinely competitive
Pick at least two credible options and resist the urge to crown a favourite. The shortlist is where most of your leverage is created or thrown away.
3. Evaluate
Symmetrically and against your own criteria
Run a fair, parallel evaluation against the requirement you wrote, not the one a vendor handed you. Same access, same data, same deadlines for everyone.
4. Decide and commit
With competition still live
Only converge at the end, with the commercial conversation happening while a real alternative is still on the table. This is the IDEAL Decide stage in practice.
How you get steered, and how to resist it
Even with a clean requirement and a real shortlist, the evaluation itself is where a vendor tries to tilt the field. Three moves are worth naming because they are so common.
Proof of concept gaming is the first. A vendor proposes a trial or a bake off and then designs it around their strengths, using their reference architecture, their data, their engineers configuring it, and a success definition that flatters their product. A proof of concept is valuable, but only if you set the scope, the data and the success criteria, and only if every shortlisted vendor runs the same test. Reference stacking is the second. The references and case studies you are shown are hand picked to be the happiest customers in the most favourable circumstances. Ask to speak to a customer who is similar to you in size and complexity, and ask them what went wrong, not just what went well. The third is sales engineer influence. The pre sales engineer is technical, credible and likeable, and is often the most effective salesperson in the room precisely because they do not feel like one. Value their input, but remember whose quota it serves.
If a vendor wants to run the proof of concept on their terms, with their engineers and their definition of success, you are not testing the product, you are watching a demo with extra steps. Own the scope, the data and the pass mark, or do not run it.
The link between the spec and the price
The last thing to understand is that the requirement and the price are not separate stages, they are the same negotiation seen at two moments. A loose, vendor shaped requirement does not just lead to the wrong product, it removes your ability to get a good price on whatever you choose, because it has already told the vendor that you do not have a real alternative. A tight, independently owned requirement does the opposite. It keeps rivals credible, it stops the chosen vendor relaxing, and it gives you concrete, defensible reasons to challenge the quote when it arrives.
This is why the early discipline pays for itself many times over. The buyer who controls the spec and protects the competition is not just more likely to choose the right thing. They are also the buyer the vendor quotes carefully, because that buyer has visibly kept the door open to walking away, and a salesperson can feel that across the table.
What we would do
This is the part of acquisition that is genuinely technical, because shaping a requirement and running a fair evaluation needs someone who understands the technology, not just the contract. We help define the requirement from the business outcome rather than the datasheet, build a shortlist that keeps real competition alive, design proofs of concept that test the product rather than flatter it, and run the process so the commercial conversation happens while you still have a credible alternative in hand. Because we spent years on the vendor side, we recognise the steering early, and we know how the price you will eventually be offered is being set by the choices you make now. Our independence is the point, we have no product to write into your spec.
Buying something new? Send us your shortlist or quote
Tell us what you are buying and where you are in the process. We will give you an independent, vendor neutral read on the requirement, the shortlist and the quote, and where the real leverage sits. The earlier you involve us, the more we can do. We have sat on the other side of the table.
Prefer email? Reach us directly at hello@c4cgroup.co.uk.
Frequently asked questions
When should I involve independent help in a new purchase?
As early as you can, before the requirement is written and the shortlist is set. The biggest gains come from shaping the spec and protecting competition, not from haggling at the end. By the time the quote lands, most of the leverage that decides the price has already been spent.
Should I let a vendor help me write the requirement?
Be very careful. A vendor that helps you scope the purchase will, however helpfully, shape it around their own strengths. Use their input to learn, but write the requirement yourself, from the business outcome, in words a competitor could also meet. The document should be owned by your people, not theirs.
How many vendors should be on the shortlist?
At least two that you would genuinely be willing to choose, kept live for as long as possible. The exact number matters less than the credibility of the competition. One real alternative that the leading vendor believes in is worth more than five names on a list that everyone knows are there to make up the numbers.
How do I stop a proof of concept being rigged?
Own the terms. You set the scope, you provide the data, you define what success looks like, and every shortlisted vendor runs the same test. If a vendor insists on running it with their engineers, their data and their definition of a pass, you are watching a demo, not testing the product.
Does a tight requirement really affect the price?
Yes, directly. A loose, vendor shaped requirement signals that you have no real alternative, and vendors price accordingly. A tight, independently owned requirement keeps rivals credible and the chosen vendor honest, and it gives you concrete grounds to challenge the quote. The spec and the price are the same negotiation at two moments.
What if we have already started and the favourite is obvious?
It is rarely too late to recover some leverage. You can revisit the requirement to make sure it reflects your needs rather than a vendor's datasheet, reopen a credible alternative, and make sure the leading vendor knows the decision is not yet made. Even partial competitive tension restored late will sharpen the final number.