A department map is a mural. A workflow is a sentence.
The last chapter argued that Blank Collars are built or suppressed by what an organization selects, promotes, and pays for. That argument stays an abstraction until it touches real work. There is exactly one place to make it touch real work, and it is not an enterprise AI strategy or a platform decision. It is a single workflow, changed end to end, in a way you can watch happen. Training language does not produce the behavior this book describes. Changed work does. And changed work has to start somewhere small enough to actually finish.
Take the schematic the book has carried and finish it, so the whole method sits in one place. Label it the way I always have: a schematic, not a case and not a proof. A customer disputes a service renewal, says they tried to cancel, and asks for a refund. What the workflow exists to produce is a fair, defensible resolution the company can reconstruct later. The request passes through support, an approval owner, and billing. The exception is the disputed case the routine reply cannot settle. The AI boundary holds a line: a system may retrieve policy and draft the routine response, but it may not decide the fairness question or invent authority it was never given. The redesigned artifact is the approved procedure the routine path runs from, with the evidence of each decision traveling alongside it, so billing and any later reviewer can see why a refund was granted or refused. Verification is a named check on the routine output. The exceptions route to a person with the authority to decide them. And the previous routine owner, the one who used to work every refund by hand, now owns the pattern of the disputes and proposes the correction to the policy or the escalation rule. I claim no result for any of it. It shows the shape, nothing more. Now set the schematic down and pick up the workflow you selected back in Chapter 9, because from here that is the only live case, and everything below runs on its evidence, not the schematic's.
The finish line has three parts, and all three are required. The workflow produces a named outcome you can point to. A second qualified person, or a system, can restart it, run it, check it, and improve it without leaning on the current owner's memory. And the current owner has a stated next responsibility beyond the work that moved. Hit the first two, miss the third, and you have made the work inheritable and left a person standing in the gap. That is the incomplete transformation the last several chapters kept warning against.
Start by mapping the current state, and map it as decision points, not as a flowchart, because Chapter 12 already taught the excavation and this is the applied version of it. What triggers the work. What outcome it owes. Who owns it now. Which handoffs are consequential, meaning the ones where work changes hands and something can go wrong. What the real exception is, the case that refuses the standard path. What counts as evidence the work was done correctly. And the sharp one: what stops entirely if one particular person is away. That last answer tells you where the dependency actually lives, and it pays to check it against the org chart, because the two do not always agree.
Record decision points, not a department, because the specimen has to be small enough to change. A department map is a mural. A workflow is a sentence. Capture only the bounded thing: the trigger that starts the work, the outcome it owes, the handoffs where something consequential can break, the exception that snaps the standard path, the evidence that says the work finished correctly, and the continuity break, meaning what stops when one person is away. Six anchors, one workflow. Keep it a description of the work and never a verdict on the worker. A continuity break where one person holds a piece names a dependency in the design, not a fault in the person, and reading it as blame guarantees you will never get the honest map you need. Write the six down as they actually are today, before you change anything, because this is the baseline. Every claim you make later about the redesigned flow, that it is faster, safer, more inheritable, is a claim measured against this record. Without it, you have opinions about a change. With it, you have a before.
Look, before you assign any technology, delete or simplify one step. This is the discipline companies skip, and skipping it is expensive. A redundant step made faster is still redundant. A redundant step automated is redundant at scale, and harder to pull out later. Faster execution does not transform a step that should not exist. Find a step whose original reason may have expired, test whether that reason still holds, and where it does not, remove or simplify the step through the authority that owns it, before you spend a cent making it faster.
Now allocate the work, and be precise about the words, because the industry has turned these words into a ladder they are not.
Augmentation and automation describe who executes. AI is a capability that may support either. None of them is a maturity rank.
Augmentation keeps a person doing the work, with assistance. Automation transfers a stable, well-defined step so a system runs it. AI can support either, and it earns its place in exactly one kind of spot: where inputs vary and correctness can be tested. That is a narrower slot than the enthusiasm suggests. This is an allocation decision made task by task, not a sequence you climb, and a good redesign may use no AI at all. The question is never how advanced the workflow looks. It is which piece of the work each part is actually built to carry.
Describe the changed flow plainly. What happens now, who or what acts at each step, what evidence moves with the work when it changes hands, and where authority changes. That last one is where redesign gets real. A redesigned workflow almost always moves a decision across an existing organizational boundary: the routine call that used to wait for an approver now runs from the artifact, and the approver's attention shifts to the exceptions. Responsibility crosses the boxes on the chart. The chart does not vanish, and pretending it has is how redesign becomes chaos, but the work stops respecting the boxes the way it once did.
Three things have to travel with the redesign, or the actor changed and the workflow did not. Evidence has to move with the work: whoever, or whatever, receives a case gets the reasons and the record alongside it, so a decision can be reconstructed later instead of trusted blindly. Authority has to be explicit at every step: who may decide what, and where the boundary of that permission sits, written down instead of assumed from a title. And the previous routine owner's next responsibility has to connect to the exception pattern, so the person who used to work every case by hand now owns the disputes the routine cannot settle and the corrections they imply. Change the actor and leave those three relationships alone, and you have substitution wearing redesign's clothes: a machine drafting where a person drafted, the same evidence gaps, the same undefined authority, the same person left with nothing above the work that moved. The hierarchy stays. The boxes do not vanish. What changes is where a decision gets made inside them, and what travels with it when it does.
Then install the boundaries that keep the change safe, applying Chapters 13 and 14 rather than restating them. Name who verifies the output, and what evidence they inspect. Name the condition under which a case returns to a person, because a workflow with no exception path will run its exceptions as if they were routine, and that failure hides until one of the mishandled cases surfaces. And name how the old method gets restored if the new one fails, because a change you cannot roll back is a bet, not a test.
Four functions have to be covered, and I am naming functions, not launching a team. An outcome owner, accountable for the result. A practitioner who actually knows how the current work runs, including the exceptions nobody wrote down. Someone configuring the change. And an independent checker, or an affected user, who was not rooting for the change to succeed. One person can hold several of these where independence and safety are not compromised. In a small team where one person holds most of them, run the small-team discipline chapter fourteen gave the deployment record: separation in time, criteria written before judging, the self-review disclosed, an external or board-level check when the consequence warrants it. If real independence cannot be arranged, narrow the test until it is safe, or stop. Small headcount is not evidence of failure. It is a condition to design around.
The four functions matter because each catches what the others miss. The practitioner holds the exceptions nobody wrote down, and without that knowledge the configurer builds a clean version of a workflow that does not exist. The configurer turns intent into a working change, and left alone will optimize for what is buildable instead of what is needed. The outcome owner keeps the whole thing pointed at the result and answerable for it. And the independent checker, or the affected user, tests the change against reality instead of against the hopes of the people who built it. That tension is the point. Collapse it into one enthusiastic person and you get a change that verifies itself. Where a small team cannot staff four people, time separation and predeclared criteria do real work: judge the build on a different day than you built it, against standards written before you looked, and say plainly that you are reviewing your own work. And where meaningful independence cannot be arranged at all, narrow the test until it is safe, or stop, because a self-graded change is a guess with paperwork.
Run it as a bounded live slice, or as a safe simulation, and predeclare everything that matters before you start: the outcome, the baseline you are measuring against, the operating window, what is excluded, the condition that stops the test, and the protections for anyone affected. High-stakes work clears its privacy, labor, security, safety, and sector gates before it touches anything live, and a simulation is the right call wherever a live run would create undue risk.
When it is done, judge the whole result, not the flattering slice of it. Weigh quality, rework, how the exceptions were handled, whether escalation actually worked, the consequence for the customer or user, what the work felt like for the people doing it, and whether you could recover if it went wrong. Time saved is one item on that list, and it is the one most likely to get waved around as proof. It is not proof of transformation. A faster version of an unchanged workflow saves time too. End with a real decision: continue, revise, or stop.
Then finish the human side, the part that gets dropped, and the part that turns this into a transformation instead of a cost cut.
If the work moves but the person has nowhere to grow, the workflow may have changed. The human transformation has not.
State which repeatable responsibility actually moved off the person. State what judgment, or what unresolved problem, they now own instead. State what capability or access that new responsibility requires, because handing someone the exceptions without the authority or the information to resolve them is a setup, not a promotion. And state how the transition gets supported and recognized, through whatever legitimate mechanism your organization uses. I am not claiming the person becomes more valuable automatically for having handed their work over. The handoff made their old value portable. Whether they become more valuable depends on what they do with the responsibility on the other side, and on whether the organization actually handed them one.
Write the whole thing down as one compact decision record, in plain prose: the outcome, the old and the new boundary of the owner's responsibility, how verification works, who holds exception authority, what the human's next responsibility is, and the date you will review it. That record is a decision artifact, not a company grade, and it is kept deliberately small enough to stay honest.
One workflow is evidence of a beginning, not proof of a transformed company.
One changed workflow tells you the method works in your hands, on your evidence, once. It does not tell you the company is transformed, and treating it as if it did is how a genuine beginning curdles into an overclaim. But it does the thing the strategy deck never does. It produces a real decision. A real handoff. A real next responsibility. On live work, not on a slide. And it surfaces the next dependency almost at once, because the moment the routine runs without you, you see how often the exceptions, the approvals, and the conflicts still climb to one person at the top. That person is usually the leader, and their presence may now be the ceiling on everything you just built.
I have kept this method in the abstract long enough. What comes next is a first-person composite from work I have done more than once. It shows the sequence that shaped my practice. It is not a completed Company Card, a company assessment, or evidence that the framework produced an outcome.
A practitioner composite. One workflow, seen from inside
Everything that follows is drawn from work I have done more than once. I changed and combined identifying details, and no single company or person is represented end to end. The sequence is testimony about how my practice formed, not an instrument result. To run the framework, use the complete row schema, state rules, confirmation discipline, and stop gates in chapters nine and fifteen.
Let me stop describing the framework and show you the kind of job that taught me why those rules became necessary.
A services business calls me in because something in the back office is broken. Same story, nearly every time. There is a workflow, and it eats people. Reports, reconciliations, the monthly close, the thing that has to go out on the fifth and never goes out on the fifth. And before I arrive, they have already tried to fix it. They bought a tool. They ran a pilot. They hired someone clever. And here is the funny thing: they always tell me the same sentence. We tried this before, and it didn't work.
I believe them. It didn't work. But not for the reason they think.
The first thing I do is refuse to start with AI. I know that is what they bought me for. I don't care. Put intelligence on top of a broken base and you can get a faster broken base. So I begin with the work itself: what the organization says this function is for, what the records show, how the work actually moves, and how the people carrying it respond to change. Those observations are not yet Company Card readings. They tell me which artifacts to collect and which rival explanations still need to be ruled out.
Direction first. I ask one question and watch the room. What does good look like here? Not the target for this quarter. What is this function for. Often what comes back is silence, then four answers from four people who have sat beside each other for years. One says accuracy. One says speed. One says keeping the client calm. One says not getting yelled at. That disagreement is a reason to inspect the company's governing direction and the decisions made against it. It is not, by itself, a Vision state.
If the governing record confirms that direction is not deciding the work, then the organization has something real to repair. The repair is not a workshop sentence everyone can repeat. It is a direction that can refuse a proposal and a recorded decision showing that it did.
Then data. I always say the same thing here: the numbers are the only mirror you have. Your bank account, your dashboard, your error log, that is the company looking at itself. So I ask for the records behind the workflow, not the report about the records. Everyone may say things are fine while one source says the work goes out late two months in three. That disagreement tells me to trace the definition and lineage of the number. Only when two qualified readers attempt the same retrieval from the authorized record can the Data state be written.
Then process, and this is where I made my own mistake, so I will tell it on myself. Process is the nervous system of the place. It is the connecting tissue. And early in my career I believed that if there was a written process, a nice document, a flowchart, then people shared a definition of the work. They did not. I learned this the hard way. I would read the map, agree with the map, build on the map, and then watch the real work go a completely different way, because the map was what somebody wished happened, not what happened. Now I do not trust the map alone, and I do not trust the interviews alone. I pull the traffic, the system logs, the timestamps, the actual trail the work leaves behind, and I put it next to what the people told me. The two versions never fully agree, and the disagreement is the finding. The trail shows steps nobody mentioned and skips steps everybody swore by. But the trail is not the whole truth either. Logs only hold what the systems saw, and part of any real workflow happens beside the systems, in a hallway, in a judgment call, in a favor between two people who never wrote it down. So the map, the trail, and the people go into one room, and the three versions argue. The process that survives that argument is the real one.
And here is what the traffic has shown me often enough that I now look for it: many steps exist to repair a problem three steps earlier that nobody removed. The process is not a process. It is scar tissue. That is a pattern in the work that reaches me, not a law of yours, and there is a selection effect hiding inside it: companies whose process holds rarely make this phone call in the first place. The Company Card still has to establish the state from the map, the trail, the people, the rival explanation, and a confirming artifact.
Then the human experience, which is the one everyone skips. I will say it the blunt way I learned it: people rarely adopt a change merely because its designer calls it better. Their day was full before the transformation arrived. So I watch where the old route survives, what objection was raised, who was authorized to decide it, and whether the decision changed what actually ran afterward. The dirt path across the grass is useful evidence, but it does not explain itself. It may show poor fit, missing authority, a compliance requirement, habit, or a transition still in progress. The Human Experience reading comes from the objection, decision, and landing chain, not from ease or usage alone.
The machine is not a prize for finishing the first four questions, and AI is not a later fifth phase. If a deployment already touches the workflow, it belongs in the same inspection from the start: permissions, evaluation, routing, cost, fallback, human review, and whether anyone other than the builder can verify a run. My practical default is still to resist automating a process nobody has observed. The evidence can reorder the work, and sometimes the deployment itself is the confirmed constraint. What I refuse is the leap from a demo to a diagnosis.
And I do not boil the ocean. How do you eat an elephant? Piece by piece. I take the one step in the workflow that is the most repetitive, the most boring, the one where a smart person is doing something a machine does better and hates every minute of it, and I hand that one step to the machine. One. Then the next. Each piece, the person hands over the part that could be written down, and keeps the part that could not: knowing when the answer is confidently wrong, knowing which exception actually matters, knowing which client is about to blow up and why.
The ending people want from automation is a person who gets bigger as the routine gets smaller. Sometimes that happens. Reports that used to eat the month begin to run with less intervention, and the returned hours move into investigating why a number changed, learning the function next door, or checking the machine against domain reality. But the handoff does not guarantee that ending. It depends on a credible next responsibility, legitimate authority, learning, support, and recognition. Without them, the work may move while the person is simply left behind.
That is the sequence that shaped my practice, assembled from several engagements. It is not the framework run through once, and it establishes no state. The actual instrument is less fluent and more demanding: complete all five rows against the required scope, preserve rival explanations, confirm the finding before consequential action, and measure the outcome named before the work began. One human outcome matters greatly: whether the person received the conditions to outgrow the work while the work became inheritable. It is not the only outcome, and the composite does not prove it occurred.
I have watched parts of this shape work and watched parts fail. I got impatient and skipped the base to reach the interesting part faster. I have seen a sound base meet the wrong deployment, where the repair was replacing the machine rather than redesigning the company. I have seen a handoff stall when the person received thanks instead of a next problem and the old workflow quietly returned. That is the honest size of the testimony. It explains why the instrument contains the rules it does. The proof that matters is the evidence chapter fifteen showed you how to collect on one workflow of your own.