The Committee Is Not One Buyer
The CFO, CIO, legal, security, operator, and user were each burned in a different place and each buys a different proof.
The deal was dead and I did not know it, because the only person I was talking to was happy.
My champion was a director of customer operations who loved the product, used the trial nightly, and forwarded my emails internally with exclamation points. I mistook her enthusiasm for organizational momentum. What I could not see was that every time she forwarded an email, it landed in inboxes belonging to people who remembered the last AI project differently than she did. The security architect remembered a vendor who had been cagey about where data went. The finance partner remembered a per-seat quote that tripled. The IT lead remembered an integration that ate a quarter of his team's roadmap. My champion's exclamation points were, to them, the early-warning sign of another enthusiasm that would cost them later. I was not selling to one excited buyer. I was selling into a committee of differently scarred people, and I had only addressed one of their scars: the one belonging to the person who already agreed with me.
Enterprise buying is committee buying. The research has been consistent for years that a typical complex B2B purchase involves a buying group of multiple stakeholders, not a single decision-maker, and that the number of people who must reach consensus has grown over time (Gartner research on B2B buying groups). For AI specifically, the group is larger and more defensive than usual, because AI touches data, money, risk, jobs, and reputation simultaneously. Six functions can each kill the deal, and each was burned in a different place. A single proof point does not heal a committee. You need a Scar Map.
The Scar Map
The Scar Map is a stakeholder-by-stakeholder inventory of how the last AI failure registered for each member of the buying group, plus the specific evidence each one now requires to feel safe. It is the committee version of the BURNED Diagnostic: where BURNED tells you what killed the last pilot, the Scar Map tells you who is still carrying the wound and what proof closes it for them.
Here is the map in its general form. In a live deal you fill in the right two columns with what you learn in discovery.
| Stakeholder | Likely scar | Evidence they actually buy |
|---|---|---|
| CFO / Finance | A cost model that inverted; an ROI slide that lied | Fully loaded cost at real volume, a sensitivity model, a kill cost ceiling |
| CIO / IT | An integration that consumed the roadmap | A scoped integration boundary, named effort, no surprise dependencies |
| Legal | Risk surfaced too late; an unreviewable system | Clear data flows, retention, explainability, contract terms that allow exit |
| Security | Data that left the boundary, or nearly did | Architecture diagram, data residency, access controls, a pre-read they can vet |
| Operator / Line manager | A model their team had to babysit | Shadow-run results, a fallback path, proof it reduces work rather than adds it |
| End user | A tool that made the job harder, then was forced on them | A workflow they helped shape, control over outputs, the ability to override |
| Data owner | Their data used in ways they did not approve | Explicit data scope, consent, and a boundary they sign off on |
Read down that table and notice that no two stakeholders buy the same evidence. The CFO is unmoved by an architecture diagram. Security does not care about your sensitivity model. The operator could not care less about contract exit terms. If you bring one proof, you reach one seat. The other six watch you fail to address them and quietly conclude you do not understand their building, which is exactly what the last vendor demonstrated.
Each function buys a different proof
It is worth walking the major seats one at a time, because the differences are not cosmetic. They change what you bring to the room.
The CFO buys survivable numbers. Finance was burned by an ROI model that did not survive contact with cost. So a fresh ROI slide, however confident, lands as a threat, not evidence. What finance buys is a cost model that already includes the things that broke last time: token or compute cost at real volume, human-in-the-loop review labor, integration effort, and the cost of the failure case. Finance buys a sensitivity model that shows what happens when your assumptions are wrong, and a hard cost ceiling that caps the downside. We build that model in detail two chapters from now. For the Scar Map, the point is that finance's scar is healed by demonstrated conservatism, not by a bigger projected return.
The CIO and IT buy a bounded integration. IT was burned by a project that quietly expanded until it owned their roadmap. So vague language about "easy integration" or "works with your existing stack" is a red flag, not a comfort. What IT buys is a precisely drawn integration boundary: exactly which systems you touch, exactly what you need from them, exactly whose effort is required and for how long, and an explicit statement of what you will not touch. IT buys a deployment that fits in a box they can see the edges of.
Security buys a pre-read they can attack. Security was burned by being brought in late to a system that had already made decisions about their data. So being asked to "just approve it quickly" is the exact pattern that scarred them. What security buys is being brought in early, with a real architecture and data-flow document they can pick apart before anyone is committed. The standards bodies have done you a favor here: aligning your security and governance story to a recognized framework gives security a familiar lens. NIST's AI Risk Management Framework organizes AI risk into four functions, Govern, Map, Measure, and Manage, that map cleanly onto the questions security and risk teams ask (NIST AI RMF 1.0). The international management-system standard ISO/IEC 42001 gives risk-conscious buyers an auditable structure for AI governance (ISO/IEC 42001:2023). You do not need to lecture security about these. You need to have done the work they imply and to hand them a document that shows it.
Legal buys exit and explainability. Legal was burned by a system nobody could explain after the fact and a contract that made leaving painful. What legal buys is clarity on data flows, retention, and the ability to explain an output if a regulator or a court asks, plus contract terms that let the buyer exit without ruin if the pilot fails. For buyers in the EU's scope, legal is tracking a regulatory timeline that has been moving; the high-risk obligations under the EU AI Act, originally set for August 2026, were provisionally agreed in 2026 to be deferred toward December 2027 under the Digital Omnibus, which legal teams are watching closely (Gibson Dunn on the EU AI Act Omnibus agreement). Whether your use case is in scope or not, legal buys a seller who already knows the answer.
The operator buys less work, proven. The line manager whose team had to babysit the last model is the most quietly powerful skeptic in the room, because they can sabotage a deployment after the contract is signed simply by not adopting it. What the operator buys is shadow-run evidence that the tool reduces their team's work rather than adding a new supervision task, plus a fallback for when the model is unsure, plus assurance that their people had a hand in shaping the workflow. Win the operator and you have won the renewal in advance. Ignore the operator and you have bought a logo that will churn.
The end user buys control. The person who will actually use the thing was burned by a tool that was harder than the old way and then mandated anyway. The behavioral evidence is directly on point: algorithm aversion drops sharply when people can adjust the system's output (Dietvorst, Simmons, and Massey, 2018). What the user buys is the ability to override, correct, and shape the tool, plus genuine involvement in design rather than a mandate handed down. A tool the user can steer is a tool the user will defend.
Mapping the committee before you build the proof
The sequencing matters. You cannot heal scars you have not mapped, and you cannot map scars by talking only to your champion. The champion's view of the committee is optimistic by construction, because they like you. So early in the deal you ask the champion, directly, two questions: who has to say yes, and who was burned last time. Then you ask to meet the skeptics, not to convert them on the spot but to learn their scars firsthand.
This request is itself a credibility move. The last vendor sold to the champion and ignored the committee, which is the D in the BURNED Diagnostic, the decision path that was ignored. When you ask to meet security and finance early, on purpose, before anyone is committed, you are signaling that you have learned the lesson their organization learned the hard way. Burned buyers notice this immediately. It is the structural equivalent of telling them where the floor is before they step on it.
A practical caution: do not let your champion become a buffer who relays your message to the committee in their own enthusiastic voice. A scarred security architect hearing your data story secondhand from an excited operations director will discount it heavily, because the messenger is exactly the kind of person whose enthusiasm burned them last time. Get in the room. Let security attack your real document. The attack is the relationship.
A stakeholder objection decoder
Stated objections from a committee are usually displaced scars. Here is how to decode the common ones, mapping the surface statement to the likely seat and the real wound. This is a tool you keep open during the deal.
| Stated objection | Likely speaker | Real scar underneath | What actually answers it |
|---|---|---|---|
| "We need to be sure about accuracy" | Operator or user | Babysat the last model | A shadow run on their data, with a fallback |
| "Procurement is going to be slow" | Finance or champion warning you | Budget overrun embarrassment | A hard cost ceiling and a sensitivity model |
| "Security will have concerns" | Champion or IT | Risk surfaced late last time | An early, attackable pre-read aligned to a known framework |
| "We're not sure this is a priority right now" | Executive sponsor | Sponsor left and stranded the last one | A named owner and a kill-criteria-bound pilot |
| "How is this different from the last one?" | Anyone | The whole organization's scar | The BURNED Diagnostic, run out loud, with your specific answer to each letter |
The last row is the most important. When someone asks how you are different from the last vendor, they are not asking for a feature comparison. They are handing you the chance to demonstrate that you understand exactly how the last one failed, in their building, and that your motion is built to avoid each failure mode. Answer it with the diagnostic, not with a pitch.
The committee is your ally once mapped
There is a version of this chapter that reads as a warning: beware the committee, it is full of vetoes. That is the wrong reading. A mapped committee is the strongest asset in a burned-buyer deal, because every scarred stakeholder you satisfy becomes a defender who will protect the deployment from the inside. The operator who shaped the workflow defends it to their team. The security architect who attacked your pre-read and found it sound vouches for you to their peers. The CFO whose conservative model held up uses your deal as the template for the next one. You are not getting six vetoes out of the way. You are recruiting six defenders, each healed in the specific place they were hurt.
In the next chapter we take the pilot itself, the moment where all of this gets tested, and we stop treating it as a favor the buyer grants and start treating it as a written contract with the one clause that proves you are honest: the conditions under which the buyer should stop.
Practical Exercise
For your top burned-buyer deal, draw the Scar Map table with all seven seats. Fill in the scar and required evidence for each, marking unknowns as discovery targets. Then count how many seats your current proof actually reaches. If the answer is one, you have a champion, not a deal. Schedule a conversation with the two highest-risk unaddressed seats before your next proposal.
Key Takeaways
- Enterprise AI buying is committee buying, and the AI committee is larger and more defensive because AI touches data, money, risk, jobs, and reputation at once.
- Each stakeholder was burned in a different place and buys a different proof: finance buys survivable numbers, IT buys a bounded integration, security buys an attackable pre-read, the operator buys proven less work, the user buys control.
- A single proof point heals one seat; the Scar Map inventories all seven and the specific evidence each requires.
- Asking to meet the skeptics early is a credibility move, because ignoring the decision path is exactly how the last vendor failed.
- A mapped committee is not a wall of vetoes; it is a set of future defenders, each healed where they were hurt.
