Key takeaways
- Readiness means the process is stable, observable and owned enough to test; it does not mean the automation is safe or worthwhile at any price.
- A missing trigger, exception destination, finish state or process owner blocks a pilot regardless of the total.
- Each criterion scores zero, one or two and every recommended improvement is visible.
- The assessment runs in your browser and produces a copyable action report without signup.
Assess one process
Mark what the current process documentation says—not what an experienced operator remembers. Clear = explicit and testable; partial = implied or inconsistent; missing = absent.
Result · 8/16 · 50%
Keep it manual while you define it
Value
1/2
Definition
3/6
Execution
2/4
Control
2/4
Next improvements
- Recurring volume: Measure runs per month and keep infrequent work as a checklist.
- Stable path: Observe another cycle and record what still changes.
- Observable trigger: Choose one machine-observable start condition.
- Authoritative inputs: Map each input to its source, format and missing-data response.
- Bounded decisions: Separate fixed rules from genuine judgment and define the handoff.
- Owned exceptions: Create an exception queue with a named owner and deadline.
How readiness is calculated
Clear receives two points, partial one and missing zero. The total is divided by sixteen. Below 60% stays manual while the team defines it. Between 60% and 84% calls for preparation followed by a supervised pilot. At 85% or more, a bounded pilot is reasonable if no hard gap remains.
The four hard gaps are observable trigger, owned exceptions, observable finish and accountable owner. They are structural prerequisites, not high-weight preferences. A process cannot be operated as a controlled automation if it starts from somebody noticing, silently drops ambiguity, calls “finished” from memory or has nobody authorized to stop it.
| Dimension | What it establishes | What it does not establish |
|---|---|---|
| Value | Work recurs often enough for effort to compound. | That benefits exceed implementation and operating cost. |
| Definition | The path, trigger and sources are stable enough to encode. | That every edge case is known. |
| Execution | Rules and exception handoffs can be bounded. | That model quality is adequate. |
| Control | Success and accountability are observable. | That permissions and safeguards are sufficient. |
Evidence that should support a clear answer
- Recurring volume: a run log or queue count, not a recollection of a busy month.
- Stable path: recent cases showing which rules and branches changed.
- Authoritative inputs: field names, access method, data owner and missing-data behavior.
- Bounded decisions: examples separating fixed rules from judgment and approval.
- Owned exceptions: a real queue, named role, response target and safe expiry.
- Finish and ownership: an observable terminal record plus the role empowered to accept, change and stop the process.
Use the result to choose the next smallest test
- 01Resolve hard gapsCreate the missing system event, exception queue, terminal state or ownership decision before buying or building.
- 02Bound the pilotLimit input class, permissions, batch size and affected audience. Preserve the manual fallback.
- 03Assess each consequential actionUse the risk assessment for actions that send, change, grant, publish or pay.
- 04Price the candidateOnly now put measured volume, handling time and review effort into the ROI calculator.
Limitations and when not to use this
- The assessment does not inspect systems or observe process runs; the output inherits every unsupported answer.
- Readiness is not a safety, security, privacy, legal, compliance or financial assessment.
- Thresholds are an educational operating heuristic, not an external benchmark. Compare the same process over time rather than comparing teams.
Sources
- Eliminating Toil — Google, The Site Reliability Workbook Accessed 1 August 2026
- Job Aid: Process Mapping — Agency for Healthcare Research and Quality Accessed 1 August 2026
Assess automation risk
Evaluate likelihood, consequence, detectability, scope and reversibility before choosing controls.
Assess automation riskUli 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.