The three doors into an enterprise
The innovation lab, the business-line solutions team, and BAU read the same vendor three different ways
Every large enterprise buys AI through one of three doors: the innovation lab, the business-line solutions team, and the team that runs business as usual, BAU on the org chart. They sit in the same building, report up to the same CEO, and read the same vendor three different ways.
Most writing about enterprise AI buying is written for the vendor: which door to knock on, how to work the org chart. Here the camera points the other way. If you are inside one of those doors, the question that matters is what you should demand from the vendor across the table. The right demand is different at each door, and buyers keep making the wrong one. Each door tends to borrow its neighbor's question and gets a weaker answer than its own question would have earned.
Nothing here comes from a survey. It is my read of how enterprises buy AI, formed over years of selling into regulated companies and watching deals move or stall depending on the door they entered through. The doors are stable across industries. Only the names on them change.
Door one: the innovation lab
The lab exists to pursue what is new. It is measured on pilots launched and learning produced per quarter. That mandate is correct, and it shapes how the lab buys: it can say yes fast, it can tolerate failure, and it owns no business number of its own.
The lab is the right door when the thing on offer is genuinely novel, agents that act across systems, a context graph where there were silos. It is the wrong door for line-of-business pain, because the lab does not own the line of business. The lab's graveyard is full of demos that worked.
What the lab should demand is the mechanism. The lab is the one door staffed to evaluate machinery, and its evaluation is the only artifact it produces that the rest of the building trusts. A vendor pitching the lab should be made to open the hood: how fields from your systems get mapped and what happens when a mapping is uncertain, what the audit trail on each decision records and whether you can query it afterward, where the model runs and who owns the weights. Push past the demo. Demos are the lab's native currency, which is exactly why they are cheap there. A vendor who answers the mechanism questions with a roadmap slide has told you everything you needed to learn, and learning is what you are measured on.
Door two: the business-line solutions team
Most functions at a Fortune 500 now have one: HR solutions, finance solutions, and their cousins across the building. Front-footed operators inside the function, close enough to the work to know where it hurts, senior enough to sponsor change. The solutions team is measured on business outcomes. A number the function owns has to move, and the movement has to survive finance review.
This is the best door for any vendor whose product touches a real workflow, because the buyer behind it owns the problem. It is also the door where the most money gets wasted, because outcome pressure makes the solutions team the easiest audience for ambition. A team that needs a number moved by Q4 wants to believe.
What the solutions team should demand is an ROI gate on every workflow. Before anything runs, each proposed workflow should arrive carrying its cost of action and its cost of inaction, in dollars, so the team can approve it, edit it, or decline it with the trade visible. It forces the vendor to commit to where the value comes from. And it accumulates, workflow by workflow, the receipts your CFO will demand at renewal.
We hold ourselves to that gate in production. At the Fortune 500 insurance carrier where Nodes runs live, hire rate moved from 14.0% to 27.7% across 6,053 hires, ramp compressed from 8 to 12 months down to six weeks, and the first quarter closed with $1.58M in net savings validated by the carrier's CFO. The methodology behind those figures is published in Decision Traces. The numbers matter less here than where they came from: an ROI gate sat in front of every workflow, so the solutions team never had to argue its case from a vendor's slide.
Door three: business as usual
BAU keeps the lights on. It is measured on stability: uptime, incident counts, audit findings, renewals that arrive without surprises. It buys automation of what it already does, and it distrusts everything else.
The distrust is earned. Every system BAU babysits at 2am was once somebody's exciting pilot. BAU inherits what the other two doors buy, which is why it reads vendor enthusiasm as a forward liability, and why "too early" from a BAU leader is rarely about the calendar. Often it means: I cannot personally evaluate this system, and if it fails I am the one explaining it to the business. A vendor who hears that and responds with more enthusiasm has confirmed the fear.
What BAU should demand is a control model and exit rights. The control model: who approves what, what gets logged, what a regulated workflow requires before it executes (in our case, a second signer), and what your CISO can inspect without filing a ticket. The exit rights: what happens to the data and the model if the relationship ends. The answers that clear the bar are architectural. Data that never leaves your VPC. A model you own, and keep, if the vendor walks away. A vendor whose exit story is "we will export your data for you" has confirmed there is a lock.
Procurement vets, the business owner drives
In years of enterprise selling I have not once seen procurement initiate a deal. The sequence never varies: a person who lives the problem pushes the deal through the building, and procurement vets what arrives.
Both sides should act on that. If you are a buyer waiting for procurement or IT to surface the fix for a number you own, you will wait through several budget cycles. The deals that close are the ones where the owner of the problem walks the vendor through the building herself. And when a prospect does not yet know it has the problem, the vendor's move is to find the person living it. No deal has ever been vetted into existence.
The entry door also sets the deal's ceiling. A deal that enters through the lab retires as a pilot unless a business owner carries it across. A deal that enters through BAU rarely grows beyond the process it automated. The deals that reach production at scale enter through the solutions team, with the problem owner driving and procurement vetting behind her.
Specificity clears every door
The three doors say yes to different things and no to the same thing: a vendor who can do anything. The lab cannot inspect a mechanism with no edges, and BAU cannot write a control model around a platform that refuses a scope. "We can do anything" is unevaluable at every desk it lands on. The wedge that wins is narrow enough to test: a named problem in a named function.
The same argument has a buyer-side twin. I have written separately about why "we need AI" is not a problem statement; that piece is about scoping a problem until it can be funded. This one is about carrying the scoped problem through the right door. The failure modes compound. A vague problem at the wrong door is how an enterprise spends a year evaluating AI and ships nothing.
Which door are you standing in
The diagnostic takes one question: what are you measured on?
If you are measured on what your organization learned this quarter, you are standing in the lab. Demand the mechanism. Make the vendor show you the mapping and the trace, and write up what you find, because your write-up is the only artifact the other two doors will trust.
If you are measured on a number the business owns, you are the solutions team. Demand the ROI gate: every workflow priced before it runs, cost of action against cost of inaction, receipts accumulating from week one.
If you are measured on nothing going wrong, you are BAU. Demand the control model and the exit rights, and be unapologetic about it. You are the door that will still be holding this system in five years.
Vendors sort fast when each door demands the thing its own mandate entitles it to. The three doors are the enterprise asking three good questions, and a vendor worth buying has answers for all three at once.
Saad Bin Shafiq is the founder of Nodes. Anchor pilot: Fortune 500 insurance carrier, four years of production data, 10,765 agents. Methodology: Decision Traces.