Audit read-only and produce a 30-day plan. Build one workflow in two to four weeks, with training. Then iterate monthly. The first result arrives in weeks, not at the end of a migration project.
Automation programmes tend to fail in one of two ways. Some never start, stuck in evaluation and planning. Others start too big — a transformation project that tries to change everything at once, runs for months before anything useful happens, and loses momentum and credibility long before it delivers.
Audit, Sprint, Scale is the delivery shape used across AutomateSales and Campaign Automation to avoid both. It is simple, and its simplicity is deliberate.
Audit: a read-only review and a 30-day plan
The audit comes first because of audit before you automate: automation amplifies whatever it lands on, so you need to know what you are about to amplify.
Two features define it. It is read-only — nothing changes while you are looking, which makes it low-risk and easy to approve. And it produces a 30-day plan, not a strategy document. The plan names the binding constraint, the first workflow to build, and what needs fixing before anything is automated.
Sprint: one workflow in two to four weeks
The sprint builds exactly one workflow. Not a platform, not a programme — one thing that solves one problem, such as the first reply to inbound leads, or the weekly pipeline roll-up.
A sprint includes three things:
- The build itself, ideally inside the tools the team already uses. See build inside the stack you already own.
- Templates, so the workflow can be adjusted without starting again.
- Team training, because a workflow nobody understands is a workflow nobody trusts, and a workflow nobody trusts gets quietly worked around.
Two to four weeks is long enough to build something real and short enough that the first result arrives while everyone still remembers why they started.
Scale: monthly iteration
Once a workflow is running, it moves into monthly iteration. Review the run log, check the metric it was built to improve, adjust the templates and sequences, and decide what to build next.
Scaling means two things: improving the workflows you have, and adding the next one. Each new workflow gets its own sprint.
Why one workflow at a time
It can feel slow to build only one thing at a time. It is not, for three reasons.
It keeps each change small enough to verify. If you change five things at once and results improve, you do not know which change worked. If results get worse, you do not know which to undo. One workflow at a time means every change can be measured and, if necessary, reversed.
The first result arrives in weeks. In a large programme, value arrives at the end — if the end arrives. In a sprint model, value arrives after the first sprint and compounds with each one after that.
It builds trust as it goes. Each working workflow is evidence. By the time you are automating something consequential, the team has already seen several automations work reliably, and the trust needed for bigger steps has been earned rather than requested.
What “verified” means
A workflow is not finished when it is built. It is finished when you can show it works:
- The metric it targets has moved, measured against the baseline from the audit.
- The run log shows it doing what it was designed to do, and nothing it was not.
- The team uses it without being reminded.
If any of those is missing, the next sprint should fix it rather than start something new.
When to stop
Scaling is not endless. Some workflows reach the point where further iteration adds little. Others turn out to be solving a problem that has disappeared. Part of the monthly review is asking honestly whether a workflow still earns its place — and switching it off when it does not.
Where to go next
Audit before you automate explains why the audit comes first. The six pipeline automations suggests which workflows to sprint first. And the readiness ladder tells you how ambitious the sprints can safely be.