Map the Work Before You Automate It

Most AI projects I see start with a tool. Someone has a license, a demo, or a mandate from leadership, and the question becomes where to point it. The workflow it's supposed to improve gets described in a sentence or two and then left alone.

That's where things go wrong. Teams automate the process on the slide, and the process on the slide is rarely the one people run.

I recently watched an episode of Greg Isenberg's Startup Ideas Podcast with Vasuman Moza, CEO of Varick Agents, about how his team deploys agents inside large companies (watch it here). He comes at the problem as a builder. I come at it from product experience. We end up in the same place. Most of the hard work in an AI project happens before anyone builds an agent.

The documented process is a draft

Every organization has a written version of how work moves. A quote gets built, reviewed, approved, sent and signed. Five tidy boxes.

Then you sit with the people doing it. The quote goes back to the start when a discount is off. Legal sends it back. Someone keeps a spreadsheet because the CRM can't handle one contract type, and now that spreadsheet holds up the whole process. The exceptions that "rarely happen" happen every week.

Moza's team finds the real process three ways: interviews with the people who do the work, data from the systems they already use, and whatever documentation exists. Each source misses something on its own. In the interviews, he says, you're trying to learn why things are done the way they are and who really decides. One line from the episode stuck with me: "Which step is theater? Which step is legitimate?"

That is research work. UX researchers and service designers have done it for years with contextual inquiry and service blueprints. The question has grown. We used to ask where people get stuck. Now we also have to ask which steps a machine could take over and which ones it shouldn't touch. I've written about this as a workflow problem, not a feature problem. This piece is about what to do once you decide to map the work.

I've had my own version of that gap. We had AI-generated access rules that looked clean in review. The policy checked that someone had been a member of an organization. It did not check that the membership was still active. During a routine security pass, we found users could read data from organizations they had already left. On paper, the rule was "members only." In the code, it was "anyone who was ever a member." That is the kind of gap mapping is supposed to catch before anyone scales the automation.

Sort every step into four buckets

Once you have the real workflow, every step goes into one of four buckets. Moza's team uses this sort with clients. It's simple, and it holds up.

• Delete it. Some steps exist only because of an old system, an old policy, or one person's habit. Automating them makes waste run faster.
• Turn it into rules. If the step is "when this happens, do that" with no judgment involved, write plain code or a configured rule. Rules are cheap, testable and predictable. An agent here adds cost and new ways to fail.
• Give it to an agent. Agents earn their place where judgment is needed and there's enough history to judge from. Categorizing a messy invoice line. Drafting a first-pass quote from similar past deals. Routing a request that doesn't fit a template.
• Keep it as a human decision. Approvals, payments, negotiations, and anything where a wrong call is expensive or hard to undo. These stay with a named person.

Don't be surprised if the delete and rules buckets fill up first. Cleaning those up can help before any model is involved.

The human decisions are a design problem

This is the bucket I care about most, and it usually gets the least design attention.

When an agent does the work up to a decision, the person making that decision changes jobs. They used to build the thing. Now they review it. Reviewing well needs a different interface. They need to see what the agent did, what it was unsure about, what evidence it used, and what happens if they say no. A bare approve button with a wall of generated text behind it will get rubber-stamped within a few weeks.

A good decision point answers a handful of questions on one screen. What am I deciding? What did the system check, and what did it skip? What changed since the last version? What does it cost if I get this wrong? Who sees it if I push back?

Those are UX questions about hierarchy, trust, error recovery and accountability. If a team puts all its effort into the agent and none into the moment a person signs off, the riskiest step in the workflow ends up as the least designed one.

After that near miss, I stopped treating "someone will look at it" as a control. I built a two-tier review for AI-generated code: a short checklist before a commit, and a fuller gate before production. The short list forces a clear verdict, safe to commit or fix first. The fuller gate ends with a risk score and an explicit ship or no-ship call. That is a designed decision surface. It aims review where a wrong call is expensive, instead of asking someone to rubber-stamp a wall of generated text.

Put the work where people already are

Moza's team builds agents inside the systems a company already runs on, like the CRM, the ERP and Slack, instead of asking anyone to adopt a new AI tool. Companies have spent years and a lot of money getting onto those systems. A pitch that starts with "first, switch platforms" loses the room.

From a UX view, this is about adoption. A new surface means new logins and one more place to check. If the agent's output shows up as a record update in the CRM, and the approval arrives where the approver already works, people get the benefit without changing how they spend their day. Before designing any new AI screen, ask whether the work could land somewhere people already look. Often the new dashboard is the expensive option.

Most of the time is lost between steps

When people picture a slow process, they picture slow steps. Usually each step is quick. The time goes into the gaps: sitting in a queue, waiting on an approver who's out, waiting for someone to notice a handoff, coming back because a field was missing.

Michael Hammer made this point in 1990, in his Harvard Business Review article "Reengineering Work: Don't Automate, Obliterate." Writing about insurance applications at Mutual Benefit Life, he noted that most of the time went to passing information from one department to the next. He also cited another insurer's estimate that an application spent 22 days in process and was worked on for 17 minutes.

The trap hasn't changed. Make each step faster with AI and the end-to-end time may barely move, because the waiting was never inside the steps.

So when you map a workflow, measure the gaps as well as the steps. Mark every handoff. Note how long work sits there and why. Count how often it loops back to an earlier step. Those numbers usually point to the real fix, and sometimes the fix is removing a handoff rather than adding an agent.

Where to start

Pick one workflow that matters and that someone owns. Map how it runs today, using the people, the system data and the documents. Mark the handoffs and the waits. Sort every step into the four buckets. Write down a baseline before anyone builds anything, so you can tell later whether it worked. Then give the human decision points the same design care you give the agents.

If you're about to fund an AI build and nobody has mapped the workflow yet, that's the decision I help product leaders work through. The Consulting page explains how that works. I review fit before we book time.

References

1. Isenberg, G. (host), with Vasuman Moza. Startup Ideas Podcast. October 2026. YouTube.
2. Hammer, M. "Reengineering Work: Don't Automate, Obliterate." Harvard Business Review, July-August 1990, pp. 104-112.