Last week I argued that the first AI hire is usually a worse bet than the second process you already know is broken. The owner who can already name a number, cost per contact, hours after 6pm, a role open for months, does not need a new seat to start. They need that process, and a written answer to what happens to the freed hour.
This issue is the next room in that sequence. The process is named. The number is on the page. Someone is about to buy a tool, or already has. And the question that decides whether Monday gets quieter or just weirder has almost nothing to do with the model.
Who gets the call when it is wrong.
The room after the demo
I keep sitting in a version of the same meeting. Owner of a company between five and twenty million. Ops lead. Sometimes the person who still answers the phone at 9pm because the open req never filled. The demo went well. Containment looked good. Someone said "we should just turn it on."
Then I ask a boring question.
When the agent is wrong at eleven, whose name is on that.
The room does one of three things. It invents a role that does not exist. It points at the vendor. Or it goes quiet, because the honest answer is still the owner, and the whole point of the project was to get the owner out of that queue.
None of those three is an operating model. The first is a hire you said you were not making. The second is a contract, not a night shift. The third is the same Sunday coverage with a new logo on the ticket.
I sell the systems in these rooms. GoZupees. Voice, intake, the repetitive service work. So read this knowing I would rather you go live than keep piloting. The bias is declared. The pattern is still what I see when the deal is already signed and nobody has written the escalation line.
What "live" actually means at this size
At a company this size you do not have an AI ops team. You have a process with an owner, a queue with a number, and a small set of people who already know what "wrong" looks like because they have been cleaning it up for years.
Live means the repetitive half stops needing a person on every turn. It does not mean the judgment half disappears. The five percent, the angry customer, the edge case, the thing that needs a human name, still has to land somewhere with authority. Someone has to decide what escalates. Someone has to change the process when the same failure shows up three nights in a row. Someone has to be allowed to pull the agent off a path without waiting for the next steering committee.
That someone is usually already in the building. The receptionist who became the person who reviews the transcripts. The ops lead who already owned the after-hours line. The office manager who already knew which calls were "where's my technician" and which ones were a lawsuit waiting.
The companies that make this work do not invent a new owner after go-live. They keep the owner they already had, take the repetition out, and leave the judgment in. The escalation is not a support ticket to the vendor. It is the job.
Why the five percent gets postponed
It gets postponed because the demo sells the ninety-five.
Accuracy, containment, cost per contact. Those are the words that get a budget signed. Escalation ownership is a sentence that sounds like process bureaucracy when everyone is still excited about the pilot. So it slides. "We'll figure that out once it's live." "The tool has a dashboard." "We'll have someone look at the transcripts."
Then it is live. The ninety-five works well enough that nobody wants to turn it off. The five percent starts landing on whoever is nearest, or on the owner again, or on a shared inbox that nobody treats as a job. Quality does not cliff on day one. It decays. The same edge case repeats. The person who would have noticed is either covering something else or was never named. Two quarters later the owner is back in the queue, and the story becomes "AI didn't work here," when what failed was ownership, not the model.
I have watched this from the vendor seat. The client who names the exception owner before cutover has a boring first month. The client who does not has an exciting first month and a quiet resignation around month three.
The vendor is not your night shift
This is the part that makes me look bad, so I will say it plainly.
We can build the handoff. We can page. We can show you the transcript. We cannot be the person who knows your customer, your policy, and what you are willing to say when the answer is no. That is not a feature gap. That is the work you still own.
If your escalation path is "email the vendor," you have bought a demo with a longer runway. Useful while you are learning. Fatal as an operating plan. The exception owner has to sit inside your company, on a process they already understood before the software showed up, with permission to change the path without asking the founder every time.
Last week's point still holds. Do not hire a Head of AI to be that person before the process exists. Do put a name, a real name, already on payroll, next to the exception before you flip the switch. If you cannot name them, you are not ready to go live. You are ready to keep counting, or to keep piloting, which is the same as not going live while spending the money anyway.
What to write on the page
Before the tool is on, write four lines. Not a policy deck. Four lines the ops lead can read out loud.
What counts as wrong. Not "bad experience." A concrete trigger: wrong address, refund over a threshold, anything that mentions a lawyer, third failure on the same account this week.
Who gets it. One name. Not a shared inbox. Not "the team." The person who already owned this process when it was all human.
By when. Minutes, not "same day" if the queue is after-hours. If you cannot staff that window, do not pretend the agent covers it. Narrow the hours or keep a human on that slice.
What they can change without asking you. The path, the greeting, the escalation rule for that failure mode. If every fix needs the owner, you have rebuilt the measurement layer with a nicer UI.
If those four lines are blank, the Monday action is not "evaluate vendors." It is filling them in for the process you already have a number for.
Monday action
Take the process you can already explain to your bookkeeper in a sentence. The one from last week, if you wrote it down. If you did not, start there first.
Under the number, write the escalation block. What counts as wrong. Who gets it. By when. What they can change without you.
If you cannot fill in the who, stop. That is the work. Naming the owner is cheaper than another pilot, and it is the only way the freed hour stays freed instead of crawling back onto your Sunday.
If you can fill it in, you already know whether you are ready to go live. Most of the time the blocker is not the model. It is the blank line where a name should be.
Tell me the process, and tell me the name. I read the replies.
Sandeep Bansal is the founder of GoZupees. He sells the systems this essay is about, which is why he wants you to go live with an owner named, and why you should check the argument against your own night shift, not his.