Apollo missions were plotted on what's called a free-return trajectory. The path swings the spacecraft around the Moon and brings it back toward Earth on physics alone, even if the engines fail. When an oxygen tank exploded on Apollo 13, the crew didn't have to invent a way home. The way home had been plotted before launch, and the job in the room became getting the ship back onto it.
Nobody added that route after the explosion. It was designed into the mission before anyone lit a rocket, because the planners didn't know what would go wrong and wanted the answer to be survivable anyway.
Most AI rollouts launch the other way round. The tool arrives first, with a demo and a license count, and the thinking about how it fits the way the office actually works happens afterward, if it happens at all. Workflow redesign is the plotting. It's the unglamorous work you do before launch so the thing you launch has somewhere to go.
What workflow redesign means
Workflow redesign is walking through how a piece of work actually gets done today, scrubbing the steps that only exist because of how things used to be, deciding who or what handles each step that's left, and then checking that the new version helps the people doing the work, all before anyone chooses a tool.
The method I use with clients is the Walkdown: four moves, borrowed from the way NASA engineers get a spacecraft ready to fly. Walk it, question it, crew it, check it. Technology doesn't enter until the third move, and only for the steps that survived the second.
It doesn't need to be a consulting deliverable with a hundred boxes on it. For most teams the first Walkdown fits on a single page and takes an afternoon.
To pick which workflow to walk first, the AI Opportunity Score takes about three minutes and points you at the one costing your team the most hours.
Why the tool can't go first
AI is very good at doing what a process tells it to do, and that's the trouble. Hand it a process with a re-keying step in the middle and it will re-key faster. Hand it a process where the same information gets hunted down in three places and it will hunt faster. You end up with a quicker version of the thing that was wasting your team's week, plus a new system somebody now has to maintain.
Most of that waste comes from a short list of sources. Re-keying the same data into a second system. Chasing people for information that should have arrived on its own. Hunting for things that live in more than one place. Checking work that was already checked. Rebuilding documents from scratch that look almost exactly like last month's. Those five sit underneath Admin Drag, and a smarter tool doesn't fix any of them. A decision that the step shouldn't exist does.
I've skipped this part myself, and I'd rather say so than pretend otherwise. My one serious attempt at building an agent in Zapier turned into an automation that got more tangled every time I touched it, until I walked away. The software was fine. I'd never decided what the work was.
Where the Walkdown comes from
A walkdown is an old engineering habit. You go over a system end to end, in person, looking for anything loose, missing, or not supposed to be there, before it's too late to fix cheaply. NASA's lessons-learned library carries a lesson whose title is the whole idea: conduct a final mechanical walkdown prior to spacecraft integration with the launch vehicle. Before the spacecraft goes on top of the rocket, somebody walks it.
The rest of the method comes from NASA's Systems Engineering Handbook, where the agency writes down how it engineers a mission. Three ideas in it travel surprisingly well to an office. The design work usually starts from a description of how the system will actually be operated. Every requirement carries its reason, because, in the handbook's words, "often the reason for the requirement is not obvious, and it may be lost if not recorded as the requirement is being documented." And every function gets allocated to whatever should carry it: hardware, software, or a human in the loop.
To be clear about the borrowing: NASA builds spacecraft, not renewal workflows, and nobody at NASA runs this four-move version. What I took are the habits that make their machines trustworthy, stripped of the engineering vocabulary.
The four moves
Walk it. Pick one piece of work your team does every week and follow it from start to finish as it actually happens now, including the ugly parts. Who starts it, what they need, where they go to get it, which system it gets typed into, who checks it, and what goes out the door at the end. Write the real version rather than the one in the procedures manual. If you've never done this, How to Document a Process Before You Automate It walks through it in a single sitting.
Question it. Every step has to state its reason, the way every NASA requirement does. When the answer is "that's the way we've always done it," you've found a step whose reason got lost, and that's worth flagging every time you hear it. Some steps will turn out to have a good reason that nobody wrote down, and they stay. Anything that exists because two systems don't talk to each other, because somebody got burned once years ago, or because nobody remembers why, gets scrubbed. This is the move people want to skip, because it can mean telling a colleague that something they've done carefully for years doesn't need doing.
Crew it. Only now does technology enter the conversation. For each step that's left, decide who carries it. A person keeps anything that needs judgment or a relationship. A simple automation takes anything that's identical every time. An AI agent takes the reading, drafting and sorting that's too varied for a rule. Then give every step that isn't a person a named human who owns what it produces, and write down the one decision it never makes. That's what turns a pile of tools into a Digital Crew.
Check it. NASA keeps two checks separate: verification, which proves the thing meets what was specified, and validation, which proves it does the job it was meant for in the real world. Ask both. Does the new version do what you said it would? And a few weeks in, do the people doing the work say it actually helped? If the answer to the second is no, you're back to walking it, and that's normal. Skipping this move is how a promising pilot quietly becomes Pilot Purgatory: the tool worked, nobody checked whether the work got better, and the old process slowly took it back.
A Walkdown in an agency
Take certificate of insurance requests, which most commercial lines agencies handle and almost nobody enjoys. Walked honestly, one request might go like this. It arrives by email, sometimes to a producer who forwards it on. A CSR opens the client in the management system, reads the contract the requester attached, checks the additional insured wording against what the policy actually carries, generates the certificate, sends it, and logs the activity.
Question it, and the forward gets scrubbed first, because requests should land in one place. The coverage check against the contract survives easily. Getting additional insured wording wrong can turn into an E&O problem, and that's the reason on file.
Crew it, and an AI agent is well suited to reading the request and the contract, pulling out what's being asked for, and laying it beside what the policy says, so the CSR starts from a comparison instead of a blank screen. The check itself stays with a licensed person. The certificate still comes out of the management system the way it always has.
Check it, and the question after a few weeks is whether the CSRs feel their time has moved from typing toward judging, which is the part of the job they were hired for. If it hasn't, walk it again.
That's an illustration rather than a case study, and your version will look different. The pattern shows up in real agencies, though. When Mike Welker at Insurance Center of Utah built his carrier report pipeline, it took him four or five versions over about sixty days, and what changed each time was how clearly he understood the work.
Where it sits, and what it doesn't promise
Workflow Redesign marks a turn in how an organization thinks about AI. It's the point where it stops asking which tool to buy and starts asking what the work should be. Teams that have made the turn usually have two or three redesigned processes running, each with a named person who answers for the result.
One honest caveat. A Walkdown doesn't always end with AI. Sometimes the right answer to a badly built process is to scrub two steps and change nothing else. That's a real win, and it will never make a good demo.
Where to start
Pick the task your team complains about most and run the first two moves on one page before anyone opens a new tool. Walk it, then put a reason next to every step. The steps where nobody can write one down are where your first redesign lives.
If you'd like to see where your team's hours are actually going before you change anything, take the AI Opportunity Score. It takes about three minutes, shows you how many hours a week your team could get back, and gets you a starter crew member built for the biggest one.
Frequently asked questions
Is the Walkdown a NASA method? No. It's inspired by NASA engineering practice: the walkdown a team does before a spacecraft goes on its rocket, and the Systems Engineering Handbook's habits of recording the reason for every requirement, allocating each function to hardware, software or a person, and keeping verification separate from validation. The four-move version is ours.
How long does a first Walkdown take? For most teams, the first one fits on a single page and takes an afternoon. Pick one process your team runs every week rather than trying to walk the whole agency at once.
Do you need AI to run a Walkdown? No. Technology doesn't enter until the third move, and sometimes the right answer is to scrub a couple of steps and change nothing else. The Walkdown decides whether AI belongs in the work before anyone buys anything.
How is a Walkdown different from documenting a process? Documenting is the first move. Walk it captures how the work really happens today. The Walkdown then questions every step, crews what's left, and checks the result with the people who do the work.
Who should run a Walkdown in an agency? Someone who owns the outcome, with the people who do the work in the room. They know the ugly steps the procedures manual leaves out, and they're the ones who can answer the Check it question honestly.
