Excel became infrastructure
A spreadsheet holds part of a critical process, and only one or two people fully understand how it works.
Process and workflow
Automate the steps that should be automated, and no more
A recurring process that runs on spreadsheets, email and memory does not need to disappear into a black box. It needs structure, clear ownership and automation where it genuinely helps.
When this is the problem
Signs a process has outgrown its tools
Progress lives in someone's inbox
The current state of a case is reconstructed from email threads rather than read from a system.
It does not scale with volume
Handling twice as many cases would mean roughly twice the manual effort, because nothing about the process is structural.
Relevant work
Process work we have delivered
Participation Tool
A guided process for building participation plans, where information is completed over time and the finished plan is generated at the end.
Read the Participation Tool projectMister Brightside
Subscription handling from signed deal through billing, plus a recurring two-year employee review that now runs on schedule rather than on a reminder.
Read the Mister Brightside projectBreakdown Service
Partner onboarding turned into a guided flow, with the handoffs that used to need manual follow-up handled by the system.
Read the Breakdown Service projectHow we work
Structure first, automation second
- Map decisions and handoffs.Including the exceptions people handle without noticing.
- Separate judgment from routine.Some steps should stay with a person, explicitly.
- Automate the routine.The repetitive, rule-based steps where the outcome is predictable.
- Make the state visible.So progress can be read from the system rather than reconstructed.
Questions we hear
Deciding what to automate
Which processes should not be automated?
Processes that change constantly, that run a handful of times a year, or where the real work is judgment rather than steps. Automating those tends to cost more to maintain than the manual version costs to run.
Is Make, Zapier or n8n enough?
For simple, low-risk flows they often are, and we will say so rather than sell you something larger. They get strained when a process needs custom business rules, has to handle failure carefully, or needs to be explainable months later.
Do we have to automate the whole process at once?
No, and it is usually a bad idea. Taking one slice, running it alongside the existing way of working and migrating gradually is lower risk and teaches you more about the process.
How do we judge the business case?
Look at how often the process runs, how much manual effort each run costs, and what a mistake costs when it happens. A process that runs constantly with a real error cost justifies far more than one that runs occasionally.
Related
Often part of the same conversation
Custom software development
When the process needs a proper application rather than automation around the edges.
System integrations and API connections
When most of the manual effort is moving data between systems.
AI in software and workflows
When a step involves reading documents, sorting or the same repeated judgment.
Software Discovery
Not sure yet what the right fix is? Start with a focused Discovery instead of guessing.
Bring a real process
Show us the process as it actually runs
Including the workarounds. Those are usually the most useful part of the conversation.
Let us look at the process