There's a tempting shortcut in automation: skip the documentation, build a rough version fast, and let the failures show you where the process is broken. It feels efficient. Why spend a week diagramming a workflow when you could just wire something up and watch what happens?
Sometimes that's exactly right. Most of the time it isn't. After running this play across a lot of service businesses, our default is clear — document first, then automate — but the exceptions are real and worth knowing. Choosing wrong costs you either weeks of wasted mapping or a half-built automation that quietly does the wrong thing. Here's how we decide.
Why documenting first usually wins
When you automate a process, you encode it. Whatever steps, exceptions, and assumptions exist get baked into the build. If those steps live only in someone's head — or worse, in three different people's heads who all do it slightly differently — you're encoding confusion at speed.
Documenting first surfaces the things nobody says out loud:
- The "oh, except when the client is on a retainer, then we skip that step" rules.
- The handoffs that depend on one person checking an inbox twice a day.
- The steps that exist only because they always have, and could be dropped entirely.
That last point matters more than people expect. A surprising share of the work in any process is there for reasons that no longer apply. Mapping it out lets you delete before you automate. Automating a wasteful process just makes the waste faster.
Documenting first also protects the part of the work that should stay human. When you can see the whole flow on one page, it's obvious where judgment lives — which approval actually needs a person, where a relationship would suffer if a bot handled it. You design those checkpoints in on purpose instead of discovering them after a client gets an email they never should have received.
This is why our method starts with Scope. Before we connect a single tool, we map what the process really is, agree on where a human stays in the loop, and write it down. That document becomes the blueprint, and because everything we build is fully documented, you keep it.
When a rough prototype is the better teacher
Documentation has a limit: it captures what people think happens, not always what actually happens. For some processes, the fastest way to learn the truth is to build a rough version and watch it run. A quick prototype is the better teacher when:
- The process is genuinely undefined. Nobody can describe it clearly because it's improvised every time. Here, a prototype gives you something concrete to react to — it's easier to fix a draft than to invent a spec from nothing.
- The volume is low and the risk is low. If a mistake is cheap and easy to catch, you can afford to learn by doing. An internal notification that pings the wrong channel is a quick fix. An invoice sent to the wrong client is not.
- You're testing whether the integration is even possible. Sometimes the real question is "can these two tools talk to each other the way we need?" A throwaway prototype answers that in an afternoon, before you invest in mapping a flow that might not be buildable.
- The team disagrees about the steps. When two people describe the same process differently, a working draft cuts through the debate. Everyone watches the same thing happen and the disagreement resolves itself.
The key word is rough. A prototype is a learning tool, not a launch. It runs on test data or in a contained corner, a human watches every run, and the lessons feed straight back into the documentation. You're not skipping the map — you're gathering the information to draw it accurately.
How we actually decide
We run a few quick questions before any build:
- Can someone describe the process end to end? If yes, document it and confirm the edge cases. If no, a prototype may teach faster.
- What does a mistake cost? High cost or client-facing means document first, always. Low cost and internal gives you room to experiment.
- Is the goal to define the process or to test feasibility? Defining favors documentation. Feasibility favors a quick prototype.
- How stable is the process? Something that changes constantly is worth observing before you commit a design to it.
In practice it's rarely all one or the other. A typical engagement documents the parts that are well understood, prototypes the one or two genuinely fuzzy steps, then folds what the prototype taught back into the final design. The map and the prototype aren't rivals — they're two ways of finding the same truth, and good builds use both.
The mistake to avoid
The failure mode isn't choosing the "wrong" method. It's treating a rough prototype as if it were finished — letting the throwaway version creep into production because it sort of works. That's how you end up with an automation nobody fully understands, doing something slightly wrong on every run, with no documentation to fix it.
Whichever path gets you there, the destination is the same: a process you understand completely, automated deliberately, with a human in the loop wherever judgment belongs, and documented so well you'd be fine if we walked away tomorrow.
If you're staring at a messy process and not sure whether to map it or just build something, that's a conversation we have all the time. Walk us through it and we'll tell you honestly which way we'd go — and why.