At some point in an enterprise sale, the buyer brings an architect or a security lead into the room. Their job is to establish whether the capability described in the proposal exists. The supplier's instinct is to send whoever presents best, and the better instinct is to send the person who would actually do the work — because the buyer's technical person can tell the difference within a few questions, and the discovery that they were being managed is worse than any weakness they might have found.
The most valuable thing an engineer can do in that room is answer a question they do not know the answer to correctly. Saying I do not know, I will find out and come back by Thursday, and then doing it, is the strongest credibility signal available. Guessing and being wrong is discovered later and taints everything else that was said. Technical buyers have sat through many meetings with confident wrong answers and they are alert to it.
Be honest about limitations proactively rather than under questioning. A supplier who says our system does not currently do X, here is how customers work around it, and here is where it sits on our roadmap, is trusted on everything else they claim. One who is discovered not to do X after asserting a complete solution has changed the buyer's question from can they do this to what else were they not straight about.
Prepare by anticipating the four or five questions that actually decide it rather than by rehearsing a demonstration. How does authentication work, where does the data live, what happens when your service is unavailable, how do we get our data out, and who has access to production. Those come up in almost every enterprise technical conversation, and having a clear, specific, unrehearsed-sounding answer to each is worth more than any slide.
Afterwards, write down what was asked and what was promised, and get it to the delivery team. A commitment made in a technical call — we can support that protocol, we could expose that as an API — is as binding as anything in the contract from the buyer's perspective, and it is frequently made by someone who will not build it. That transfer is the same handover problem that damages projects generally, arriving in its most specific and most forgettable form.
