Start with a recurring task whose result someone can check. Describe how people do it today, where they spend time and what would count as an improvement. Then you can assess whether AI helps or simpler automation is enough.
Bring a real example
Choose something that happened last week: a report someone rebuilt, an enquiry that needed sorting, or a document whose details were copied into several systems.
Ask the person who did the work to show the source material and explain the steps. Where did they need to think, search, copy or wait? That gives you more to work with than a list of tools the company could buy.
Write down four things before the test
- How often the task occurs.
- How much working time it usually takes, including review and corrections.
- What happens if the result is wrong.
- Who can decide whether the result is good enough.
Choose a task that can be reviewed
If nobody owns the task or can check the result, resolve that before expanding the trial.
Compare two or three tasks using the same questions. Choose one where you can obtain source material, follow the work and detect mistakes. A time-consuming task can still be a poor starting point if its result is difficult to judge or a mistake has consequences the test cannot contain.
Separate fixed rules from judgement
If the same fields always move between two systems, an integration may be a reasonable first step. If unstructured text needs summarising or sorting, AI may be worth testing. In either case, decide what information the tool may use and which exceptions a person will handle.
This assessment depends on the task. It does not establish that one model or product suits every business. Check the provider's current terms and access controls before using real customer information in a test.
An illustrative example
Suppose a company receives enquiries by email and records them in a CRM. An initial test could suggest a category and a short summary for each enquiry. A person reviews the suggestion before it is saved. The test sends no automatic customer replies and makes no pricing commitments.
Compare this with the previous method. Include time spent reviewing, correcting and handling information the tool does not understand. The example describes a possible test, not a completed client project or promised saving.
Agree what happens after the test
Decide when to evaluate the trial and which evidence to examine. Assess quality, working time, exceptions and whether the people doing the work can use the solution.
If the result does not justify further work, stop, change the scope or improve the underlying process first. Record why you continue or stop.
Include the eventual user in that decision. Ask them to demonstrate an ordinary case and an exception. If the test only works while its builder stands beside them, resolve the instructions, responsibilities or implementation before involving more users.
Fill this in before choosing
- The task starts when ... and is finished when ...
- It happens roughly ... times and takes ... minutes each time.
- The source material is in ... and access is owned by ...
- A mistake is detected by ... and handled by ...
- We continue if ... and stop if ...
Bring the workflow to the discussion
Leave question marks where you lack answers. They show what needs investigation. This method helps bound the work; it does not promise that AI will be the right solution.
Describe how the task works today and what you want to improve. Do not include customer records or sensitive source material in the form.
