Key takeaways
- The scarce resource is the attention of whoever knows the process, not software budget. Budget roughly fifteen hours of their time across eight weeks and the project survives; leave it implicit and it stalls.
- Capture a timed manual baseline before anything else. It becomes unrecoverable the moment automation is involved, and without it every later claim about time saved is a guess.
- The readiness decision is about coverage, not a count of clean runs. Two are enough for a single-branch process; twenty are not enough if the expensive branch has yet to appear.
- Decide which approvals are permanent while you design, not after. A gate added because something went wrong is a reaction; a gate designed in is a control.
- Two stop signals are worth honouring: the process changes shape during the project, and nobody can name who owns it. Both mean the work is not ready, and neither is fixed by a better tool.
Three things to have before week one
The parent guide describes this sequence from the system's side: what it does as it learns, codifies and runs. This page is the other half — what lands in your diary, and when. Do not start without all three of these, because each one is far more expensive to obtain later.
- One process, deliberately unglamorous. Frequent, cheap to get wrong, and owned by one person. Resist starting with the process that hurts most: it is usually painful because it is ambiguous, and ambiguity is the one thing automation makes worse. Google's engineers reserve automation for toil — repetitive work that produces no enduring value and grows at least as fast as its source. Work that stays flat as the business doubles is the wrong first choice.
- A timed manual baseline. Run it by hand three times with a stopwatch and record where the minutes go, plus the error rate you currently live with. Once automation is involved this number cannot be recovered, and without it you will be arguing about whether the project worked using anecdotes.
- A named owner who has agreed to the hours. Not a team, not a job title. One person who can say what a correct run looks like, and who has fifteen hours over two months. NIST puts govern at the centre of its four AI risk functions, ahead of measuring and managing, on the reasoning that responsibility has to be settled before the rest means anything.
The eight weeks, and what each one costs you
Hours below are the process owner's hours, which are the ones that are actually scarce. The last column is the part most plans omit: at every stage there is a result that should end the project rather than escalate it.
| When | What you actually do | Your hours | What you decide at the end | What would make you stop |
|---|---|---|---|---|
| Week 0 | Pick the process, time three manual runs, name the owner, and write down the one exception you already know about. | 2 | Whether the volume justifies the next seven weeks at all. | You cannot name an owner, or the timing shows the process eats less than an hour a week. |
| Weeks 1–2 | Do the real work with the system watching. Correct it as it goes. Approve every action that leaves the building. | 6 | Nothing yet. This stage exists to produce corrections, not conclusions. | The same correction is needed three times running. That is a procedure problem, not a training one. |
| Week 3 | Deliberately feed it the awkward cases you avoided in weeks one and two, including the one from week zero. | 3 | Readiness: have the expensive branches appeared and been handled cleanly? | A branch turns up that nobody can describe a correct answer for. Settle it with colleagues first. |
| Week 4 | Walk the procedure step by step against real runs. Mark each step as code, judgment or approval, and pin the gates. | 3 | Which approvals are permanent. Decide now, in the calm, not after an incident. | You cannot say which steps must never run unsupervised. Stop and read the human-in-the-loop guide. |
| Weeks 5–6 | Let it run on real work while you watch daily. Attend the approval queue properly; do not batch it on Friday. | 2 | Whether the exception rate is falling or merely being absorbed by you. | You are spending more time on approvals than the manual process took. |
| Weeks 7–8 | Stop watching daily. Check the record once a week and compare against the week-zero baseline. | 1 | Whether to take a second process, and what carried over from the first. | Nothing carried over, and process two looks like starting again. |
The shape of that plan is not accidental. Google's engineers describe automation as a progression whose real payoff is consistency and a platform to build on, not simply hours removed. That is why weeks seven and eight ask what carried over. A first process that saves six hours a month and teaches you nothing transferable is a worse outcome than one that saves three and makes the next four processes cheap.
The two decisions that actually matter
Most of the eight weeks is unglamorous supervision. Two moments carry nearly all the consequences, and both fall in weeks three and four.
The readiness call. The temptation is to count clean runs and pick a threshold. Resist it. Two clean runs are plenty for a process with one path; twenty prove very little if the branch that costs money has not appeared yet. The honest test is coverage — have the awkward cases turned up and been handled — and a secondary one that catches most mistakes: could a new colleague follow the written procedure without asking you a question? If not, the procedure is not finished, and writing it precisely is the remaining work.
Which gates are permanent. A gate designed in week four is a control. A gate added in week nine because something went wrong is a scar, and it tends to be placed where the last incident happened instead of where the risk is. Anything irreversible, anything that reaches a customer, and anything that decides something about a named individual should keep a person — and keep them permanently, not until confidence grows. The human-in-the-loop guide works through how to make those gates worth their cost.
What week nine onwards actually looks like
The project does not end; it changes shape. A supplier alters a form, a threshold silently expires, someone renames a field. A small change should arrive as a proposed fix you confirm, checked against runs you already accepted so it cannot break what worked. A large one should send the process back to supervised runs while the queued work still gets done.
Watch three numbers rather than the flattering one. The share of runs completing untouched tells you little, because a process doing the wrong thing at speed scores beautifully on it. Track the exception rate, which is your earliest signal that reality has moved; the time between a wrong run happening and somebody noticing, which matters more than the error rate itself; and how often an approver actually edits or rejects, because a gate that is never used has either finished its job or stopped doing it, and you need to know which.
Limitations and when not to use this
- Eight weeks and fifteen hours describe one straightforward process with a single owner. A process spanning three teams, or one where the correct answer is genuinely disputed, takes longer and the extra time goes on agreement between people rather than on anything technical.
- This plan assumes you have already chosen a tool. Judging one is a different exercise, covered in the tools guide, and running it as an evaluation rather than a deployment changes what you do in weeks one and two.
- The hours are the process owner's only. Setup, connections and permissions take somebody else's time as well, and how much depends entirely on how obliging your existing systems are.
- Nothing here is legal, financial or employment advice. A process that decides something significant about an individual carries obligations this plan does not enumerate, and those belong in week zero rather than week nine.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 27 July 2026
- Automation: The Evolution of Automation at Google — Google, Site Reliability Engineering Accessed 27 July 2026
- AI Risk Management Framework — NIST Accessed 27 July 2026
Start with the baseline
Week zero begins with numbers you can only collect while the process is still manual. Put your volumes and handling times in, and find out whether the eight weeks are justified before you spend them.
Start with the baselineUli Prantz
Builds and operates all-agents
Uli Prantz builds all-agents, the process-automation platform this site documents. He writes about the operational side of automating recurring business work: where deterministic code beats model judgment, where it does not, and where a human still has to approve.