The win is the easy part
You automated something. Maybe it was invoice reminders, a scheduling flow, or a weekly report that used to eat half a Friday. It worked. Time got saved, an error stopped happening, someone stopped dreading Mondays.
That's a good result. It's also fragile.
A single automation, run once by one person, isn't a system — it's a demo. If the person who set it up leaves, forgets, or gets busy, the win quietly evaporates and you're back to the old manual process without ever noticing the regression. The goal of this stage isn't to celebrate the fix. It's to make sure it survives contact with a normal, messy week — and then to make it bigger than the one process it started with.
This is the Improve stage: you've already Planned and Done. Now you standardize what worked, roll it out wider, and capture what you learned so the next cycle starts smarter.
Write it down before you forget how it works
The first mistake most small teams make is treating an automation as "done" once it runs correctly one time. It's not done until someone other than the builder can operate it, fix a minor hiccup, or explain it to a new hire.
Write a short SOP — one page is usually enough:
- What it does. One or two sentences. "This automation pulls new form submissions into the CRM and sends a welcome email within five minutes."
- What triggers it. The event, the schedule, the condition.
- What to check if it breaks. The two or three most likely failure points — an expired API key, a renamed spreadsheet column, a paused Zap.
- Who owns it. Not "the team" — a name. Someone has to be responsible for noticing if it stops working.
- Where it lives. The tool, the account it runs under, any login details stored in your password manager.
This isn't bureaucracy for its own sake. It's insurance. A process that depends entirely on one person's memory is a single point of failure, whether or not it involves software. Writing it down converts a fragile trick into an asset the business actually owns.
If you ran a short pilot to get here, this is also the moment to go back and formalize what you tested informally — see You Found a Win. Now Lock It In. for more on turning a good result into something durable before you move on.
Decide if it's ready to scale
Not every win should be rolled out wider immediately. Before you expand it, ask three questions.
Did it actually hold up, or did you just get lucky once? One clean week isn't proof. Give it enough cycles — a few weeks of real, messy use — to know it handles edge cases: the customer with a weird email format, the order that comes in at 11:58pm, the month with five Fridays instead of four.
Is the underlying process the same everywhere you'd apply it? An automation built around how your best salesperson handles leads may not transfer cleanly to how the rest of the team works, if their process is different underneath. If you're scaling to more people or more locations, make sure you're scaling a process, not just a script. Don't automate a mess and expect it to behave once there's more of it.
Is anyone actually asking for it? If one department automated their weekly reporting and it's a clear win, check whether other departments have the same pain — and the same underlying process — before you assume it transfers. Sometimes it doesn't, and that's fine. Note it and move on rather than forcing a rollout that creates more exceptions than it solves.
Roll it out deliberately, not all at once
Once you've confirmed the win is real and the process underneath is consistent enough to scale, expand it in stages rather than flipping a switch for everyone at once.
A workable pattern:
- Pick a second team or use case that's similar enough to the original to be low-risk, but different enough to be a real test.
- Reuse the SOP, and update it with anything the second rollout reveals. This is normal — the first version of any SOP is a draft, not a final answer.
- Assign an owner for the wider rollout — could be the same person, could be someone closer to the new team who'll actually use it daily.
- Set a short check-in, a week or two out, to catch friction early rather than letting people quietly revert to the old manual way because the new one felt unfamiliar.
If the wider rollout is happening across a full team or company, treat it with the same structure as a fresh 90-day initiative: quick setup, a defined check-in point, and a plan to fine-tune once people have used it for real. If you haven't formally reviewed how your last 90-day push performed, that's worth doing before you commit more automations to the pile — see The Automation Audit: Did Your 90-Day Plan Actually Work? for a structured way to check.
Turn one win into a habit, not a one-time project
The real payoff of standardizing a win isn't just that one process runs smoother. It's that you've built a repeatable move: spot a pain point, automate a piece of it, confirm it holds up, document it, scale it. Do that a few times and it stops being a special project and becomes how your operation naturally improves.
A few habits that make this stick:
- Keep a running log of automations and their owners. A simple spreadsheet is fine: what it does, who owns it, when it was last checked. This is your risk-reduction net — if something breaks, you know where to look and who to ask.
- Revisit old automations occasionally. Tools change, teams change, and an automation built for a five-person company may need adjusting at fifteen. A quarterly glance at the log catches drift before it becomes a real problem.
- Feed what you learn into the next cycle. Every rollout teaches you something — maybe the SOP format needs a different section, maybe your team responds better to a five-minute demo than a written doc. Carry that forward.
A small company that automated its intake process this way is a useful real-world reference point: see Case Study: A 30-Day Automation Pilot at a 9-Person HVAC Company for how a single focused win got locked in and then used as a template for the next improvement.
Close the loop
Standardizing a win isn't the finish line — it's the handoff to the next planning cycle. Once a process is documented, scaled, and owned, it frees up the attention you were spending on it to go find the next opportunity: the next manual task, the next blind spot, the next process worth fixing before you automate it.
That's the whole point of running this as a cycle rather than a one-off project. You don't need a bigger plan next quarter — you need the same discipline, applied to whatever's next on your list.