The checklist
Seven screens before you choose software
A promising first use case is specific enough to observe and bounded enough to stop. Score each screen 0 unclear, 1 partial, or 2 clearly true. Do not blindly select the highest score; eliminate assumptions and safety-critical gaps first.
- Frequency: Does this handoff happen often enough to learn from?
- Measurable baseline: Can you observe completeness, time, duplicates, reroutes, overrides, or another meaningful before-state?
- Accountable owner: Can one person or role own the process and the decision to change it?
- Known exceptions: Do the people doing the work know the employee, customer, or operating exceptions that a draft could miss?
- Qualified human review: Will a person with the right context review the output before it creates consequences?
- Reversible fallback: Can the business return to the existing process with source records preserved?
- Worth maintaining: Would the outcome be valuable enough for someone to keep the process accurate and supported?
Write down what makes the experiment pause: missing information, unsafe confidence, repeated corrections, an unowned exception, or a result below the agreed threshold.
An illustrative example: maintenance intake
Illustrative example only—not a client result, benchmark, or promised outcome. Imagine a maintenance team receiving reports that a machine is running hot and making an unfamiliar noise, fragmented through operators, radio calls, and supervisors. An assistant could draft structured fields, flag possible duplicates, identify missing questions, and suggest a category, priority, or trade for supervisor review.
It should not declare equipment safe, close orders, or dispatch work away from a critical task. A supervisor reviews the draft, source records remain available, and the existing intake is the fallback.
- Measure completeness at submission.
- Observe triage time, duplicates, reroutes, and supervisor overrides.
- Pause when information is missing, the category is unclear, or the review boundary is not respected.
Human review is not a disclaimer
“A person is in the loop” is only useful when that person has time, authority, context, and a clear action to take. Name the reviewer. Define what they check. Preserve the original request. Make the approval visible. Decide what happens when the reviewer rejects the draft.
When to stop choosing a use case
Do not proceed when the process has no owner, consequences cannot be observed, source information is inaccessible, errors cannot be caught before impact, or the fallback is not genuinely available. A conventional process improvement may be the better answer.