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 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 six minutes.
I wrote the conversation to be argued with. The position in it is mine, and the objections are the ones I would want a buyer to raise before signing anything. What follows is the written version: the rule the conversation arrives at, the objections that changed it, and the three things 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.
Broad 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 describes how many firms report using something. It does not describe whether one workflow in any of them improved, so it cannot tell this operator to fund all three requests at once.
Consequence, Volume, Owner
The rule the conversation builds 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 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 toward the workflow around it (McKinsey, 2025). It reports an association, not a promise for your operation. Your own baseline and your own observed adoption still 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 is that configuration comes first. If a setting in the field-service system can require the technician's photograph before a job closes, that is a Monday task and it needs no engagement.
Custom software earns its place in the gap between systems — the handoff that lives in email and a spreadsheet because no product owns it. That distinction is worth making before a first call, because it decides whether there is a project at all. A clear no is one of the legitimate outcomes of that conversation.
Small Enough To Read
Scope is where a first project loses its meaning. If a release touches nine teams and six systems and the numbers move, nobody can say why. If it touches one handoff, the result points at what to fund next. For the partnership, that boundary is written down: one prioritized delivery lane, starting with one workflow, up to three roles and two integrations, with each release agreed before work begins.
The same section of the conversation covers where a person stays involved. Automate the repeatable match, route every uncertain case to a named person, and keep the record of each decision. The voluntary AI risk-management framework is useful background for thinking about a system across its lifecycle (NIST, 2023). In the clinical billing work ML LABS delivered, claims did not move until the system cleared an expert-agreement gate of 98% or better — 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 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 adoption observed in ordinary use.
Use the governance, data, performance and monitoring questions as an external lens on that report (GAO, 2021). The framework was written for federal agencies and other entities; it is not evidence that your business meets an assurance standard. Its separation of concerns keeps an accuracy score from becoming the whole operating report.
When Waiting Is Correct
Two conditions stop the work, and neither is a lack of ambition. The first 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 is a planned system replacement that will remove the workflow's foundation. Confirm the migration path before building an integration that would need replacing on arrival.
Supplier practice deserves the same scrutiny before approval. The secure software development recommendations give you a vocabulary for asking how a system is built and maintained (NIST, 2022). Ask for evidence that fits the system instead of accepting a framework name as proof.
First Steps
- Collect real records for the strongest candidates, including the rejected and unresolved ones, because the exceptions are where the days go.
- Walk one record through the whole handoff with its process owner and the receiving team, writing down every wait and every decision.
- Choose one measurable release, document its manual fallback, and name the person who will review whether it deserves to grow.
One Handoff, One Baseline
Commission a bounded release around the handoff you can observe. Agree the baseline, the access dependencies, the acceptance conditions and the operating responsibilities before implementation begins, and keep the first decision small enough that its result changes the next one.
That is why 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.
- Tabassi, E. Artificial Intelligence Risk Management Framework 1.0. NIST, 2023.
- U.S. Government Accountability Office. Artificial Intelligence: An Accountability Framework. GAO-21-519SP, 2021.
- Souppaya, M., Scarfone, K., and Dodson, D. Secure Software Development Framework Version 1.1. NIST SP 800-218, 2022.
