Dex
7 min readBy Dean Craftsman

The "no decision" is the enemy: why 50% of IT automation deals die to the status quo, not a competitor

IT automation ROI loses most often to doing nothing. Why the ticket queue is the real competitor, and how IT leaders price the cost of waiting.

The ROI of IT automation rarely loses to a better product. It loses to nothing. Across B2B software, 40 to 60 percent of deals end in "no decision": the buyer evaluates, the committee meets, the pilot runs, and then everyone quietly goes back to the ticket queue. For IT leaders this is not a sales statistic. It is the reason your own backlog keeps winning budget reviews it should lose.

This post reframes the status quo as what it is: a competitor with a cost, a constituency and a very good defense. If you are an IT leader building a case for autonomous IT, the job is not to prove one vendor beats another. It is to prove that waiting has a price, and that deciding is safer than it feels. Here is how to do both.

Why most IT automation deals end in "no decision"

Most stalled IT automation projects are not rejected. They are deferred until they disappear. Matthew Dixon and Ted McKenna analyzed more than 2.5 million recorded sales conversations for The JOLT Effect and found that 40 to 60 percent of B2B deals end with no decision at all. Their more uncomfortable finding: most of those losses were not buyers who preferred the status quo. They were buyers who agreed change was needed and still could not commit.

The causes are familiar to anyone who has sat on an IT buying committee:

  • Fear of the wrong call. Nobody gets fired for keeping the helpdesk running the way it ran last year.
  • Option overload. Copilots, chatbots, ITSM add-ons and agentic IT all claim the same outcome, so comparing them feels like more work than waiting.
  • No owner of the outcome. The backlog is everyone's problem, so the decision is nobody's job.

None of these is a feature gap. A longer feature list does not fix any of them.

The status quo is a competitor with a ticket queue

The status quo wins because it never has to make a case. It has no implementation plan, no security review, no procurement step and no line on the budget with its name on it. Its cost exists, but it is distributed: a few hours of blocked users here, an interrupted engineer there, an escalation that re-investigates what Tier 1 already looked at.

That is exactly why the ticket queue is the villain in the Dex story. The queue is not neutral infrastructure. It is the mechanism by which an IT request turns into waiting, and waiting is where both tickets and deals go to die.

Split funnel diagram comparing two paths: evaluate, stall and keep the ticket queue, where deals and tickets die, versus resolve before the ticket exists.

Look at the two paths side by side. On the first, the organization evaluates, stalls and keeps the queue: the deal dies to no decision, and requests keep dying in the backlog with the same SLAs as last quarter. On the second, the request is resolved the moment it is raised, so the ticket never exists. The decision is the same decision in both cases. Only one of them has a cost that shows up on a dashboard.

Why your own backlog keeps winning the budget review

Your backlog wins internal budget reviews for the same reason it wins against vendors: its cost is invisible to the people approving spend. Three things keep it hidden.

The cost lives in other teams' P&Ls. The helpdesk line shows technician time and tooling. It does not show the sales rep locked out of their CRM for half a morning, or the new hire who waited two days for access. In our IT helpdesk math, loaded cost ran about three times the invoice cost once user wait time, engineer interruption and escalation overhead were counted.

"Normal" absorbs the drag. A team that has always worked a queue stops seeing it as a cost and starts seeing it as the job. Engineers who spend the week on resets and access requests report that the week was busy, not that it was wasted.

The new option carries all the scrutiny. The proposed tool gets a security review, a pilot and a CFO question. The queue gets none of those, so it looks risk-free by default. As we covered in why CFOs veto already-approved software, finance is now reviewing at the last checkpoint, and an unpriced status quo makes every alternative look like the risky choice.

Price the "do nothing" option: IT automation ROI starts with the cost of waiting

The fix is to put the status quo on the same line as every other option. Our per-resolution TCO model does this directly: it computes a cost per resolution from labor, user downtime, escalation and tooling, and it asks you to run every option through the same formula, including doing nothing.

Once doing nothing has a number, waiting has a monthly cost:

