Workflow audit
The first stage, on its own, at no cost.
How we work
Understand the work, then build around it
Discover, design, build, improve. Each stage ends with something you can hold, and you can stop after any one of them.
The short answer
A CanAutomate engagement runs in four stages. Discovery maps how the work actually happens and produces a written record of where the time goes. Design decides what gets automated, what stays a plain rule, and where a person keeps signing off — delivered as scope, system design and risks before any code exists. Build puts it into production inside the tools you already run. Improve watches it under real conditions and adjusts, because early automations always meet cases discovery missed. You can stop after any stage, and the deliverable from that stage is yours regardless.
- 01
Discover
We sit with the work as it actually happens, not as the process document describes it. That means talking to whoever does it, watching where it stalls, and counting how often it happens. Most of what makes automation fail is discovered here or not at all.
A written map of where the time goes
- 02
Design
We decide what should be automated, what only needs a plain rule, and where a person should keep signing off. You see the design, the scope and the risks in writing before anyone writes code, and you can disagree with it cheaply at this point.
System design, scope and risks
- 03
Build
We build into the tools you already run, in your accounts, with credentials you control. Human review stays on anything carrying money, legal or reputational weight. The failure path is built before the working path.
A working automation, in production
- 04
Improve
We watch what it does under real conditions and adjust. Early automations always meet cases discovery missed — that is expected rather than a fault, and it is why the engagement does not end at handover.
Measurement and revisions
Four principles we do not bend
These are the choices that decide whether an automation is still running in a year, and they are not negotiable per project.
- The failure path first
- What happens when the automation is unsure, or a system is down, is designed before what happens when everything works. Teams trust systems that fail visibly and safely.
- You can stop at any stage
- Each stage ends with something you can hold. Some clients take the discovery map and fix the process themselves. That is a good outcome.
- Rules over models where possible
- A model is used where the input is genuinely ambiguous. Everywhere else, a rule you can read and change is cheaper, faster and identical every time.
- No lock-in by construction
- It runs in your environment and it is documented well enough that another developer could take it over. Nothing should only work while we are involved.
What we need from you
Short list, and most of it is attention rather than effort. Being clear about it early is what keeps an engagement from drifting.
- Someone who does the work
- A person who can walk us through the process as it really runs, including the informal steps that never made it into any document.
- Someone who can change it
- Automating a process means changing it. If nobody in the room can approve that change, the engagement stalls at design.
- Access to the systems
- Read access early, write access at build. Engagements are delayed by access far more often than by effort.
- A few hours of attention
- Concentrated at discovery and at the design review. Between those, we should not need much from you.
What we will tell you that other people might not
Three things worth saying out loud, because each of them costs us work.
Sometimes the answer is no
Some processes are better fixed by removing a step, changing a rule or dropping a tool. Automating those just makes a bad process run faster.
We do not have a wall of logos
CanAutomate is a young practice and we are not going to invent client results. We would rather show you the reasoning than borrow someone else's proof.
Headcount is not the pitch
What changes is what the same people spend their day on. If the goal is specifically to reduce staff, we are probably the wrong partner.
How an engagement runs
- Can we stop after the design stage?
- Yes. Each of the four stages ends with something you can hold, and you can stop after any one of them. Some clients take the discovery map and fix the process internally without automating it. That is a legitimate outcome and we would rather it happen than have you buy a build you did not need.
- How long does a typical engagement take?
- Discovery is usually a week or two of elapsed time and only a few hours of yours. Design is another week. Build depends entirely on scope — a single flow is a few weeks, work spanning several systems is longer, and access to those systems is more often the constraint than the code. Improve is ongoing for as long as it is useful.
- What do you need from our team?
- Someone who can walk us through how the work happens today, and someone who can decide to change it. Beyond that, access to the systems involved and a few hours of attention at the design review. Engagements stall on access far more often than they stall on effort.
Related
What we automate
The four kinds of work these stages get applied to.
About CanAutomate
Who is doing this, where, and what we will not claim.