Assign an owner for every decision below and write down the answer. This can be a short working document. The point is to expose missing access, unclear responsibility and a weak business case before those become implementation delays.
1. Choose one job and an accountable owner
- Describe the task in one sentence, including its trigger and finish line.
- Name the person who owns the process and can decide whether an output is acceptable.
- Record task volume, current handling time and common exceptions.
- Choose a measurable improvement: capacity recovered, fewer corrections, shorter turnaround or another observable outcome.
Avoid starting with a broad request for an AI employee. A narrow task makes the first result testable. If the process itself is inconsistent, agree its rules with the people doing it before trying to automate it.
2. Check whether custom work is needed
- Test the relevant features of tools you already pay for.
- Identify which steps follow fixed rules and which need interpretation.
- Compare configuration, ordinary automation, an AI workflow and a custom agent.
- Include licences, integration work, review effort and ongoing support in the comparison.
Use our assistant-versus-agent guide to structure this decision. A less complex solution is preferable when it meets the same business requirement.
3. Identify the source of truth and access
- List the documents, records and systems the deployment needs.
- Identify the authoritative and current version of each source.
- Confirm API availability, account plans and who can approve app access.
- Agree which users may see which information; check that search does not cross those boundaries.
- Decide what data may be sent to each provider and how retention and deletion should work.
An agent's access should be designed for its task. Connecting a shared drive does not automatically make every document appropriate for every user. Record the actual account and permission decisions rather than assuming a platform name settles them.
4. Define allowed actions and human checks
- Separate reading and drafting from sending, changing records or spending money.
- Write down which actions require approval and who may approve them.
- Decide how approval is verified by the action-performing system.
- Define limits for tool access, request volume, spend and retries.
- Assign a manual fallback and an owner for the exception queue.
Ask how the system treats instructions embedded in an email, document or tool result. Those sources can contain misleading or hostile text. Important permission boundaries need enforcement in the surrounding software, not only a request for good behaviour in a prompt.
5. Agree acceptance criteria before building
- Collect representative normal, difficult and incomplete examples.
- Add tests for unsupported requests, incorrect source material and integration failures.
- Define unacceptable errors separately from minor corrections.
- Check correctness, source support, human review effort, latency and operating cost.
- Agree who reviews the evidence and authorises the pilot.
A successful demonstration is one example. Acceptance needs a representative set, including failures. For an enquiry workflow, the worked CRM design provides a starting set of cases.
6. Plan a small rollout and a useful handover
- Choose a pilot group and a review period appropriate to task volume.
- Train users on the intended scope, approval steps and when to fall back to manual work.
- Document setup, account ownership, routine operation and recovery.
- Provide a clear way to report a bad answer or action.
- Compare the full human effort and failure rate against the baseline before expanding.
7. Agree what happens after launch
- Name the person responsible for monitoring and unresolved exceptions.
- Agree how knowledge, prompts, models and integrations are updated and re-tested.
- Separate support scope from new feature work; state response expectations in the agreement.
- Set cost alerts and review usage against the business case.
- Confirm access to code, documentation and accounts if you change supplier.
Recovered time is useful only if the team can use it. Review adoption alongside technical quality: whether the right people use the system, whether they trust the review process and whether exceptions are actually resolved.
What to bring to an opportunity sprint
Bring the task description, approximate volume, tools involved, sample inputs you are authorised to share and the name of the process owner. We can use the gaps in this checklist to shape a practical first scope. See AI implementation packages, or describe the job to us.