ModulesModule 4
Test a Better Workflow Before Adding AI
Chapter 4: Why AI Can't Save You.
The book is out in early 2027. The lesson below carries the chapter, so you can start now.
- 1ReadThe lesson, about 9 minutes.
- 2UseThe 4 tools, on one real situation.
- 3MeetA 60-minute working session with your team.
- 4Mark it heldThe module is done when the session happens.
In short
Module 4 of the free Heroes Don't Scale course, by Russ Reeder, turns Chapter 4, Why AI Can’t Save You, into work. Follow one real transaction from request to accepted result with the people doing and receiving the work, and name every step that exists only because of how the work used to be done.
Objectives
- Follow one real transaction from request to accepted result with the people doing and receiving the work, and name every step that exists only because of how the work used to be done.
- Repair the complete result before automating it.
- Leave the Operations First AI Gate with one of three authorized decisions: a bounded experiment, further repair, or no investment.
- Write the stop rule while the project is still popular.
Lesson
About 9 minutes to readThe scene
End of 2024. We were integrating ATSG and Evolve IP, the two companies that would become XTIUM, about 1,000 employees combined, and our AI engineering team had built something impressive: a ticket hydration system that added information to incoming support tickets so reps did not have to look it up by hand. By the start of 2025 the reps still weren't using it. In the weekly engineering standup, the engineers asked the head of customer support why. The head of customer support said, "I don't know why they're not using it. I haven't asked them." The video call went silent. We looked at one another on the screen.
The mechanism
The silence said more about how we had built the tool than about one manager. Managers had described the steps their teams already followed, and those steps shaped the build. The tool prepared a ticket faster, but the workflow underneath still depended on the same manual resolution work. The analogy I use is a tire that's almost flat. Take it onto the highway and the speed makes the problem more dangerous. Fix the tire before you add speed.
We asked the reps, then we almost started over. The rebuild took another 2 months, while reps kept looking up known issues and entering ticket data by hand. The second generation could resolve certain issues without a person touching the ticket: verify a user's identity and restore access to a locked account, restart a stopped application service, or retry a backup that had failed for a known temporary reason, then check the result and escalate when it couldn't finish. That meant deciding what the AI should finish, where it should stop, and when a person takes over. Those are operating decisions, not technical details. Looking up known issues and entering structured data had been part of the reps' contribution, and we were asking them to help a system take it over. Their value was making sure problems got fixed and customers were satisfied. The measure of the second generation was never that it shipped. It was how many tickets closed without a touch, how long resolution took, and whether tickets reopened.
The second scene
Lunch with Jamey Butcher, the CEO of Chemonics, and Tetyana (Tanya) Dudka, its chief operating officer. Their work had been disrupted by changes in U.S. foreign assistance, and they were using the pressure to push changes that might otherwise have taken years. The list of potential AI projects was long, and I heard a familiar risk: replacing existing applications with AI while carrying the current processes forward, the XTIUM pattern multiplied across a portfolio. A lower cost to build does not give a team unlimited capacity to run what it creates. The decision that came out of that lunch was a ranking: quicker wins with the higher expected return first.
The third scene
According to a 2018 Reuters report, Amazon's experimental recruiting tool learned from ten years of submitted résumés, most of them from men. By 2015, Reuters reported, the company had identified gender bias in ratings for technical jobs: the software downgraded résumés containing the word "women's" and those from graduates of two women's colleges. The lesson is not that the engineers ignored the problem. They found it, and the company ended the project. Giving a system part of a decision does not remove the owner's responsibility for the standard behind it: define what qualified means for the job, test whether the system measures it fairly, and name the person with authority to stop the experiment when the tests fail.
The tool
Draw the Workflow Repair Map with the people doing and receiving the work, following one real transaction from request to accepted result. Agree on a repair to test. Put the repaired workflow through the Operations First AI Gate and leave with one of three decisions before any money is committed: a bounded experiment, further repair, or no investment. Write the AI Stop Rule before release.
From your seat
If you fund the work, fund nothing until the people doing and receiving it agree on the outcome, what the system decides alone, and what would stop it. If you manage the team, ask them why they use what was built for them, or why they don't, before anyone calls it resistance. If you do the work, separate the tasks you perform from the value you deliver, write the steps you would kill if you were building the process from scratch, and bring that list to the build.
The line
Swapping a human hero for a software one leaves the dependency in place.
Tools
Module 4: Test a Better Workflow Before Adding AI. From the free course toolkit for Heroes Don't Scale.
Workflow Repair Map
WorksheetWith the people doing and receiving the work, follow one real transaction from request to accepted result. Name each handoff, duplicate entry, approval, delay, exception, and rework loop, and the control each one protects. Remove unnecessary steps without removing obligations the business still has to meet.
- Trigger
- Step
- Owner
- Input and source
- Decision rule
- Output and recipient
- Typical waiting time
- Common failure
- Control that must remain
- Proposed repair
Initiative: ________________________ Owner: ________________________ Date: ____________
Operations First AI Gate
WorksheetCompare the repaired workflow with and without AI. Identify the task AI might improve, where a person must decide, and the business result that would justify the full operating cost. Choose a bounded experiment, further repair, or no investment, with an owner, a decision date, and the person authorized to fund or stop it. The Production Gate in Module 12 comes after a pilot has run; its menu is scale, extend, redesign, or stop.
- Business outcome
- Current baseline
- Workflow owner
- Executive accountable for the result and adoption
- Approved data and access
- Task suited to AI
- Human decision boundary
- Quality and risk thresholds
- Full operating cost
- Expected benefit
- Existing capability we can use
- Evidence required before deployment
Initiative: ________________________ Owner: ________________________ Date: ____________
AI Adoption Cadence
Review actual use and results with the workflow owner and users, at a frequency that matches the risk and rate of work. Ask the people doing the work why they use the tool or avoid it, and confirm what their role is now expected to contribute. Compare the complete outcome with the baseline, including rework and support. Training attendance and licenses issued do not establish adoption.
AI Stop Rule
WorksheetSet stop rules before release for unacceptable errors, unsafe or unfair outcomes, access violations, control failures, or economics that do not support continued use. A tripped stop rule means repair, redesign, or stop.
- Condition that pauses use
- Person authorized to stop it
- Safe fallback workflow
- Notification path
- Repair owner
- Evidence and approval needed to restart
Initiative: ________________________ Owner: ________________________ Date: ____________
Working Session
60 minutesImprove the complete result before expanding automation. AI should reduce a real operating constraint, not make an unnecessary task faster or create another expert nobody can work without.
- People
- The workflow owner, representative users, the receiving owner, technical and relevant control expertise, the person responsible for ongoing support, and the executive who can authorize the test, its spending, and its data access.
- Bring
- One normal transaction and one difficult exception, already drawn on a Workflow Repair Map with the people doing and receiving the work, baseline outcome and waiting time evidence, existing tools, support capacity, and controls that must remain.
- 10
Where does the current work fail or wait?
Confirm the Workflow Repair Map with the people who drew it, following the transaction from request to accepted result. Locate the dependency and downstream burden, and mark every step that exists only because of how the work used to be done.
- 10
What should change?
Choose one step to remove or repair. Identify the obligation or control each approval protects before removing it.
- 15
Does AI belong in that change?
Compare repair alone, existing capability, and a proposed AI task. Set the human boundary and approved data access, and record the full operating cost or who will supply it by what date.
- 15
What will the test prove?
Define scope, representative cases, exceptions, baseline, quality conditions, and outcome evidence. Include rework and support demand.
- 10
Who can pause it and decide what follows?
Set the AI Stop Rule, safe fallback, repair and restart authority, adoption review, and decision date.
- Leave with
- One decision from the Operations First AI Gate in the VOOCS Operating Record (the one-page record from Module 5 that every session writes into): a bounded experiment, further repair, or no investment, authorized by the executive in the room. Use the Workflow Repair Map, AI Adoption Cadence, and AI Stop Rule as supporting views. If the decision is a bounded experiment, design it with the Commitments Before Scale Canvas in Module 12 and carry the Workflow Repair Map forward as the Production Workflow Map.
- Next check
- Have the recipient inspect the full result and users explain the changed work. Compare value, failures, rework, support, and cost with the baseline before expanding.
- If the work still stalls
- Task speed improves but the customer's result does not; difficult cases are excluded; nobody can run the fallback; training attendance substitutes for adoption.
Session kit: tools from other modules
Session 4 uses these tools from other modules. They are here so you can run the session from this page. Print worksheet prints them with the session.
From Module 5: Build the Operating Loop and Transfer Judgment
VOOCS Operating Record
WorksheetCopy this record for one initiative. Use role titles while designing the plan, then name the actual people before making a live commitment. Link to detail only where it supports a decision. Leave irrelevant fields out. If an answer is unknown, or the owner and sponsor give different answers, name who will resolve it and by when. Start with one recurring problem so the team can test the whole arrangement before expanding it; the book's illustrative locked-accounts record in Chapter 5 shows one filled in.
Header fields:
- Initiative
- Outcome owner
- Sponsor
- Date and next review
- Facilitator and recorder
Vision: What result are we building toward, and who benefits? Why does it matter now? Which priority does it serve? What are we choosing not to do?
Outcomes: What is the baseline, target, and due date? Which quality or risk conditions must hold? What evidence will show the result, and who will verify it?
Ownership: Who owns the outcome? Which decisions and resources can they control? What do dependency owners commit to deliver, and who resolves it when their other priorities compete with this work? What is reserved for someone else, and how quickly must that person respond?
Cadence: When will we review the evidence? Who will do what next, by when? Which decision must close before the work can proceed? Where will we record the decision and its result? If a commitment slipped, what condition changes before the new date?
Systems: What repeatable workflow, standards, and controls support the work? Where is the shared source of truth? Who has the access, training, and practice to provide backup? What evidence shows they can carry the work and recognize an exception without waiting for the original hero?
Decision check. Before closing, confirm: decision and reason; authorized owner; next commitment; due date; evidence and receiving person. If a gap remains, record its exact question, decider, evidence owner, and return date.
Module 7 deepens the Outcomes line and Module 8 the Ownership line. Every other tool writes into this same record, and the 90-Day Install follows it.
Initiative: ________________________ Owner: ________________________ Date: ____________
From Module 12: Give the Pilot a Path to an Operating Decision
Commitments Before Scale Canvas
WorksheetTest the riskiest assumption first, with the production owner, representative users, risk expertise, and the person who can approve the next investment. Agree on what could disprove value, data access, quality, economics, adoption, or safe operation. Before approving another build, compare the proposal with the tools the company already owns and the capacity its existing systems consume.
- Business outcome
- Riskiest assumption
- Baseline
- Test population and duration
- Success and failure thresholds
- Production owner
- Operating capacity required and work displaced (see A6)
- Conditional funding path
- Required controls
- Gate date
- Person authorized to scale, extend, redesign, or stop
A6 is the No List, in Module 6.
Initiative: ________________________ Owner: ________________________ Date: ____________
From Module 12: Give the Pilot a Path to an Operating Decision
Production Workflow Map
WorksheetThe work across teams, systems, and human decisions; carry a Workflow Repair Map from Module 4 forward to the state the pilot will run in, and show where AI decides and where a person takes over.
- Step
- Sender
- Receiver
- Control or human decision
- Acceptance evidence
- Failure route
- Accountable owner
Initiative: ________________________ Owner: ________________________ Date: ____________
The Hero Test for this chapter
THE HERO TEST: What are you making faster?
For the person at the top
Which process are you about to speed up that nobody has questioned, and which steps would survive if you built it from scratch?
For the manager in the middle
Have you asked your team why they use what was built for them, or why they don’t?
For the person the company waits on
Which of your daily tasks is the value you deliver, and which is only the task?
One action
If the decision is yours, fund nothing until the people doing and receiving the work agree on the outcome, what the system decides alone, and what would stop it. If it is not, write the steps you would kill and bring the list to the build.
Evidence of Completion
- One Operations First AI Gate decision in the VOOCS Operating Record: a bounded experiment, further repair, or no investment, with the executive who authorized it, the owner, and the decision date.
- The Workflow Repair Map for the transaction, with the repair to test, its owner, and the evidence that would show the result improved.
- The AI Stop Rule written before any release: the condition, the person authorized to stop, the safe fallback, and what it takes to restart.
- The adoption review on the calendar and a dated next check with the receiving owner. If the decision is an experiment, the Workflow Repair Map carried forward to Module 12 as the Production Workflow Map.