The high priests of complexity.

There is a great deal of money to be made right now in making this look harder than it is.

Not by lying. Nobody has to lie. It's enough to answer a simple question with a complicated answer, to use six words the client doesn't know, and to let the resulting silence do the work. The client concludes that the problem is beyond them — which is exactly the conclusion that makes them hire someone, keep paying them, and never quite feel able to ask what they're paying for.

This is not new. Every technology wave produces a priesthood: people whose position depends on the thing staying mysterious. What's different now is the speed. The vocabulary changes every few months, which means nobody outside the field can tell the difference between a person who's keeping up and a person who's keeping you confused.

The incentive is structural, not moral.

Most people doing this aren't cynical. They're responding to incentives that all point the same way.

A firm billing for implementation makes more from a custom build than from telling you to buy a product for $40 a month. A firm billing hourly makes more from a system that requires them to maintain it. An internal champion who has staked a promotion on an AI initiative cannot come back and say the answer was a policy change. And a vendor whose product is a hammer will, reliably and sincerely, diagnose a nail.

None of that requires bad faith. It just requires nobody in the room being paid to argue for less.

What "less" often looks like.

In operating businesses — the ones with real revenue, real customers, and processes that grew rather than being designed — the highest-return interventions are frequently unglamorous:

• A product that already exists. Mature, supported, tested by thousands of companies, with a support line you can call at 2am. Custom software you must maintain forever is a liability you've been sold as an asset.
• An incentive change. If the weekly report is always late, look at whether anyone is measured on it before you automate its production. Some of the highest-return changes we've recommended cost nothing to implement.
• Deterministic software. Rules engines, scrapers, scheduled jobs, validation logic. Twenty-year-old technology that runs the same way every time, costs nearly nothing, and never hallucinates. A surprising share of what gets pitched as AI is a job for a scheduled task and a regular expression.
• Writing the process down. Often the actual deliverable. You cannot automate a process nobody has specified, and the act of specifying it frequently reveals that three of the seven steps exist because of a decision made in 2011 that nobody has revisited.

None of this means the sophisticated version is never right. Sometimes it is, and when it is, it's worth doing properly. The point is that the decision should be made on the merits, by someone who would genuinely have been willing to recommend the cheap answer.

Four questions that expose it.

You don't need technical knowledge to run these. Ask them in the first meeting.

"What would it take to remove this piece?" Point at any component. A person who designed the system can tell you what depends on it and what would break. A person who added it because it's what everyone builds will give you a reason that sounds like a brochure.

"What's the cheapest thing that would get us 70% of this?" Everyone has an answer. The question is whether they'll say it out loud, and whether they treat it as a serious option or as a strawman to dismiss.

"What happens when this is wrong?" Every one of these systems is wrong sometimes. Someone who has actually run one in production will describe error rates, review queues, and what the person on the other end does about it. Someone who hasn't will tell you it's very accurate.

"Explain that again, without the vocabulary." This is the one that matters most. Anything real in this field can be explained plainly to a smart person who works somewhere else. If it can't be, one of two things is true: they don't understand it well enough to simplify it, or they don't want to. Both should end the meeting.

The test that runs in the other direction.

The uncomfortable corollary: restraint is only credible from someone visibly capable of the complicated version. "You don't need this" from someone who couldn't build it anyway is not advice, it's a limitation being described as a philosophy.

So ask for both. Ask what the ambitious version would look like, in detail, and see whether they can describe it precisely — the failure modes, the cost, what would have to be true for it to be worth it. Then ask what they'd actually recommend, and why it's different. The gap between those two answers is where you'll find out whether you're talking to an advisor or a priest.

Buy, build, or change the incentive.

A crew of field technicians won't file expense reports. The mobile app has been deployed twice. There have been two memos and one meeting. Receipts still arrive as text-message photos sent to the office manager, who types them into the accounting system on Friday afternoons.

There are three real answers to this, and almost every firm you talk to will only offer you one of them.

Answer one: buy the tool and force the behavior.

Deploy a proper expense platform. It's mature, it's supported, it handles receipt capture, approvals, card reconciliation, and the accounting export. It costs a few dollars per user per month and it will work correctly forever without you maintaining anything.

The catch is in the second half of the sentence: and force the behavior. This answer requires fourteen field technicians to change how they've done something for years. That's not a software project, it's a management project, and it succeeds or fails on whether the owner will actually enforce it — including with the two best technicians, who are the least replaceable and the most resistant.

Answer two: build something that meets them where they are.

Keep the texting. Build a system that receives the messages, reads the receipts, extracts vendor, amount, date, and job code, matches them against the card feed, and posts coded transactions into the accounting system — flagging anything it isn't sure about for the office manager to resolve in a queue.

Nobody has to change anything. Adoption is guaranteed, because adoption already happened years ago. The cost is that you now own a system: it needs maintenance, it will break when a carrier changes a message format, and somebody has to be responsible for it in two years.

Answer three: change the incentive and buy nothing.

Ask why the receipts are late rather than how to process them faster. Sometimes the answer is that reimbursement takes three weeks, so nobody is in a hurry. Sometimes it's that the job code isn't knowable at the moment of purchase, so the technician is being asked to supply information they don't have yet. Sometimes the process is simply nobody's job.

Change the reimbursement cycle to weekly, or move coding to the person who actually knows the job code, and the problem can quietly disappear without any software at all. This answer is the one least likely to be offered by someone selling software, and it is more often correct than that industry's revenue would suggest.

The variable that decides it.

Notice that the three answers are not distinguished by technical merit. They're distinguished by one question, which is a question about your business rather than about technology:

