A chief operating officer has three requests on her desk and the budget for one. Branch managers want faster onboarding. Finance wants complete job records before an invoice leaves. The president wants fewer exceptions landing in his inbox. This episode puts that choice in front of two voices — one makes the operating case, the other tries to break it — and the recording above runs about seven minutes from start to finish.
I wrote the conversation to be argued with. The position in it is mine, and the objections are the ones that I would want a buyer to raise before they sign anything. What follows is the written version of it: the rule that the conversation arrives at, the objections that changed it, and the three things that you can do this week without buying software.
The Demo Is Not Evidence
The first exchange settles what the decision is not about. A demo shows what a model can do in a room. It says nothing about whether a handoff in your operation will change, who will use the result on an ordinary Tuesday, or what happens to the records that do not fit.
A demo tells you what a model can do in a room. It tells you nothing about whether your operation will change.
Adoption figures have the same limit. In the collection period ending May 3, 2026, reported AI use among firms with 100 to 249 employees reached 32% (Census Bureau, 2026). That number counts firms that report using something. It does not show whether any one workflow improved, so it cannot tell this operator to fund all three at once.
Consequence, Volume, Owner
The rule has three parts, and each one can be checked before any software exists.
- A consequence you can measure now. Completed jobs that wait for paperwork can be counted, and so can the days each one waits. That count is the baseline.
- Enough volume to judge a release. Finance closes jobs every day; a branch may onboard a few people a quarter. A first release has to be used enough for you to read its result.
- One owner who can decide. Finance owns the late invoice, but the missing information comes from the technicians in the field. If no executive can bring both teams into one decision, software automates the argument instead of settling it.
Research on workflow redesign and self-reported earnings impact supports looking past isolated tool use to the workflow around it (McKinsey, 2025). It reports an association, not a promise for your operation. Your baseline and observed adoption carry the decision.
The Objection That Changed It
The skeptic's strongest point is aimed at me: an engineering firm will conclude that the answer is to build software. The honest reply to it is that configuration comes first. If a setting in the field-service system can require the technician's photograph before a job is closed, then that is a task for Monday and it does not need an engagement.
Custom software earns its place in the gap between systems — the handoff that lives in email and in a spreadsheet because no product owns it. That distinction is one worth making before a first call, because it decides whether or not there is a project at all. A clear no is one of the legitimate outcomes that such a conversation can have.
Small Enough To Read
Scope is where a first project loses meaning. If a release touches nine teams and six systems and numbers move, nobody can say why. If it touches one handoff, the result points at what to fund next. For the partnership, the boundary is written: one prioritized workflow, with each release's people, systems and outcome agreed before work begins.
The same section of the conversation covers where a person stays involved. Automate the match that repeats, route every uncertain case to a named person, and keep the record of each decision. In the clinical billing work ML LABS delivered, claims did not move forward until the system cleared a 98%+ expert-agreement gate, and the judgment stayed visible.
Is the team using it on an ordinary Tuesday, or have they gone back to the spreadsheet?
Knowing It Worked
The last test in the episode is the one buyers skip: how to tell, in month three, that the release worked and not merely that it runs. The answer to that is the baseline written down before anything was built — days from completed job to invoice, and the share of records that needed a person — plus the adoption observed in ordinary use.
When Waiting Is Correct
Two conditions stop the work, and neither is a lack of ambition. The first condition is ownership: until someone can set the completion rule, approve an exception and grant system access, there is no decision for software to support. The second condition is a planned system replacement that will remove the workflow's foundation. Confirm the migration path before building an integration that would need replacing the day it arrives.
First Steps
- Collect real records for the strongest candidate workflows, including the rejected and unresolved ones, because the exceptions are where the days go.
- Walk a single record through the whole of the handoff with its process owner and with the receiving team, writing down every wait and every decision.
- Choose one release that can be measured, write down its manual fallback, and name the person who will review whether the release deserves to grow.
One Handoff, One Baseline
Commission a bounded release around an observable handoff. Agree the baseline, access dependencies, acceptance conditions and operating responsibilities before implementation, and keep the first decision small enough that its result changes the next.
So the conversation ends on a rule instead of a recommendation for a tool: recurring volume, a consequence measurable today, an owner who can decide, and a release small enough to read. When the roadmap needs ongoing engineering alongside that first release, the AI engineering partnership is the scoped way to build, run and improve the system.
References
- U.S. Census Bureau. Large Firms With at Least 20 Employees Biggest AI Users. 2026.
- Singla, A., et al. The State of AI: How Organizations Are Rewiring to Capture Value. McKinsey, 2025.
