How to choose your first AI automation
An enquiry arrives. Someone reads it, finds the customer, checks the price list and writes a reply. The next enquiry starts the same sequence again.
That is a useful place to look for automation. The starting point is a piece of work you can describe, observe and improve—not a decision to put AI everywhere.
This guide gives you a way to choose that first piece of work, check whether AI belongs in it, and define a pilot your team can judge.
Start with a recent task
Ask a colleague to walk through something they completed this week. Keep the actual email, document or record in front of you, with sensitive details removed where needed. Ask what triggered the task, which information they looked up, what decisions they made and how they knew it was finished.
“We spend too much time on admin” is difficult to build against. “Every enquiry needs a customer lookup and a reply based on our current service list” describes an input, a source and an output.
Write down three candidates before choosing. Common places to look include preparing customer replies, turning incoming requests into structured records, gathering material for a recurring report and preparing an internal handoff. Treat these as possibilities to investigate, not promises that every task will benefit.
Does this step need AI?
Some work follows an exact rule. If a form already contains a valid customer ID, copying that ID into another system usually does not require a language model. AI becomes more relevant when the input is varied language: interpreting an email, identifying requested items in a document or drafting a summary from several sources.
| Part of the work | A sensible starting approach |
|---|---|
| Move a known field between two systems | An integration with validation |
| Check whether a required field exists | A fixed rule |
| Interpret a request written in free text | AI extraction, followed by checks |
| Prepare a reply using approved information | Retrieval and AI drafting |
| Decide whether to make a commercial exception | A named person with the relevant context |
A useful workflow may combine all of these. You can automate the predictable steps and use AI only where interpretation helps. Anthropic draws a similar distinction between workflows with predefined paths and agents that choose their next steps dynamically. Read its explanation of workflows and agents.
Use five questions to choose a candidate
Count real occurrences over a representative period. Include quieter days as well as busy ones. A task that feels frustrating may still happen too rarely to justify building and maintaining a system.
For an enquiry, that might mean the correct customer is identified, the service details match the current source, and no unsupported price is included. “Make the team more productive” is an ambition; these are checks.
Locate the records, files and permissions the work needs. Agree which source wins when two documents disagree. If the information exists only in someone's memory, document that part before automating it.
A draft in a review queue is easier to inspect than a message already sent to a customer. Choose an initial boundary that makes errors visible and correction practical.
Name the person who reviews exceptions, updates the business rules and decides whether the system is still useful. An unowned queue is just another place for work to get stuck.
You do not need a weighted score to begin. If a candidate has no clear owner, unreliable sources or no way to recognise a good result, fix those gaps or choose a narrower task.
Write a pilot brief that fits on one page
Consider a service business that receives enquiries by email. This is an illustrative example, not a Lindevo customer result.
| Decision | Example pilot boundary |
|---|---|
| Trigger | A new enquiry arrives in one shared inbox |
| Scope | Questions about services already covered in an approved guide |
| Information | The current service guide and permitted customer records |
| Output | A suggested reply with its sources and the matched customer |
| Approval | The account owner checks and sends the reply |
| Exceptions | Missing details, conflicting information and requests outside the guide |
| Completion | The review outcome is recorded against the enquiry |
This boundary deliberately leaves some work with the team. It lets you test whether gathering context and preparing a draft are useful before deciding whether any actions should happen automatically.
Measure the work that remains
Record a baseline before the pilot. Useful measures include handling time, time spent reviewing drafts, corrections, missed enquiries and unresolved exceptions. Keep the definitions consistent so you are comparing the same kind of work.
For example, suppose a team handles 120 eligible enquiries each week. Preparation takes six minutes per enquiry today. During a pilot, review and correction take two minutes, and maintaining sources and handling exceptions adds one hour each week. The illustrative calculation is:
120 × (6 − 2) minutes − 60 minutes = 420 minutes, or seven hours per week.
That is a planning example, not an expected result. It does not include setup costs or prove that released time becomes additional revenue. Replace every assumption with measured values, and check that quality and customer outcomes have not deteriorated.
Info
A fast draft is not the whole result. Count review, corrections, exceptions and upkeep. If those consume the time you saved, narrow the scope or improve the workflow before expanding it.
Know when to pause
Pause the pilot if reviewers cannot tell where an answer came from, if exceptions routinely disappear into a queue, or if the source material changes without anyone updating it. These are useful findings. A pilot should reveal what needs to change before the system becomes part of everyday work.
Expand when the first task consistently meets the agreed checks, the team understands its boundaries and the owner can operate it. The next improvement might be a better source document or a simpler approval screen rather than more automation.
Bring one recurring task, an example input and a description of a good outcome. That is enough to start a focused discussion about how we work or the systems Lindevo builds.
On this page