The most common starting mistake
A familiar pattern: someone sees a demonstration, gets excited, and the team starts comparing products before anyone has said what needs fixing. Weeks later there is a subscription, a handful of curious users, and no clear way to tell whether it helped.
Writing the problem down first reverses that order. It is a small amount of effort that makes everything after it easier, from comparing options to deciding whether a trial worked.
What a good task statement contains
A useful statement is short, specific and about the work, not about technology. Try to answer these questions in plain sentences.
- What is the task? For example, “answering routine questions about order status” or “turning meeting recordings into a list of decisions.”
- Who does it today, and how often? One person weekly is a different problem from a whole department daily.
- What are the current steps? List them, even roughly. The steps often reveal that the slow part is waiting for approval, not the task itself.
- What goes wrong? Delays, mistakes, inconsistency, boredom, backlog.
- What does a good result look like? Describe it without mentioning any tool.
- What must not happen? For instance, “no customer details leave our systems” or “nothing goes out without a person reading it.”
If your answers fill half a page, that is plenty.
Check whether it needs AI at all
Once the problem is clear, you may find that AI is not the answer. A fixed sequence of steps that never changes can often be handled by rules-based automation, a spreadsheet formula or a better form. Those options are usually more predictable and easier to explain. Tasks with variable wording, fuzzy judgment or large volumes of text are where AI tools tend to be considered, and even then they work best with a person reviewing the output.
It also helps to be honest about tasks that do not suit an assistant. The list of poor-fit tasks is worth skimming before you commit to a direction.
Separate the symptom from the cause
“Our reports take too long” is a symptom. The cause might be messy data entry, unclear ownership, or three people reformatting the same numbers. A tool that speeds up one step does not fix a process that is broken elsewhere.
Ask “why” a few times. If the answer keeps pointing to missing information or inconsistent habits, fix those first. Automating a confusing process generally produces a faster confusing process, which is one of several reasons why broken automations happen later.
Size the problem honestly
You do not need exact figures, but a rough sense of scale helps you judge how much effort a solution deserves. If a task takes a few minutes a week, a costly tool is unlikely to make sense once setup and review are included. If it consumes many hours across a team, there is more room to justify the effort.
Here is a hypothetical example, with numbers invented purely for illustration. Suppose four people each spend 2 hours a week on a repetitive formatting job. That is 8 hours a week in total. If a tool removed half the effort, which is far from guaranteed, the gain would be about 4 hours a week, before subtracting the time spent checking results. Seeing the arithmetic keeps the discussion grounded, and the fuller picture of total cost shows what else belongs in the comparison.
Decide how you will know it worked
State the measure before you look at any product. It might be time per task, number of corrections, response time or a satisfaction score from the people involved. Picking success measures up front prevents the common habit of judging a trial by how impressive it felt.
Record the current baseline too. Without a “before,” there is no honest “after.”
Turn the statement into a shopping brief
A clear problem statement becomes your filter. Each candidate tool can be held up against it with simple questions: does it handle this specific task, with our kind of inputs, within our data limits? Anything that does not is a distraction, however good the demonstration.
The statement also gives you something precise to hand a vendor, which makes their answers more useful. It feeds directly into the wider process for how to choose tools, and into the scope of a small pilot project.
A short template
Copy this into a document and fill it in:
- Task and owner:
- Frequency and volume:
- Current steps:
- Main pain points:
- Desired result:
- Limits (data, accuracy, approvals):
- Success measure and baseline:
If you cannot complete a line, that gap is useful information. It tells you what to find out before spending money.