What Operations Mapping Looks Like Before Any Code
Short answer: Operations mapping is a structured conversation where I document how your business really works, step by step, including the rules nobody wrote down. You leave with a map, a decision tree of the rules and exceptions, and a clear view of what is worth automating. It happens before any code, because the build is only as good as the map.
Why map the process before building anything?
The most expensive automation mistakes I see are built on a wrong assumption about how the work happens. Someone describes the process from memory, a developer builds exactly that, and the first real order breaks it.
Mapping fixes the order of operations. First we find out what actually happens. Then we decide what to change. Only then do I write code. It’s the same approach behind the Xero invoicing automation and the SAP and Shopify integration for Bont Cycling.
What actually happens in a mapping session?
Each session is a conversation, not a workshop with sticky notes. I ask the people who do the work to walk me through it using a real example.
Take the invoicing process from the Xero automation I wrote about. I’d ask someone to open a real wholesale order and show me what they do next. Where do they look? Which spreadsheet do they check? What makes them decide an order needs an invoice, and what makes them skip it?
I’m listening for three things:
- The steps. What happens, in what order, in which system.
- The rules. The “if this, then that” decisions people make without thinking.
- The exceptions. What happens on a refund, a split payment or a partial shipment.
How do you find the rules nobody wrote down?
Ask what happens when it goes wrong. The rules people follow every day are invisible to them, but the exceptions force them to articulate them. “Oh, if it’s that customer, we always do it differently” is exactly the sentence I’m after.
In the invoicing example, the rules for which orders got invoices weren’t documented anywhere. They lived in one person’s head, which meant the process stopped when she was away. Surfacing that was valuable before a single line of code was written.
What is a decision tree and why does it matter?
A decision tree is the output that turns a conversation into something a system can follow. Each question has a yes or no answer, and each answer leads to the next step or to an outcome.
For invoicing, it might start with “Is this a qualifying order type?” and branch from there through payment status, customer type and refund handling. Once the tree is complete, the team can read it and say “yes, that’s what we do” or “no, you’ve missed something.” That review step catches problems while they are still cheap to fix.
What do you walk away with?
At the end you have:
- A written map of the process as it really runs.
- The rules and exceptions, usually as a decision tree.
- A recommendation on what to automate, what to leave manual and what to simplify first.
- An honest view of cost and value, so you can decide whether it’s worth doing. If you want to size that up yourself first, see how to work out what manual work really costs. The manual work calculator is a quick way to get a first number.
The map is yours to keep. Sometimes the right answer is a small change to a process, or a connection between two existing systems, not a build. I’d rather tell you that than build something you don’t need. That’s the thinking behind why integration often beats migration.
Does mapping make the build simpler?
Almost always. When the rules are crystal clear, the technical solution is far smaller than a vague “just automate it” brief would suggest. Fewer surprises mean fewer rebuilds, and the people who’ll use the system have already seen and agreed to how it behaves.
It also tells us what not to build. A lot of complexity in business software comes from handling cases that turn out never to happen.
Is operations mapping worth it for a small business?
If a process eats hours every week, yes. The mapping is the cheapest part of the project and the part that decides whether the rest goes well. You can read more about what this work covers on the services page.
Got a process that’s eating hours every week? Start a conversation and we’ll map it out together.
Frequently asked questions
What is operations mapping?
Operations mapping is the process of documenting how work actually moves through a business: who does what, in which system, in what order, and under which rules. It captures the real process, including workarounds, not the one written in a handbook, so you can decide what to automate.
How long does an operations mapping engagement take?
It depends on how many processes are in scope. A single workflow, like invoicing from online orders, can be mapped in a couple of working sessions. Wider engagements across several teams take longer. I scope the number of sessions up front so there are no surprises.
What do I get at the end of operations mapping?
You get a written map of the process as it really runs, a list of the rules and exceptions that drive decisions, usually as a decision tree, and a clear recommendation on what to automate, what to leave alone and what it should cost. It's yours to keep, even if I don't build the solution.
Do I need to prepare anything before a mapping session?
Not much. It helps to have the people who actually do the work in the room, and a recent example or two of the process in action, such as a real order or invoice. You don't need documentation or a technical background.
