Start with the recurring bottleneck
Ask your team which task they keep copying, chasing, or handing back to the owner. Useful candidates include preparing a weekly operations report, collecting missing enquiry details, finding an approved procedure, or reminding a colleague about an overdue handover.
Do not start with the largest list of features. Start with a sequence you can describe from beginning to end. “Improve operations” is too broad. “Turn a complete enquiry into a review-ready CRM record” is specific enough to investigate.
Use these five selection questions
- How often does it happen? A repeated process gives you more opportunities to observe it and compare results. Record actual occurrences during a representative week.
- Where does the time go? Separate active work from waiting. Copying information, checking details, and asking for approval create different design problems.
- Is the information usable? Confirm which source is current, who can access it, and whether records have consistent identifiers.
- What happens when it goes wrong? Identify the point where a draft becomes a customer message, financial commitment, or irreversible change. Place review before that point.
- Who will own it? Name the person who checks exceptions, updates the procedure, and decides whether the result is acceptable.
Compare three common starting points
| Workflow | Useful first outcome | What to check first |
|---|---|---|
| Enquiry intake | A complete record and draft next action | Required fields, duplicates, and a review owner |
| Weekly reporting | A consistent report prepared for review | Source definitions and missing or stale data |
| Internal knowledge | An answer linked to an approved source | Document ownership, permissions, and expiry |
Measure the baseline before you build
Write down the volume of requests, time spent handling each one, number returned for missing information, and number left unresolved. Keep the measures simple enough that someone will actually maintain them.
For illustration, 30 requests requiring 12 minutes of active work each amount to six hours of handling time. That calculation describes the starting workload; it does not mean automation will recover all six hours. Review, exceptions, upkeep, and work that remains manual must be counted after a pilot.
Test the difficult cases
A happy-path demonstration proves very little about day-to-day reliability. Try an incomplete request, a duplicate, a tool outage, and information that conflicts with the approved source. Agree what should happen in each case before connecting the workflow to routine work.
A useful pilot has a limited group of users, a way to see what happened, and a manual fallback. The team should be able to stop the workflow and understand which records still need attention.
Write a one-paragraph scope
Use this template: “When [trigger] occurs, the system uses [approved sources] to prepare [output]. [Owner] reviews [decision] before [action]. Exceptions go to [person or queue]. We will assess it using [measure].”
This is a stronger starting point than a list of tools because it makes the handovers and responsibilities visible. It also helps a specialist explain which parts need AI, which need ordinary automation, and which should stay manual.
Decide whether to expand
Expand only after the pilot produces usable work and the team understands its limitations. If reviews take longer than the original task or exceptions dominate, simplify the design. Read what drives an AI operations build’s cost before turning the pilot into a larger scope.