We’ve written about what the Foundation Client Program is, and walked through what one build looked like. This post is the roll-up: the patterns that showed up across the early builds, including the ones we got wrong.
Three things came up often enough that they’ve changed how we run a build.
The time saved was rarely where the client expected
Every engagement starts with a conversation about which process hurts most. Owners are usually very clear on the answer — and they’re usually pointing at the wrong thing.
What they nominate is the task that annoys them personally. What actually costs the business is almost always something duller and more frequent: the five-minute copy-paste that happens eleven times a day, the status update someone writes out by hand every afternoon, the double-entry between two systems that nobody thinks of as a task because it’s just how the job works.
The annoying task is memorable. The frequent task is expensive. Those are different problems, and only one of them is worth automating first.
So we stopped taking the nominated process at face value. Before scoping anything, we now ask the person doing the work — not the person who owns the business — to note what they actually touched over a few days. It’s a small step and it has reordered the priority list nearly every time.
Every build hit an exception we hadn’t mapped
We map the process before building. We’ve written a whole post arguing you have to. And every build still ran into a case the map didn’t cover.
A customer who pays by a different method. A job type that skips a step. A supplier whose invoices arrive in a format nothing can read. None of these were hidden — they just didn’t come up, because the person describing the process genuinely doesn’t think about the exception until it lands in front of them.
The lesson wasn’t “map harder”. Past a point, more mapping produces diminishing returns and a lot of documentation nobody reads. The lesson was to build for the exception from the start: the automation handles the cases it recognises, and anything it doesn’t recognise goes to a human with a clear note saying why.
An automation that quietly guesses on the edge cases is worse than one that handles eighty per cent and flags the rest. The first kind erodes trust the moment someone finds a wrong entry. The second earns it.
Handover mattered more than the build
The technical part of these builds is rarely the hard part. Getting a workflow to move data between two systems reliably is a solved problem.
What decided whether an automation was still running two months later was whether someone inside the business understood it. Not could rebuild it — understood it well enough to know what it does, what it doesn’t, and who to call when something looks off.
Where we handed over a working automation and a short explanation, it stuck. Where we handed over a working automation and a diagram, it held until the first exception and then someone quietly went back to doing it manually “just for this one”.
That’s the thinking behind the ownership point we made a fortnight ago, and these builds are where it came from. Handover is now part of the build, not a thing that happens at the end of it.
What we’re changing
Three adjustments, all small:
- Scoping starts with a few days of observation, not just the initial conversation
- Every build ships with a defined path for the cases it can’t handle
- Handover includes a walkthrough with whoever will own the process day to day
None of this is dramatic. Automation work that lasts rarely is — it’s mostly about being honest regarding how a business actually operates, rather than how it looks on a process diagram.
The Foundation Client Program is still deliberately small, for exactly this reason. If you’ve got a process that’s eating hours a week and you’d rather it didn’t, get in touch — spots are limited.