1–2: Is the problem clear, and does someone own it?
1. Can you describe the task and the outcome? Name the trigger, input and accepted output. “Prepare a proposed response to a new property enquiry” is specific enough to explore. “Use more AI” is not a delivery brief.
2. Who owns the process? Identify the person who can explain exceptions, approve changes and judge whether the result is useful. That person needs time to participate. A project can be technically feasible and still fail because decisions have no owner.
3–4: Can the system use the right information?
3. Is the required data accessible and usable? Check where it lives, whether it is current and how records relate. Try extracting a small representative sample. Missing customer identifiers and inconsistent status labels often surface earlier in a sample than in a planning meeting.
4. Are permissions and provider arrangements understood? Identify which users and systems may access each record, and what information any external provider would receive. Review account settings, contracts and retention requirements with the people responsible for them. Do not assume installing a tool on your server determines every connected service’s data handling.
5–6: What can AI do, and when must a person decide?
5. Which step actually needs AI? Separate fixed rules from tasks that require interpretation. Deterministic checks should remain straightforward where possible. This keeps the system easier to test and gives AI a useful, bounded role.
6. Are approval and escalation rules explicit? Define what may run automatically, what stays as a draft and which conditions require human review. Include uncertainty, missing information and requests outside the intended task. Name the person or queue that receives an exception.
7–8: Can you test success and failure?
7. Do you have representative test cases? Include ordinary work and difficult cases. Write down the expected result or review criteria. A demonstration using a few ideal examples cannot show how the system behaves across real demand.
8. Is there a measurable baseline? Record time, quality, rework and costs before implementation. Decide how you will compare the assisted process with the existing one. Include the effort required to review and correct AI output.
9–10: Can the business operate the result?
9. Have you budgeted for the complete service? Include development, integration access, model usage, hosting, monitoring and support. Ask how costs change with volume, longer documents and repeated attempts. Set sensible limits before enabling tools that can incur charges.
10. Who handles maintenance and recovery? Name the owner for provider changes, failing workflows and updates to source information. Test how to pause the system, recover an incomplete task and return to the previous process where necessary.
Turn the answers into a first project
Mark each question as ready, needs work or unknown, with evidence and an owner for the next action. Avoid turning the checklist into an invented maturity score. One unresolved issue can outweigh several positive answers. Missing permission to use the data is one example.
If the process and ownership are clear but the integration is uncertain, investigate that connection first. If data quality is the main gap, scope the cleanup. If the cost case is unclear, measure a small sample of existing work before paying for a build.
The output should be a practical decision: start a bounded pilot, resolve a named dependency or use a simpler tool. Read AI workflow automation for measurement examples, or bring the checklist to a discovery call.
Written for Orwell Lab’s practical guide collection. Examples and calculations are illustrative unless a project is specifically identified.
Discuss your own requirements ↗