Automation multiplies whatever you point it at
Updated: Jun 24
Point it at a clean, well-run process and it compounds the gains. Point it at a messy one and it compounds the mess, around the clock, with no one watching. The difference between an automation that pays for itself and one that becomes shelfware is rarely the software. It's the operations work that happens before and around it. The rule is simple: document first, automate second.
No one buys automation because they want software. They buy it because something is slow, error-prone, or eating their team's time, and they want that to stop.
The promise is real. The right automation gives a team back hours, removes the mistakes that come from re-keying the same data into three systems, and lets a business grow without adding headcount in lockstep. We build those systems for a living, and when they land, they massively change how a company operates.
So, here's the uncomfortable question worth asking before you spend a dollar on tooling: why do so many automation projects land with a thud? They get scoped, built, and launched, run for a few months, and then quietly get worked around until the old manual habits creep back in. The budget was spent. The pain came back.
Almost always, the reason isn't the tool. It's that the process underneath was never ready to be automated. Getting it ready is the part most teams underestimate, and it's the part that decides whether you get a return at all.
THE TRAP
A bad process doesn't get fixed by automating it
Automation is a multiplier, and multipliers work in both directions. Point one at an efficient process and it compounds the gains. Point it at an inefficient one and it compounds the inefficiency, faster and more reliably than any person could, all day, every day, with no one watching.
Most processes look fine from the org chart and fall apart up close. The version written in the SOP hasn't matched reality in years (shocker, right?). The one step that actually keeps things from breaking lives inside a single person's head. Work waits in inboxes between hand-offs, gets re-entered into multiple systems, and loops back for rework that nobody measures. None of that is visible from a distance. Automate on top of it and you haven't fixed anything; you've made the flaws permanent and given them a schedule.
Document first, automate second. Treating the software as the last step, not the first, is unglamorous, and it is the entire game.
The principle behind every automation that pays off
THE CLIMB
Where automation actually starts
Every operation we work with sits somewhere on the same climb: from work that runs on memory and heroics, up to work that runs on documented, optimized, automated systems you can actually measure. Most teams sit lower on the mountain than their leaders think, and that's not a knock on the team. The next move up is genuinely hard to make from the inside.
The order is not negotiable, and it's why we tell every client the same thing: document first, automate second. You can't standardize a process you haven't documented, can't meaningfully optimize one that isn't standardized, and shouldn't automate anything you haven't optimized first. Skip a stage and the automation inherits every flaw you skipped past. The reason most teams stall at the lower camps isn't capability. It's that climbing requires a kind of distance from the work that's almost impossible to get while you're the one running it, sounds familiar?
THE FIRST MOVE
Start by documenting the work as it really is
Of the five stages, documentation is the one you can start on your own. It's the foundation every stage above depends on, it costs nothing but attention, and most teams learn more about their operation in the week they spend mapping one process than in the year before it. So here is how we do it, and how you can begin today.
A process you can eventually automate is one you've described precisely enough that a careful stranger could run it without asking you a single question. That takes seven things. We'll use one example throughout: a company's invoice approval.
The trigger
The exact event that starts the process, and how you'd recognize it without a human deciding. "An invoice arrives by email" is a trigger. "When we get around to it" is not.
The actors and their handoff
Every person, team, or system that touches the work and, more importantly, the moment it passes between them. Handoffs are where time and accuracy go to die, far more than the steps themselves.
The steps
The real actions, written verb-first: capture, match, route, post. Not "process the invoice," which hides four steps inside one polite word.
The decisions and the rules behind them
Every fork in the road, plus the logic that decides which way it goes. "Approve if PO matches and amount is under the manager's limit" can be automated. "Use your judgment" cannot.
The systems and data
Where information lives, what shape it's in, and whether a machine can read it. A structured field in your ERP is automatable. A figure buried in a PDF attachment is a project of its own.
The exceptions
The off-script paths: the duplicate invoice, the missing PO, the vendor who emails the wrong department. This is the 20% of cases that breaks 100% of naïve automations, so it has to be documented, not waved away.
The numbers
Volume, cycle time, and rework rate. Three hundred invoices a month at eleven minutes each is a business case. Three a quarter is a hobby. The numbers tell you what's worth automating at all.
Capturing all of that in prose is hard, because a written list of steps reads as a tidy straight line even when the real process loops and bounces between people. So, we draw it. A simple swimlane map gives each actor a lane and lets the workflow left to right; every time an arrow crosses lanes, that's a hand-off, the exact spot where work waits or gets dropped.
THE METHOD
How to document a process in five passes
You don't capture all seven elements in one sitting. You build the picture in layers, and you build it from reality, not from the way the process is supposed to work.
1
Pick a process with a clean start and a clean end
Scope it to one trigger and one clear outcome: "invoice received" to "payment scheduled." Vague boundaries are why most mapping efforts sprawl and stall. If you can't name the start and the finish in one sentence each, the scope is wrong.
2
Document the as-is, not the as-imagined
Capture the process as it actually runs today, including the ugly parts. Watch the work happen rather than asking people to describe it. What people say they do and what they actually do are reliably different, and the difference is usually where the friction lives.
3
Walk it backward from the output
Start at the finished result and ask, "what had to happen right before this?" all the way back to the trigger. Working backward exposes hidden inputs and silent approvals that a forward walkthrough glosses over.
4
Make every decision rule explicit
For each fork, write the rule as if/then. Where the honest answer is "it depends," dig until you find the real criteria, or flag that step as one that needs a human. Unwritten judgment is the single most common reason an automation can't be built.
5
Validate with the people who do the work
Walk your draft map back to the operators and the exception-handlers. They'll catch the missing branch and the step you compressed. A map the team can't recognize is a map you can't automate against.
Do this for one process and you've made the first real move up the climb: the work is finally visible, and the waste is impossible to unsee. The harder, more valuable question comes next, and it's the one most teams get wrong on their own.
NOTE: You also don't need fancy notation to begin. The easiest map is a straight line: lay the steps out left to right, mark the one or two points where the process branches, and you can already see the shape of the work. Here is the same invoice process drawn the simple way, before any lanes or roles are added.
THE WORK
What it takes to make a process pay off
A documented process is the on-ramp, not the destination. With the work finally visible, the decisions that decide your return begin, and most of the value lives in the judgment, not the map.
The line that matters most is this: what to trust to software, and what to keep with a person. Some work is high-volume, rule-based, and fed by clean data, and that's where automation earns its keep. Other work turns on judgment, relationships, or messy inputs, and forcing software to fake that judgment is precisely how automations fail. The catch is that most steps don't sit cleanly on either side.
WHERE THE EXPENSIVE MISTAKES HIDE
Most steps in a real process look routine but hide a judgment call, or look messy and turn out to be a few simple rules once you pull them apart. Sorting the obvious cases is easy. Sorting the ambiguous middle and knowing which exceptions to automate around versus design for, is the difference between an automation that pays for itself in a quarter and one that quietly becomes shelfware. That call comes from having made it across dozens of operations, not from a template.
Only once the process is lean and agreed do we encode it, into a workflow platform like Smartsheet, an integration across your existing systems, or a custom build, and instrument it so you can prove it worked. By that point, the software is the easy part. The hard, valuable work happened before anyone opened a tool.
THE PITFALLS
Where these projects go wrong
We get called in most often after an automation has already stalled, and the pattern is consistent. Each of these is obvious in hindsight and nearly invisible from inside the team that made it:
X Documenting the ideal instead of the real. The SOP describes a process that hasn't existed in years; automate that and it breaks on contact with reality.
X Buying the tool first. The platform gets chosen before anyone understands the process, so the process gets bent to fit the software instead of the other way around.
X Skipping the exceptions. The edge cases feel like noise until they're the reason the rollout fails. They're signal.
X Automating before optimizing. A very efficient version of a broken process is still a broken process, now harder to change.
X No baseline numbers. Without before-and-after data, you can't prove the automation worked, or justify the next one.
X Treating it as an IT project. Automation that isn't owned by the people who run the work gets quietly abandoned the moment it hits an exception.
Every one of these is easy to avoid once you've watched it happen. The expensive part is that most teams only see it the first time, after it has already cost them a quarter.
THE PAYOFF
What it's worth when it's done right
Done in the right order, the results are concrete, which is the whole point. Cycle times drop because work stops waiting between hand-offs. Errors fall because data is entered once instead of three times. Your team gets its hours back for the work that actually needs a human. And because the process is measured before anyone touches it, you can see the gain in the numbers rather than just feeling it, and build the case for the next process with evidence.
That's the real prize, and it compounds. The first process you climb pays for itself. The discipline you build getting there makes every process after it faster, cheaper, and lower-risk to automate. Operations stops being the thing that holds growth back and starts being the thing that lets it scale.
Work with us
Start with one process
Pick a process that frustrates your team. We'll map it end to end, show you exactly where the time and money leak, and tell you what's worth automating and what isn't, before you invest a dollar in tooling. You'll see what good looks like on your own operation, not a sample one, and you'll know precisely where you sit on the climb.
Comments