Value
Does this remove meaningful time, delay or error?
Automation framework
The Useful Automation Test
Automate work because the operating case is strong — not because the technology is impressive.
Canonical AtlasFlow framework
The Useful Automation Test
Automate work because the operating case is strong — not because the technology is impressive.
01
ValueDoes removing this work matter?
→02
RepeatabilityIs the work defined well enough?
→03
JudgementWhich decisions still need a human?
→04
VisibilityCan someone inspect what happened?
→05
EscalationWhat happens when confidence is low?
Human gateAmbiguity, sensitivity or material risk stays reviewable.
Repeatability
Is the work defined well enough to automate safely?
Judgement
Which decisions still require a human?
Visibility
Will people be able to see what the system did and why?
Escalation
What happens when confidence is low or the situation is unusual?
Use it when
A business has a list of AI ideas but no disciplined way to choose what deserves implementation.
Limit
Automation ROI depends on real volumes, costs and failure modes. A framework cannot replace those facts.
Apply this to a commercial problem →Definitive guide
Automation earns authority one bounded decision at a time.
The Useful Automation Test is a refusal to start with the tool. It asks whether the work creates enough value to matter, whether the process is defined, where judgement belongs, whether actions remain observable and what happens when the system encounters an exception.
01
Value
The workflow should remove meaningful labour, delay, error, missed opportunity or visibility failure rather than merely demonstrate technical possibility.
Diagnostic question
What recurring cost or constraint becomes materially better if this works?
02
Repeatability
Triggers, inputs, expected outputs and normal states need enough structure for the system to act reliably.
Diagnostic question
Can we describe the normal workflow clearly enough that two competent people would execute it similarly?
03
Judgement
Language interpretation can be assisted by AI, but commercial, sensitive or high-consequence decisions may still require accountable human review.
Diagnostic question
Which decision would we still want a named person to own if the system were wrong?
04
Visibility
People need to inspect what happened, which data was used, what action was taken and whether intervention is required.
Diagnostic question
Can the owner understand and correct the workflow without reverse-engineering a black box?
05
Escalation
Low confidence, unusual context, missing data, high value or material consequence should have an explicit route out of the automated lane.
Diagnostic question
What condition makes the system stop, ask, defer or hand control back to a person?
Automation preflight
Design the operating case before designing the workflow.
The strongest first implementation is usually smaller than the original automation idea because it isolates the repeated value from the judgement and exception load.
- 01
Describe the current workflow, owner, trigger, inputs, states and desired outcome
- 02
Estimate the real cost of the current process in time, delay, error or missed opportunity
- 03
Separate deterministic rules from interpretation, judgement and sensitive decisions
- 04
List failure modes, reversibility and the consequence of a wrong action
- 05
Define permissions, human gates, observability and escalation before the build
- 06
Pilot the smallest bounded workflow with enough volume to generate evidence
- 07
Review exceptions and operating value before expanding authority or scope
Failure patterns
Automation theatre begins when capability replaces operating logic.
The most expensive automation mistakes often look impressive in a demo because the missing responsibility only becomes visible in real operation.
AI where a rule is enough
A probabilistic model is used for deterministic routing, validation or reminders that would be easier to test as explicit rules.
Undefined process in, automation out
Different people still perform the work differently, so automation encodes one accidental version of an unresolved process.
No exception lane
The happy path works but unusual inputs, low confidence or missing context have nowhere safe to go.
Irreversible authority too early
The system can send, approve, delete, commit or change material state before the team understands failure patterns.
Invisible action history
People can see the outcome but not what the workflow did, why it acted or what source information it relied on.
No post-launch owner
Nobody is responsible for broken integrations, changing rules, bad source data, permission drift or reviewing recurring exceptions.
Worked scenario
One follow-up workflow can justify three different operating models.
Imagine an inbound sales enquiry that should be acknowledged, researched and qualified.
Create the CRM opportunity, preserve source and assign the correct owner.
Summarise the enquiry and prepare a draft acknowledgement from approved context.
A person decides fit, commercial priority and whether the draft should be sent.
High-value, sensitive or ambiguous enquiries are surfaced instead of automatically advanced.
Exceptions and time saved determine whether more of the workflow should be automated.
The useful automation design is not “AI handles the lead”. It is a bounded allocation of rules, assistance and accountable judgement.
Boundary
The framework cannot prove automation ROI without real volumes, costs and failure evidence. High-risk decisions remain human-owned unless the operating case explicitly supports otherwise.
A defined place to start
Commercial Conversion Review
One enquiry-to-revenue journey. Five business days. A concrete diagnosis and priority roadmap.
R9,500 fixed scopeNo charge by enquiryEvidence before implementationOne defined journey