Gartner reports that 74% of B2B buying teams experience unhealthy conflict during a purchase decision. That number describes almost every stalled security evaluation I have watched from either side of the table. The product was fine. The committee never converged.
I have been on both ends of this. I founded LoginRadius in 2013 and scaled it to over a billion user identities, which meant sitting through several hundred enterprise security evaluations from the vendor's chair, and I have run the security and compliance program that had to buy its own tooling. The evaluations that ended in a decision looked structurally different from the ones that evaporated, and the difference showed up in the first fortnight.
Why security evaluations stall
A security purchase crosses more internal boundaries than almost any other software buy. Gartner puts a modern B2B buying group at five to sixteen people across as many as four functions. Security sits at the top of that range because the tool touches identity, so IT is involved; it processes data, so privacy and legal are involved; it carries a contract, so procurement is involved; and it needs an architecture opinion, so an engineer who never joins a call is involved.
Each of those functions can stop the purchase. Only one of them can start it. That asymmetry is the entire problem. A committee with six vetoes and one sponsor does not need a competitor to lose a deal, and it does not need a reason to be written down anywhere.
The visible symptom is a slow evaluation. The actual mechanism is that two functions reached incompatible positions, neither wanted to escalate, and the purchase lost its slot on the roadmap without anyone recording a decision.
The short answer
Treat the evaluation as a decision with an owner and an expiry date. Three moves, all in the first two weeks:
- Enumerate every function that can say no, by name, not by role.
- Get each one's specific objection in writing before the first demo.
- Set the date on which no decision becomes a decision to decline.
Everything else in an evaluation is negotiable. These three are what separate a process that closes from one that decays.
The discriminating variables
Who can say no, and do they know they can
Ask the sponsor to list the people whose objection would stop this. Then ask each of those people whether they believe they have that power. The gap between the two lists is where evaluations die.
The test: if a named person on the veto list has not been contacted by week two, the evaluation is already behind, regardless of how many demos have happened.
Whether the objection is written down
An unwritten objection cannot be answered. It can only be discovered late, usually after a proof of concept has consumed six weeks.
The test: can you produce a one-line statement of what each function is worried about, in that function's own words? If procurement's concern is "we have not benchmarked this pricing" and nobody wrote it down, you will find out in the final week.
Whether there is a real alternative
Committees converge faster against a stated alternative than against an open field. The alternative can be a competing product, an internal build, or explicitly doing nothing for another year. Doing nothing is a legitimate option and should be on the list with the same rigor as the vendors.
The test: is "no purchase this cycle" written on the comparison with its own consequences described? If not, the committee is being asked to choose between products when it has not yet agreed it needs one.
Whether the decider is a person
"The committee will decide" is how an evaluation becomes ownerless. Committees advise. A person decides, and that person should be named at kickoff, in writing, to everyone involved.
The test: if you ask three committee members who makes the final call, do you get the same name?
Whether the timeline survives a holiday
Evaluations are planned against working weeks and executed against calendars that contain end of quarter, summer, and whichever national holidays your committee spans. A six-week evaluation started in mid-November is a ten-week evaluation.
The test: count the working days between kickoff and your decision date, then subtract the days your two most senior veto-holders are unavailable. If that number is under twenty, either move the date or cut a stage.
A decision table
| Signal | What it means | What to do |
|---|---|---|
| No named decider by week one | The evaluation is a research project | Name one or stop |
| A veto-holder is uncontacted by week two | You will discover their objection in month three | Contact them before the next demo |
| No written objections | The committee is being polite, not aligned | Ask each function what would make them say no |
| No stated alternative | Consensus has nothing to push against | Add "do nothing" with its consequences |
| No expiry date | The evaluation will outlive its budget window | Set the date the default becomes decline |
What this looks like in practice
An example, compressed from several real ones.
A company evaluating a cloud security platform. Sponsor is the head of security. The committee, once written down, is seven people: security lead, a cloud architect, the platform engineering manager whose team would operate it, someone from IT for the identity integration, procurement, legal for the data processing agreement, and a finance partner who owns the budget line.
Week one produces the four lines: decider is the head of security, veto-holders are the architect, the platform manager, legal, and procurement, the default becomes no on 15 March, and the alternative is extending the incumbent contract for a year.
Week two produces four written objections, one per veto-holder:
- Architect: "I do not believe the agent's resource footprint at our node density. Show me a customer above 4,000 nodes."
- Platform manager: "My team is on call for this. Who answers a 2am page, us or the vendor?"
- Legal: "Where does telemetry land, and is there a sub-processor in a jurisdiction we have not approved?"
- Procurement: "We have not benchmarked this pricing and the incumbent will discount if we ask."
Look at what those four objections do to the shape of the evaluation. None of them is answered by a demo. Two are answered by a reference call with a customer of comparable scale. One is answered by a document. One is answered by running a competitive process rather than a single-vendor one.
Without writing them down, the demo happens anyway, the POC happens anyway, and the architect's objection surfaces in week nine when somebody finally asks him directly. That is the entire failure mode, and it is three emails of prevention.
What the evaluation costs you
Worth stating, because most organizations never price this and then wonder why evaluations feel expensive.
A seven-person committee running a ten-week evaluation with a weekly thirty-minute sync, plus reading time, plus two demos, plus a proof of concept, consumes somewhere between 120 and 200 hours of internal time. At a loaded rate that is thirty to fifty thousand dollars, before anyone signs anything.
Two consequences follow. The first is that running a full evaluation on a fifteen-thousand-dollar tool is irrational, and organizations do it constantly because the process is uniform rather than proportional. Set a threshold below which the decision is one person plus a reference call, and put the number in writing so nobody has to defend skipping the ceremony.
The second is that an evaluation which dies without a decision has still spent that money. That is the real cost of the failure mode this piece describes. It is not the delay. It is that the organization paid forty thousand dollars to learn nothing and will pay it again next year when the problem resurfaces.
What changes the answer
A renewal deadline. If an incumbent contract expires on a fixed date, the expiry date is set for you and the evaluation compresses naturally. Use it.
A regulatory trigger. Evaluations driven by an audit finding or a regulatory obligation have a built-in decider, usually whoever signs the attestation. The committee gets smaller and faster. Do not add stakeholders it does not need.
Very small organizations. Under roughly fifty people, the committee is two or three people who already talk daily and the formal structure is overhead. Skip it. The failure mode below that size is buying too fast, not too slowly.
A genuinely novel category. If the organization has never bought this class of tool, expect an extra cycle spent agreeing on what the category is. That is real work, not delay, but it should happen before vendor contact and it should have its own end date.
The one meeting that fixes most of this
If you take one thing structurally, make it this: a thirty-minute meeting in week two where every veto-holder states their objection out loud, in front of each other.
Not a status meeting. Not a demo. One round of the table where each function says what would make them say no, and somebody writes it down verbatim.
Three things happen in that room that do not happen in parallel one-to-ones. Functions discover that two of them have the same concern, which turns two soft objections into one hard requirement. Somebody with no formal veto raises the thing that actually kills it, usually the person who would have to operate the tool. And the sponsor learns, in week two rather than month three, whether this evaluation has a path.
The meeting is uncomfortable, which is why it does not happen by default. Gartner's finding that 74% of buying teams experience unhealthy conflict is partly a description of organizations that never scheduled it, and let the conflict happen asynchronously and invisibly instead.
What to do with an evaluation that has already stalled
If you are reading this mid-evaluation rather than before one, the recovery is a single message rather than a restart.
Send one note to the committee saying: here is the decider, here is the date the answer becomes no, and here is what I understand each of your objections to be. Ask for corrections rather than agreement. Corrections arrive fast because people will not let a wrong summary of their position stand, and the corrections are the objections you never got.
That message either restarts the evaluation on a real footing or it produces silence, and silence is also an answer. An evaluation nobody will correct is one nobody is invested in, and closing it is a better use of the quarter than continuing to schedule demos into it.
What to do Monday
Open the evaluation document and add four lines at the top: the decider's name, the list of functions with veto power, the date the default becomes no, and the alternative being compared against. If you cannot fill in all four by Friday, you do not have an evaluation yet. You have a set of demos.
Then send one message to each veto-holder asking a single question: what would make you say no to this? Do it before the next vendor call. The answers are the evaluation.