The client is a general contractor with a few hundred active jobs in any given month. Their admin team handled a workflow we will call subcontractor change order intake. A field super would phone in or text in a change. The admin would log it, validate it against the contract, route it to a project manager, draft the response, attach the right documents, and post the result back to the system of record.
When we first walked the workflow, the admin lead pulled up a Visio file with 25 numbered boxes. The cycle time on a typical change order was 18 minutes from intake to closed. Volume was 60 to 80 changes per day across the team. The math was a three-person admin function spending most of its day on this one workflow.
The team did not need the workflow eliminated. They needed it compressed. The judgment calls (whether to push back on a sub, whether to escalate to legal) had to stay with humans. The drafting, validation, document attachment, and posting did not.
Mapping the 25 Steps
We grouped the 25 steps into five buckets based on the work they actually did.
Capture (steps 1 to 4). Receive the change request from the field, log basic identifiers, attach to the right job, and set initial status. This was four steps that produced a structured record.
Validation (steps 5 to 11). Look up the contract on file, find the relevant clause, check whether the change was within scope, check whether the requesting sub had pending issues, check the budget headroom, check the schedule impact, and flag anomalies. Seven steps that all involved looking things up.
Routing (steps 12 to 14). Determine the right project manager, set the priority, and notify. Three steps of decision plus communication.
Drafting (steps 15 to 21). Draft the response email, attach the relevant contract clause, attach the budget extract, attach the prior change order if it amended the same scope, format the response, queue for review, and send. Seven steps of producing output.
Posting and close (steps 22 to 25). Update the system of record, mark the change order closed, log the cycle time, and archive supporting documents. Four steps of bookkeeping.
Once the steps were grouped, the question got simpler. Which buckets are pure rules, which buckets are pure judgment, and which are mixed?
What We Compressed
Capture compressed from four steps to one. The field text or call hit a transcription endpoint that produced a structured record automatically. The admin no longer typed anything to log a change. They saw a queue.
Validation compressed from seven steps to zero clicks. An agent looked up the contract, the clause, the budget, the schedule, and the sub's history in parallel and produced a one-paragraph summary with the key signals flagged. The agent did not make the decision. It just gathered the evidence the admin would have gathered manually.
Routing compressed from three steps to one. The agent's recommendation included a default project manager based on job assignment and current load. The admin clicked confirm or override.
Drafting compressed from seven steps to one. The agent drafted the response email with the right attachments already pulled from the project record. The admin clicked review and send (which was one click) or edited if needed. About 80% of drafts went out unedited.
Posting and close compressed from four steps to zero. Once the response was sent, the system of record updated automatically and the cycle time logged itself.
The four clicks that remained were the four moments that genuinely required human judgment: confirm the change is what the field said, confirm the routing destination, review the draft, and send. Everything else became evidence the human reviewed in seconds, not minutes.
The Math
Cycle time dropped from 18 minutes to 90 seconds. The compression came from two places. The pure-mechanical work (validation lookups, drafting, posting) disappeared. The judgment work (routing, review, send) compressed because the admin saw evidence already organized rather than gathering it.
What did not change was the headcount. The client was clear from the first meeting that they wanted capacity, not layoffs. The admin team kept their seats and absorbed the next 18 months of business growth without adding a fourth admin. By the math we ran, the workflow paid for itself in 11 weeks.
What also did not change was the policy boundary. The agent never sent an email without the admin's review. It never updated the contract record. It never escalated to legal on its own. Every action with consequence had a human in the loop. The compression came from removing the work between the consequential moments, not from removing the moments.
What We Did Not Compress
Three steps survived intact, by design.
The escalation path stayed manual. When a change order had legal implications (work outside the master contract scope, indemnification language changes, or any reference to a litigation matter), the workflow stopped and routed to the project manager and legal counsel. We did not automate the decision to escalate. We just made it easier to recognize when escalation was warranted.
The relationship judgment stayed manual. Some subs had history that made certain change orders sensitive (a difficult sub asking for more, a long-time partner asking for less than they should). The admin team had years of context the agent did not have. We surfaced the context and let humans decide.
The exception loop stayed manual. About 8% of change orders did not fit the standard pattern and could not be processed by the agent. The agent flagged these for full manual handling. The agent's job was to be honest about what it could not do.
What This Looks Like in Other Industries
The pattern is not unique to construction. We have run the same compression on legal intake (estate planning paralegal workflows), on finance close (variance analysis and reporting), and on professional services (engagement onboarding). The numbers vary. The pattern does not.
Map the steps. Group by what work each step actually does. Compress the rules-based steps to zero clicks. Compress the lookup-based steps to evidence presented to a human. Keep the judgment steps in human hands. Measure cycle time and throughput, not step count.
For more on how we use AI agents to enforce process without removing the human, see our AI agents enforce process page. For the deeper case study with project context, see contractor admin automation case study. For the related pattern in operations diagnostics, see our 30 day operations diagnostic.
The 25 step process did not become a 4 click workflow because the steps disappeared. It became a 4 click workflow because the work that did not need a human stopped requiring one.