The meeting that decides your deal is one you are not in. A corporate buyer does not adopt a new technology because one engineer liked it. A group agrees, in a room you never enter, and the person who met you has to carry your case to the rest of them without you. If you have not given them what they need to do that, the deal stalls where you cannot see it.
Think of the buyer as a walled building. You get one person over the wall to let you talk to them, and then that person has to walk your argument back inside, past everyone who guards the gate. Whether the deal survives depends almost entirely on what they are carrying.
Who is actually in the room
A deep tech purchase of any size involves a committee, even when nobody calls it that. The members are predictable.
A technical evaluator, who decides whether it works and whether integrating it is going to land on their team. Someone in operations, who is thinking about downtime, maintenance and who gets called when it breaks. Someone in finance, who wants a number and a payback period and a comparison against doing nothing. An executive sponsor, who cares about the strategic case and has roughly ninety seconds of attention for it. And, usually, someone who can block the whole thing without ever being in a meeting with you, because it threatens a system they own.
You will meet one or two of these people. The rest form their view of you second-hand, through whatever your champion manages to relay.
Why the good meeting goes nowhere
Steve Cook, who has watched a lot of these from the corporate side, makes the point that the person you meet is rarely the person who decides. They are a champion, and after your meeting their job is to sell your technology internally, in a short slot, to people who have never met you.
They do this from memory. Whatever they retained from an hour with you is the entire case the finance director ever hears. If what they retained was that it was interesting and a bit complicated, that is what gets said, and the committee moves on.
It gets worse across roles. Your champion is usually technical, so the technical part of your pitch survives the retelling reasonably well. The finance case does not, because your champion is not a finance person and was never equipped to argue it. The operations concern never comes up at all, so the operations lead fills the silence with their own worst assumption. The deal does not fail on its merits. It fails because your argument arrived in four different rooms in the wrong shape, or did not arrive at all.
I have covered the psychology of why a single buyer smiles and then goes cold separately, in why corporate buyers say yes in the room and no afterwards. This is the structural version of the same problem, across the whole group rather than one person.
Map the committee before you build anything
The work starts before any document exists, with the founder or commercial lead writing down who is actually on the committee for a given deal.
Which company, which job titles, who evaluates, who pays, who blocks, who signs, and, for each of them, what they need to hear to say yes. Most deep tech companies cannot do this cleanly on the first attempt, and the gaps are informative. If you do not know who signs, you do not yet understand the deal. If you have never considered who might block it, you are about to be surprised by them.
This map is useful well beyond the documents. It is the same targeting specification you would hand to any LinkedIn campaign work, because the people on the committee are the people the campaigns should be reaching. Getting the committee map right once feeds everything downstream.
Build one thing per role
Once you know who is in the room, the fix is to stop handing your champion a single deck and start handing them a set, one short document per role, each written to that person’s part of the decision.
A technical answer sheet, covering the specification, the integration questions and the evidence, answered straight rather than sold. A finance document, giving cost, payback and a risk comparison in the language a finance function actually uses. An operations document, covering implementation, disruption, maintenance and who does what when something goes wrong. And an executive one-pager that makes the strategic case in the ninety seconds an executive will give it.
None of these is long. The point is not volume, it is that each member of the committee receives something that speaks to their concern instead of a general document that speaks to none of them. The technical evaluator was going to be fine anyway. These assets exist for the four people you never meet.
This is the same discipline as matching a landing page to the advert that sent someone to it, which I have written about in landing pages that match the ad. Right message, right role. The only thing that changes is that the medium here is a document travelling through a building rather than a page behind an advert.
Hand the champion a plan, not a pile
The last piece is the least obvious and the one that makes the difference. The documents come with a short guide for the champion: who gets which one, and when in the process.
Left to improvise, even a motivated champion sends everything to everyone, or sends the technical sheet to the finance director because it is the one they understand best. The usage guide removes that. The finance document goes to finance, before the budget conversation. The operations document goes to operations, before they raise the maintenance objection rather than after. Your champion stops being a single point of failure repeating a half-remembered pitch, and starts being someone handing the right person the right answer at the right moment.
When this will not save the deal
This isn’t a guarantee though, because a well-made document pack cannot rescue everything.
If your champion does not really exist, none of this helps. If the person carrying you is lukewarm, or junior enough that nobody listens to them, the first job is finding or building a genuine champion, not equipping a weak one. A brilliant set of documents in the hands of someone who does not care goes in a drawer.
And if the technical evaluation has genuinely failed, no finance one-pager can fix that. This works when the substance is there and it is not travelling across the committee, which is a real and common problem. It does nothing for a deal that is dying because the technology did not do what you said, and it would be dishonest to suggest otherwise.
What to do first
Before your next serious opportunity, write the committee map for that specific deal. Name the people if you can, the roles if you cannot, and write one line on what each of them needs to believe. That alone will show you where your case is thin, usually in finance or operations, because those are the rooms technical founders think about least.
Then build the missing documents (videos also work really well), starting with the one for the role most likely to block you. You do not need the full set on day one. You need the finance case to exist before the finance conversation happens.
If you want help mapping the committee and building the documents that get your champion through the gate, that is part of what our growth work covers, and a 20 minute call will tell you whether this is your bottleneck or whether the deal is stalling somewhere upstream.
Frequently asked questions
What is a buying committee in deep tech sales?
It is the group inside a corporate buyer that has to agree before anything is adopted. Typically a technical evaluator, someone in operations, someone in finance and an executive sponsor, plus whoever can quietly block it. Each has a different concern, and a supplier usually meets only one or two of them.
Why do deep tech deals stall after a good meeting?
Because the person you met has to carry your case to the rest of the committee without you, from memory, and the parts of your pitch that matter to finance or operations were not built for them. The deal does not die in your meeting. It stalls in the meetings you never attend.
How do you support an internal champion?
Map the committee first, so you know who they have to convince, then give them one short document per role written in that person’s language: a technical answer sheet, a finance and payback case, an operations plan and a ninety-second executive summary. The champion hands the right document to the right person rather than improvising.
What is the difference between a champion and a decision maker?
A champion wants your technology to win and argues for it internally, but usually cannot approve it alone. The decision maker signs, and is often someone you never meet. Most of the work is helping the champion win over the people between them and the signature.
How many documents do you actually need?
Usually four, one each for the technical, operations, finance and executive readers, and often a fifth aimed at whoever is most likely to block it. Start with the role most likely to say no, because that is the one your champion is least equipped to handle alone.