How much behavior change can this team absorb right now?

That number is real, it's finite, and it's usually much smaller than owners think. It's also a budget you're spending elsewhere — if you've just changed the pay structure, or brought in a new ops manager, or moved to a new scheduling system, there may be nothing left this quarter.

A proven tool that your people won't use is worse than a rough system built around what they already do, because the first one costs you money and credibility while the second one at least works. Equally, a custom build you'll maintain forever is a bad trade when a mature product would have been accepted without complaint.

Say it out loud.

The failure mode isn't picking wrong. It's picking without noticing you were choosing.

Most implementations pick answer one or answer two silently, based on what the vendor happens to sell, and the behavior-change cost never appears in the business case. Then adoption fails, and everyone concludes the technology didn't work — when what actually happened is that a management decision got made by default, by someone who wasn't in a position to make it.

So we write it down. For every candidate on the roadmap: what we'd buy, what we'd build, what we'd change instead, what each costs, and how much behavior change each one asks of your people. Then the owner decides, on the record, with the tradeoff visible. That's a decision. Everything else is a drift.

Why your pilot produced a slide deck.

Somewhere in your industry, a company ran a pilot last year. It went well. The demo impressed everyone. The consultants presented a readout with a projected ROI. And today, nobody at that company uses it.

This is the normal outcome. Not because the technology failed — it usually worked fine in the demo — but because of four structural decisions made before the pilot started, each of which guaranteed the result.

Pilots are scoped to demonstrate, not to carry load.

A pilot's success condition is a good demo. So it gets built on the twenty cleanest examples: the well-scanned invoices, the standard work orders, the accounts with complete records. The messy 30% — the faxed statement, the handwritten field note, the account that exists twice under two spellings — is excluded as "out of scope for the pilot."

But the messy 30% is the job. That's where the handling time is, where the errors are, and where the person you're trying to help spends their afternoon. A system that handles the clean 70% doesn't reduce anyone's workload; it adds a triage step. The person still has to look at everything to decide what the system can handle. You've automated the easy part of their day and left them the worst of it.

Nobody instruments a pilot.

Production systems get dashboards. Pilots get anecdotes. When nobody logs every run, captures every correction, and publishes an error rate, the decision at the end has no evidence to rest on. The champion says it went great; the skeptic says it made a mistake once; both are working from memory. The safest executive decision in that meeting is to not decide — which is what "let's extend the pilot" means.

Nobody was brought along.

The people who would have to live with the system saw it in a demo and got a training deck by email. Nobody sat next to them during a real week of work, watched where it got in the way, and adjusted it. So at the first inconvenient moment they went back to the spreadsheet, which never fails and never surprises them.

Adoption is not a rollout phase that happens after the build. It's most of the build, and it's the part that gets cut when the timeline slips.

Nobody owns it.

Ask who owns the pilot and you'll get a committee: the consultant built it, IT hosts it, an ops person sponsors it. Ask who fixes it when the invoice format changes in January, and the room goes quiet. A system without a named owner decays at the speed of its most fragile integration — usually about six months.

The alternative is not a bigger pilot.

It's a smaller production system. One workflow, chosen because it's boring, high-volume, and reversible. Deployed into real work on day one, with a human reviewing every output. Instrumented, so the error rate is a number on a dashboard rather than an argument in a meeting. Shaped around how the team already works. And owned — by a named person inside your business, trained on a written runbook, before the builders leave.

The uncomfortable summary: a pilot is a way of not deciding. If you're not willing to put something into production with a human safety net, you haven't found the right workflow yet — and that's a selection problem, not a technology problem.

What accuracy actually means for document extraction.

A vendor tells you their extraction is "98% accurate." That sounds like an A+. Here is the arithmetic they're hoping you won't do.

Field-level vs. document-level.

A carrier statement, an invoice, a work order — each is not one answer but many. A typical commercial invoice might carry 30 fields you care about: vendor, date, PO number, line items, quantities, rates, tax, total. "98% accurate" almost always means per field. The number you actually live with is per document — the odds that a document comes through with every field right:

At 98% field accuracy, roughly 45% of your documents have at least one error in them somewhere. If a document with one wrong field is a document a human must fix — and in billing, it is — your "98% accurate" system requires review of every document, and you've saved the typing but kept all of the checking. Sometimes that's still a good trade. But it's a very different promise than "98%."

Confidence is the tool that changes the economics.

Good extraction doesn't just output a value; it outputs a value and a confidence. That turns one queue into two:

High-confidence output flows straight through, spot-checked by sampling. Low-confidence output goes to a human review queue, presented next to the source document so the check takes seconds rather than minutes.

Now the operating question stops being "how accurate is it?" and becomes "what review rate can I afford?" — a question about your business, not about the technology. If a person can clear 60 flagged documents an hour and you process 4,000 documents a month, a 20% review rate costs about 13 hours of skilled review per month against, typically, several hundred hours of manual entry displaced. You set the confidence threshold to hit the review rate you can staff — and you tighten it for fields where an error is expensive (rates, totals) and relax it where an error is cheap (a memo line).

Measure on your documents. Only yours.

Any accuracy number measured on someone else's documents is marketing. Scan quality, form variety, handwriting, seasonal volume spikes, the carrier that redesigns its statement every January — these are properties of your paper, and they dominate the result. The honest procedure: take a few hundred of your real documents, including the ugly ones. Have the system extract them. Have a person mark every field right or wrong. That number — measured on your documents, at the field level and the document level, before anything is trusted — is the only accuracy figure that should appear in a business case.

If a vendor resists measuring on your documents before quoting a number, that tells you the number.