Which business task should you automate first?

Look for repetition and a clear next step

List the tasks that repeatedly interrupt your team: sorting enquiries, finding information, copying details from documents or preparing draft replies. For each one, write down what comes in, what someone does and what should happen next.

A good starting point has recognisable inputs and a result that a person can review. For example, an incoming sales enquiry can become a short summary, a suggested priority and a draft next step. Your team still decides whether to contact the prospect.

Choose the task with the clearest boundaries

Compare the candidates using four questions. If the answers are unclear, spend time understanding the process before connecting tools.

• Does it happen often enough to justify setting it up?
• Are the necessary information and access available?
• Can someone check the result without repeating all the work?
• What happens if information is missing or the suggestion is wrong?

A fictional decision: start with one shared inbox

Imagine a small service team choosing between sorting enquiries in a shared inbox and answering customer calls. The inbox has agreed categories and one person who can check draft replies. Calls cover more subjects, and the team has not yet agreed when the assistant should hand over to a person.

For this example, choose email sorting first. The pilot reads incoming enquiries, suggests a category and prepares a draft. A team member checks the draft and sends the reply; missing or unclear information stays in the manual queue. Before testing, agree that a complete enquiry must reach the right category and that the workflow must never send a reply by itself. This is an example of making a decision, not a customer case or a claim of time saved.

Try a small, reviewable workflow

Email sorting or document extraction may be easier to scope than a voice assistant handling open conversations. The right choice depends on your inputs, languages and review needs. Use fictional examples first, then include difficult cases such as an incomplete request or an unreadable document.

Write down the starting point before the pilot: time spent, corrections needed and missed follow-ups. Compare the same measures after testing. Keep a manual route available and name the person who reviews exceptions.