Featured image: AI-generated conceptual illustration. Sources checked 26 October 2026.
A company asks for an AI agent because its operations team is overwhelmed. That is a buying signal, but it is not yet a specification. The work may involve unreadable documents, inconsistent policies, duplicate data entry, or a manager who must approve every exception. Each problem suggests a different solution. Selling implementation before discovering the bottleneck can leave both parties paying for an impressive interface that changes very little.
A workflow audit can be a useful paid service in its own right. Its deliverable is a defensible decision about what to automate, what to assist, and what to leave alone. The business model proposed here is a fixed-fee diagnostic, followed by a separately priced pilot only when the evidence supports it. There is no assumed income level and no promise that every audit produces an agent project.
Start with a completed task
Ask an employee to show one recent request from arrival to final resolution. Follow the actual records. Who received it? Which information was missing? Where was a number copied? Who checked the result? What happened after the customer replied? A process diagram built from this walkthrough is usually more useful than a list of applications the company owns.
Then examine an ordinary case, a difficult case, and a failed case. A routine invoice may take two minutes, while an invoice without a purchase order can sit for days. The waiting time might be caused by missing authority rather than slow data entry. An agent that extracts the invoice faster will not necessarily shorten the full cycle.
Write the unit of work precisely. “Improve accounts payable” is too broad. “Prepare an invoice record and route mismatches to the correct approver” is bounded. Record the trigger, required inputs, permitted actions, completion evidence, and owner. This task contract becomes the basis for both the audit and any later pilot.
Measure before estimating value
Use a representative sample of real work, with permission and appropriate data minimization. Record hands-on minutes, elapsed time, rework, error severity, and exception frequency. Ask workers what they had to do outside the visible system. Those hidden steps often explain why a simple integration has not solved the problem already.
Suppose, illustratively, a team handles 600 requests a month at eight hands-on minutes each. That is 80 hours of work. If a pilot could remove three minutes from 70 percent of requests, the theoretical capacity release would be 21 hours, before review and maintenance. This is a planning calculation, not proof of savings. A team may use that capacity to clear a backlog without reducing payroll expenditure.
Separate three value categories: cash costs that can genuinely be avoided, productive capacity that can be reassigned, and service improvements such as faster responses. Do not add them together indiscriminately. A faster response may improve retention, but the audit should not attach revenue to that possibility without supporting measurement.
Compare three solutions
For every promising task, compare a conventional rule, a bounded model-assisted workflow, and a more flexible agent. The simplest option may win. If an email always contains a standard order number and needs one lookup, a deterministic integration may be sufficient. If the request is ambiguous, a model might classify it while code validates the order and permissions.
Use autonomy only where it adds measurable value. Anthropic's linked architecture discussion distinguishes predefined workflows from systems that dynamically choose their steps. That distinction helps frame the decision, although its older tooling examples should not be treated as current implementation recommendations.
Create a short scorecard covering task volume, input variability, availability of authoritative data, reversibility, cost of error, and ability to verify completion. A high-volume task with accessible data and reversible actions is a stronger pilot candidate than an occasional negotiation involving undocumented commercial judgment.
Make the audit commercially clear
Price the diagnostic around its deliverables and scope. State the number of workflows, interviews, systems, and sample records included. Identify what the customer must supply and what happens if access is unavailable. An audit that promises unlimited discovery can become an unpaid implementation project.
A useful final package contains a process map, baseline measurements, opportunity ranking, assumptions register, and one pilot specification. Include rejected opportunities and explain why they were rejected. This demonstrates independence and gives the buyer something actionable even when no build follows.
Do not quietly make the audit fee contingent on recommending your own platform. If implementation revenue is part of the commercial relationship, disclose that incentive. The recommendation should remain understandable to another provider, and the customer should be able to use it without buying the next phase.
Define a stop condition
A pilot should stop when its required data cannot be accessed lawfully, when the customer cannot identify an accountable approver, or when the expected value is smaller than operating cost. It should also stop if the only plausible success metric is “employees liked the demo.” Positive feedback is useful, but it cannot substitute for task performance.
Before handing over, ask whether the proposed result can be observed independently of the agent's own message. A prepared record can be inspected. A routed request has an assigned owner. A supposed saving needs a documented calculation. This makes the audit a foundation for responsible purchasing rather than a sales presentation with an AI label.
Sources and evidence
NIST AI Risk Management Framework.
Research checked October 26, 2026. Business designs and illustrative calculations in this article are editorial proposals, not documented earnings or guarantees. Recheck current product terms before implementation.
Leave a Reply