Document the Workflow Before You Automate It

Take a billing dispute. The written procedure might say: verify the customer, review the account, and resolve the issue. The person doing the job knows that “review” means checking the last two invoices in QuickBooks, comparing the contract in another system, looking for a note from sales on Slack, and asking a manager before applying one particular credit. None of that feels remarkable after the hundredth case. It still has to appear in the workflow.

OpenAI made the same point in its July 2026 description of Presence, an agent system used in customer operations: “production sessions and escalations reveal gaps.” Its billing example moves from identity verification to account lookup, policy application, and an approved action. A workshop can compress that whole sequence into “resolve the billing issue.” Observation cannot.

An insurance claims process that works on an ordinary Tuesday may come apart during a storm. Call volume spikes. Documents arrive out of order. Policy exceptions multiply. Customers repeat themselves because they are frightened and speaking to several people. Julie Batch, CEO of IAG’s Australian retail insurance business, described the goal of its customer agent as providing support during “high demand periods such as severe weather events.”

That detail changes the design. The team needs to observe the surge case, not only the average case. Who can authorize an emergency payment? Yup. We’ve all been there. The quintessential corporate answer-searching scramble. What happens when an address cannot be verified? Which promise must never be made automatically? The answers determine the escalation rules, the evidence shown to a reviewer, and whether the workflow should be automated at all.

You do not need to record every screen or read private messages to understand a workflow. Start with a defined task, a short observation window, and clear consent. Ask the person doing the work to narrate choices that would confuse a new colleague. Capture the tools they touch, the information they seek, and the points where they hesitate.

Privacy boundaries belong in the discovery plan. Exclude personal windows, redact customer data, and keep raw recordings for as little time as possible. A team will hide the messy parts if the research process feels invasive. That defeats the purpose.

Consider Maya Chen, a billing specialist at the fictional Acorn & Vale Office Supply. A customer says its renewal invoice ignored a discount promised by sales. Maya opens the ticket in Zendesk, compares the last two invoices in NetSuite with the signed order form in Salesforce, searches Slack for the salesperson’s promise, and asks her finance manager whether she can issue a $1,200 credit.

View full size

The four-step review is now concrete. Observe the dispute from the Zendesk ticket to the corrected invoice. Record Maya’s decisions, including the credit threshold and the cases that need finance approval, without capturing unrelated messages. Confirm the map with Maya and her manager, who may remember an exception she missed. Then delete the screen recording and keep only the redacted workflow map, approval threshold, and exception list.

A useful workflow map answers a small set of concrete questions. What starts the work? Which system holds the source record? Who changes it? Which output proves completion? The map also names the person who handles exceptions, because an automation without an exception owner creates an unattended queue.

Handoffs deserve special attention. OpenAI’s analysis of more than 800,000 work-related ChatGPT messages found that 43.5% of occupation-specific requests involved tasks normally associated with another occupation. A salesperson explores a customer dataset. A marketer troubleshoots a website. Work already crosses role boundaries, so a useful map has to record who owns the next step rather than assuming the job title tells you.

A five-minute task can spend two days waiting in an inbox. The automation opportunity may have little to do with the task itself. Routing, reminders, prefilled context, or a clear approval state can remove more delay than automating the judgment step.

The technical boundary is moving quickly. Vercel’s August 4 release gave its eve agents a browser that can navigate pages, read content, click controls, fill forms, and take screenshots. Domain allowlists and protected credentials limit where an agent can go and keep saved login details away from the model.

That makes a previously awkward workflow possible: open the CRM, check a customer record in a vendor portal, search for a duplicate, request a missing tax ID, and return the final status to the CRM. It does not tell the agent which record is authoritative, when a partial match counts as a duplicate, or who should see the tax document. Those rules still have to come from the people doing the work.

Each observed action should become one of four things: a deterministic rule, a human decision, a data requirement, or an exception. That classification keeps teams from asking a model to guess where the business already has a rule. It also exposes rules that conflict across departments.

Jason Robert, a principal software engineer at Microsoft, puts the governance requirement plainly: “Human oversight should be a built-in workflow step, not something you bolt on later.” In practice, that means naming the reviewer, defining the conditions that trigger review, and deciding what evidence the system must present.

The first version should preserve that evidence. If a system drafts an update, show the source fields. If it routes a request, record the rule it used. If confidence drops, send the item to a named person with enough context to decide. These details are harder to add after the team loses trust.

The best first automation often removes a dull handoff: collecting missing information, preparing a record for review, or reminding the next owner. Those changes create visible gains without asking the system to make a sensitive decision on day one.

Observation gives you a baseline as well. You can measure wait time, corrections, repeated lookups, and manager intervention before the build starts. Later, the team can see whether the workflow improved instead of relying on a vague sense that work feels faster.