Process Documentation
Documenting Multi-Step Workflows That Span Multiple Tools
The most valuable process in your company is probably the one nobody can write down. Onboard a new customer: open the CRM, check the contract in the billing tool, create an account in the product, send invites, update the dashboard, log it. Of the whole business, this workflow crosses four or five apps, a couple of tabs, and at least one place where a human "knows" the next step without it being written anywhere.
These multi-step, multi-tool workflows are exactly the ones where a stale or missing SOP does the most damage — and where generic templates fail hardest. This guide covers what breaks in cross-tool documentation, how to capture one accurately, and how to shape it so both your newest hire and your AI agent can follow it.
Why Cross-Tool SOPs Break Defaults
Ask most people to document a workflow and they write it as prose with occasional screenshots. That works until the workflow crosses a tool boundary, and then it falls apart for a specific reason: the reader has to re-orient on every handoff. In a single app, step 8 naturally follows step 7. Across apps, you have to describe not just the action but the switch — "copy the order ID, open the shipping portal, paste it in, click look up." The missing links are precisely these transfers of context.
Those handoff steps are also the first to go stale, because they depend on UI details that change. When the shipping portal renames "look up" to "find order," the single-tool steps are still fine but the cross-tool link is broken, and the whole procedure reads wrong. If you've wrestled with why procedures drift, the mechanics are the same set of forces described in our piece on why SOPs go stale — cross-tool workflows just concentrate them at every boundary.
Capture the Real Run, Not the Memory of It
The single biggest mistake in documenting a multi-tool process is writing it from memory. Memory smooths over the awkward parts — the exact dropdown, the copy-paste of a value, the name of the second account. When you write from memory you produce a plausible summary, and plausible summaries are exactly what a trainee can't follow the first time.
The fix is to capture the process while it actually runs. Record the screens as you perform the workflow in the live tools, note the value that moves between each app, and then transcribe the sequence from the capture rather than from your head. Because these workflows live mostly in the browser — CRM, billing, the admin panel — a browser-based recorder is the natural fit. We covered which tools mount that kind of capture in our roundup of the best workflow recording tools for AI agents.
A captured run also gives you the exact UI labels and paths — the elements that go stale first. A screenshot at each major handoff is worth more than a paragraph of prose, because the reader compares the screen in front of them to the screen in the doc. If you're weighing how visual to make your procedures, our guide to visual SOP documentation lays out the trade-offs.
Structure a Multi-Tool SOP Around the Transitions
Once you have a faithful capture, structure it around where context changes hands. A strong cross-tool SOP looks like:
- Start conditions: what must be true before you begin (logged into which accounts, which tab is open, which record is selected).
- Steps grouped by tool: all the steps inside App A, then App B, so a reader isn't ping-ponging.
- Explicit handoff lines: "Copy the customer ID from the CRM header, then open the billing tool and paste it into Search." These are the lines your structure makes unmissable.
- The value that travels: name the thing being carried between apps, because that's the actual unit of the process.
- Error and decision paths: what to do when a value isn't found, or when a step has branches.
The mental model to hold onto: the workflow is a chain, and the links are the handoffs. Get the start conditions and the handoffs exactly right, and even a tool-heavy SOP becomes followable on the first pass.
Make It Executable by an AI Agent
There's a second consumer of this documentation now: AI agents. Claude Code and Claude Cowork act on documented workflows by loading them as skills — instructions, typically in a SKILL.md file, that tell the agent what a task means and how to do it. If your SOP is prose buried in a wiki, an agent can't reliably act on it. If it's a clean, step-oriented procedure, it becomes something an agent can (almost) follow.
This is why the cross-tool SOP and the AI skill are converging. A well-structured, handoff-explicit procedure is most of what a SKILL.md needs. If you're new to the format, our explanation of what a SKILL.md file is connects the dots between written procedures and agent-executable instructions, and our comparison of SKILL.md versus MCP servers shows how the two approaches fit in an agent setup.
The practical takeaway: document the workflow once, in a structured form, and it pays off twice — your team follows it today, and tomorrow's agent uses it as the basis for a skill. That's the direction the whole process-documentation field is moving, and it's a strong argument for capturing at the source rather than hand-typing prose. Everything you want an assistant to be able to do eventually starts with an accurate, current, step-by-step record of how the work actually happens — the same record we've been describing for your team all along.
Capture the whole cross-tool workflow in one run
Claudia records your browser workflow as you run it — across apps and tabs — and exports structured documentation your team and your agent can both follow.
Add to ChromeFAQ: Multi-Step Workflow Documentation
What's the hardest part of documenting a cross-tool workflow?
The handoffs — the point where a value or context moves from one app to the next. These are the least visible steps, the first to go stale, and the easiest to omit when writing from memory. Structure your SOP to make each handoff an explicit, bolded line.
Should I record the workflow or write steps by hand?
Record the real run, then shape the transcript. Writing from memory produces a plausible summary that omits exactly the details a newcomer — or an AI agent — needs. Capturing at the source keeps labels, paths, and handoffs accurate.
How do I stop my cross-tool SOP going stale?
Keep review cycles short (quarterly for high-change tools), group steps by tool so a UI change is easy to spot, and re-capture the screen when an app changes rather than editing prose blind. Staleness concentrates at tool boundaries, so treat those as the places to re-verify.
Can an AI agent really run a multi-tool workflow from documentation?
Fully end-to-end, not yet reliably — agents still need well-formed skills and often manual sign-off at sensitive steps. But a clean, configured, handoff-explicit SOP is exactly what becomes a SKILL.md, so documenting it well today puts you in position as agent automation matures.
Multi-tool workflows are the highest-leverage documentation you can write and the easiest to get wrong. Capture the real run, structure around start conditions and handoffs, and record the value that travels between apps. Do that and you'll have a procedure a newcomer can follow on the first try — and a foundation an AI agent can build a skill on tomorrow. Start with the one workflow your team asks about most.