Key takeaways
- Inventory work for a week before choosing a task from memory.
- Rank repeated work by total handling, waiting, corrections, and coordination, not irritation alone.
- Name the trigger, finish state, normal path, and three common exceptions before choosing technology.
- Give deterministic steps to code, bounded interpretation to AI, and consequential decisions to people.
- Pilot with real cases, visible evidence, and a manual fallback before increasing coverage.
Automate repetitive tasks by first recording what actually repeats, then ranking candidates by handling time, waiting, corrections, stability, checkability, and risk. Map the trigger, finish state, normal path, and exceptions. Assign settled work to code, bounded interpretation to AI, and consequential decisions to people. Test historical cases, start in observation or draft mode, release a narrow scope, and measure clean completion, correction, exception, and recovery rather than hours saved alone.
Inventory a week of work before choosing
The task people remember is usually the most annoying recent interruption, not necessarily the best automation candidate. Capture every repeated action for five working days, including short checks, handoffs, searches, copying, follow-ups, corrections, and work that was delayed because an input or owner was missing.
Google's toil guidance recommends a data-driven inventory and ranking. The same logic applies beyond site reliability: repeated work becomes more important when it scales with customers, orders, tickets, suppliers, or employees.
Checklist
Repetitive Task Inventory
A markdown worksheet for capturing frequency, handling time, waiting, corrections, stability, risk, owner, and automation next step.
Preview the fileHide preview
# Repetitive task inventory Use this worksheet for five working days. Record the work as it happens instead of reconstructing the week from memory. Do not include secrets, personal data, customer confidential data, or regulated information. ## Task log | Date | Task or queue | Trigger | Person or role | Active minutes | Waiting created | Correction or repeat? | Systems touched | Outcome | | --- | --- | --- | --- | ---: | --- | --- | --- | --- | | | | | | | | | | | ## Candidate summary Complete one summary for each repeated task. - Task name: - Accountable owner: - What creates one item? - What observable result finishes it? - Runs per week: - Total active minutes per run across all people: - Typical elapsed time: - Who waits while it is open? - What drives future volume? - Share of cases following the normal path: - Three common exceptions and their current owners: - Source of truth for required inputs: - How quickly can a correct result be verified? - What external action occurs? - What is the impact, detectability, scope, and reversibility of a wrong action? - Is there a usable manual fallback? - Who would own monitoring, failed runs, changes, and retirement? ## Candidate score Score each item from 0 to 2. A score is a discussion aid, not an approval to automate. | Factor | 0 | 1 | 2 | Score | | --- | --- | --- | --- | ---: | | Frequency | Monthly or rarer | Weekly | Daily or scales with volume | | | Stability | Sequence changes each run | Normal path repeats | Normal path and main exceptions repeat | | | Inputs | Hunted from memory | Some named sources | Required sources and owners are clear | | | Checkability | Subjective or delayed | Human can review | Outcome and effects can be verified | | | Coordination | One person, no wait | One handoff | Several people or systems wait | | | Containment | Immediate hard-to-reverse harm | Gate can contain effect | Draft, internal, or reversible effect | | | Ownership | No owner | Process owner only | Service and decision owners named | | ## Decision - Keep manual and document: - Simplify or batch first: - Assist with preparation or drafting: - Automate a bounded path: - Evidence needed before deciding: - Review date: Measure real clean completion, corrections, exceptions, harmful effects, detection, recovery, and owner effort after any pilot. Do not report projected hours as realized savings.
Rank the job, not the click
| Measure | Capture |
|---|---|
| Frequency | Runs per week and what drives future volume |
| Handling | Active minutes across every participant, including checking and correction |
| Waiting | Elapsed time and who is blocked while the item sits |
| Stability | How often the normal path, inputs, and rules change |
| Exceptions | Share of cases outside the normal path and their common destinations |
| Checkability | How quickly correctness and external effects can be verified |
| Consequence | Impact, detectability, reversibility, and affected scope of a wrong action |
A task that consumes 20 minutes monthly may stay manual. A four-minute intake check repeated 100 times, followed by ambiguous handoffs and corrections, may justify an internal tool because the queue cost is larger than the click.
Map enough reality to automate safely
- 01Name the trigger and required inputsTriggerState what creates one item, how duplicates are recognized, and what happens when a required fact is missing.
- 02Define the finish stateHuman approvalDescribe the observable business outcome, not “automation completed.” Name the receiving owner.
- 03Write the normal pathCodeTurn stable checks, calculations, transformations, updates, and notifications into explicit steps.
- 04Route three real exceptionsHuman approvalUse recent awkward cases. Give each one an owner, evidence, clock, and return path.
- 05Place the authority boundaryHuman approvalDecide which actions are automatic, which are drafts, and which require approval permanently.
Give each step to the cheapest reliable performer
| Performer | Give it | Do not give it |
|---|---|---|
| Code | Exact checks, calculations, matching, state changes, and verification | Unwritten policy or ambiguous human judgment |
| AI judgment | Bounded classification, extraction, comparison, and drafting with examples | Authority to invent policy, infer external effects, or approve its own consequential action |
| Human | Novel exceptions, policy, accountability, sensitive decisions, and release approval | Routine copying and status chasing that software can verify |
Pilot for learning, then expand coverage
- 01ReplayCodeRun historical normal and failure cases without taking live effects.
- 02ObserveAI judgmentProduce the result beside the current process and compare disagreements.
- 03DraftHuman approvalLet the system prepare work while a person verifies every action.
- 04Release narrowlyTriggerLimit the users, records, actions, and volume; keep fallback ready.
- 05Measure and adaptHuman approvalReview clean runs, corrections, exceptions, harmful effects, detection, recovery, and owner effort before increasing scope.
Limitations and when not to use this
- The inventory records time and operating characteristics; it does not by itself establish ROI, safety, or compliance.
- Do not automate work simply because it is repetitive. Some repeated reviews exist to provide accountable judgment or separation of duties.
- Examples are process patterns, not claims that all-agents currently supports every named system or use case.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 14 August 2026
- The Evolution of Automation at Google — Google Site Reliability Engineering Accessed 14 August 2026
Download the task inventory
Capture recurring work for five working days, then score the top three candidates with their actual owners.
Download the task inventoryUli 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.