The first question in an AI project should be painfully ordinary: which part of the business is harder than it needs to be?
A useful starting point might be organizing incoming enquiries, preparing a draft after a customer call, or finding the right information for a team member. Choose a problem you can describe before you choose software.
This guide is a planning framework. The examples and numbers below are illustrative, not results from a customer deployment.
Describe the work as it happens today
Write down the trigger, the steps, the people involved, and the final result. Include the exceptions. A workflow that sounds simple in a sales presentation can contain several decisions that only an experienced employee knows how to make.
For example: an enquiry arrives, someone checks the service area, asks for missing details, assigns an owner, and sends an acknowledgement. The opportunity might be helping staff prepare that acknowledgement, rather than automating the entire enquiry process.
Choose a bounded task
A strong first project has a clear start and finish. It also has an understandable recovery path when something goes wrong.
- Clear input: you know which information starts the task.
- Clear output: a person can judge whether the result is useful.
- Limited consequences: an incorrect result can be caught and corrected.
- Named owner: someone is responsible for reviewing results and resolving exceptions.
If the proposed task requires unrestricted access to every system, ambiguous decision-making, or commitments nobody can easily reverse, narrow it before proceeding.
Choose a problem you can describe before you choose software.
Capture a baseline
Observe a representative sample of the current workflow. Record volume, time spent, common errors, and what happens to unusual cases. Include busy periods and messy inputs, not just the easiest examples.
Suppose a team handles 120 enquiries a month and spends six minutes preparing each acknowledgement. That is 12 hours of work. If AI reduces preparation time to two minutes but every draft needs another minute of review, the estimated time released is six hours, not eight. Integration maintenance and exception handling still need to be counted.
Time released is not automatically money saved. Decide whether the team can use it for more valuable work and whether that improvement is worth the ongoing cost.
Define success before testing
Use a short scorecard that balances speed with quality. For a draft acknowledgement workflow, you might track:
- Time from enquiry to a reviewed response.
- Percentage of drafts accepted with minor or no changes.
- Incorrect details or promises in drafts.
- Time spent fixing exceptions.
- Total operating cost, including human review.
Write down acceptable limits before you see the results. A faster workflow that sends the wrong information should not pass because it looks efficient.
Test with human review
Start with a small, representative set of examples that you are permitted to use. Remove unnecessary personal information. Test missing details, conflicting instructions, duplicate enquiries, and requests outside the service area.
For the first live stage, let the system prepare work for a person to approve. Record both the proposed output and the reviewer’s correction. These differences reveal whether the problem is missing information, unclear instructions, an integration issue, or a task that needs human judgment.
Decide whether to expand, revise, or stop
Set a review point based on enough cases to learn from, rather than an arbitrary promise to launch everything in a week. Compare the pilot with the baseline. Look at the difficult cases separately so good average performance does not hide a recurring failure.
Expand only when the result is useful, the exception process works, and the owner can support it. Revise the scope if one part performs well and another does not. Stop if the project creates more checking and repair work than it removes.
Your one-page project brief
- Problem: what happens today, and why does it matter?
- Scope: where does the task begin and end?
- Information: what does the system need, and is it authorized to use it?
- Baseline: how much work, delay, or rework exists today?
- Success: which quality, speed, and cost measures must improve?
- Exceptions: when does a person take over?
- Owner: who reviews results and maintains the workflow?
- Decision point: what evidence will justify the next step?
Complete this brief before comparing tools. It gives vendors something concrete to respond to and gives your team a way to judge the result after the excitement of the demonstration has passed.