Cost of waiting per month  =  (Today's annual cost  -  Annual cost with the tool)  /  12

Using the illustrative 500-person organization from our helpdesk math, resolving 90% of Tier 1 work cut the loaded cost of IT support by about $103,500 a year. That makes a one-quarter "let's revisit after planning" roughly a $26,000 decision. And it is a conservative figure, because that model counted Tier 1 only. Dex resolves L1 through L3, and the expensive layers of the per-resolution model, escalation and downtime, concentrate in the L2 and L3 tickets that wait for a named engineer.

Plug in your own volume and loaded rates. The point is not our number. The point is that "no decision" is a decision with a price, and the committee should see it written down.

How to make deciding safer than waiting

Pricing the queue removes the illusion that waiting is free. The other half is removing the fear that deciding is dangerous, because that fear, not cost, is what stalls most deals. Four moves shrink the decision.

Start with a bounded scope

Pick request types you already know cold: password resets, MFA recovery, group and license access, then a set of Tier 2 configuration fixes. A decision about a defined slice of work is smaller than a decision about "automating IT."

Write policy before you grant action

Dex investigates the issue, plans the change and executes it, but only inside explicit policy. Every action must match a structured policy enforced in code. No policy, no action. That turns "what if it does something wrong?" into a question your team answers in writing before go-live. You can see the full investigate, plan, execute loop on how Dex works.

Make every action verifiable

Every Dex action is written to native Microsoft 365 logs and to Dex's own Activity Log. The committee does not have to trust a vendor's resolution count. It can audit it.

Prove it on real requests

A free trial on your own tenant replaces a forecast with evidence. Employees reach Dex through Dex Go in Microsoft Teams and Slack, so the trial runs where requests already arrive, with no new portal to adopt. Dex works alongside your ITSM, which stays the system of record for whatever still needs a human.

What to bring to the next committee meeting

If your IT automation evaluation has been "in progress" for more than a quarter, bring three things to the next meeting:

  1. The status quo as a line item. Today's cost per resolution, multiplied by volume, next to every vendor option.
  2. The monthly cost of waiting. One number, from the formula above, using your own data.
  3. A reversible first step. A scoped pilot, the policies that bound it, and the audit trail that proves what happened.

That reframes the meeting. The question stops being "which tool is best?" and becomes "what are we paying to keep the queue, and what is the smallest safe step to stop?"

Dex is the world's first autonomous IT engineer, working across Microsoft 365, Google Workspace, Okta and any SaaS. But the competitor we meet most often is not another product. It is the ticket queue, defended by inertia. You beat it the same way Dex beats a ticket: by resolving it before it has a chance to wait.

Frequently asked

Why do so many IT automation projects end in no decision?
Because the alternative to buying is not a rival product, it is keeping the ticket queue, and the queue never has to prove anything. Research by Matthew Dixon and Ted McKenna, based on more than 2.5 million recorded sales conversations and published as The JOLT Effect, found that 40 to 60 percent of B2B deals end in no decision. Most of those losses trace to buyer indecision: fear of making the wrong call, too many options, and no clear owner of the outcome. For IT automation the effect is stronger, because the cost of the backlog is spread across every team's calendar while the cost of the new tool sits on one visible line.
How do I calculate the ROI of doing nothing on IT automation?
Treat doing nothing as an option with its own cost per resolution. Take today's fully loaded cost per resolved issue (technician labor, user downtime, escalation handoffs, and the tooling the fix consumes), multiply by annual volume, and compare it with the same number under the tool you are evaluating. The gap, divided by twelve, is what each month of waiting costs. In our illustrative 500-person model, resolving 90% of Tier 1 work alone cuts the loaded cost of IT support by about $103,500 a year, so a one-quarter delay leaves roughly $26,000 on the table before L2 and L3 work is counted.
Is the status quo really a competitor in IT buying decisions?
Yes, and usually the strongest one. The status quo has no implementation risk, no change management, no procurement review, and no budget line of its own. Its cost is real but diffuse: users blocked while tickets wait, engineers interrupted by routine work, and escalations that re-investigate the same issue. A business case that only compares vendors against each other ignores the option most likely to win, which is keeping the queue.
Does Dex only resolve L1 tickets?
No. Dex autonomously resolves L1 through L3: routine Tier 1 work such as password resets, MFA recovery and access provisioning, plus the Tier 2 and Tier 3 troubleshooting, configuration and engineering-adjacent work that used to need a senior technician. Only genuine architectural or judgment calls escalate to a human, with the full investigation attached. Scope matters to the cost of waiting, because the most expensive tickets in the queue are the L2 and L3 ones that sit until a named engineer is free.
How do I reduce the risk of deciding on IT automation?
Make the decision small, reversible and verifiable. Start with a scoped set of request types, write the policies that bound what the system may do, and require every action to land in an audit log you can check. Dex enforces policy in code, so an action with no matching policy is blocked rather than attempted, and every action is written to native Microsoft 365 logs and to Dex's own Activity Log. A free trial on real requests gives the committee evidence instead of a forecast.