Most conversations about AI start with the model. The useful ones start with a task — a specific, repeated piece of work that someone on your team does every week and would happily never do again. Find that, and you have a candidate. Start from the model, and you usually end up with a chatbot nobody opens.

Start with the task, not the model

Write down the task in one sentence, the input it starts from and the output it produces. "Turn a supplier's PDF invoice into a row in our accounts sheet" is a task. "Use AI for finance" is not. If you can't describe the input and output, no model will fix that — the process needs defining first.

Three places it earns its keep

  • Drafting — first versions of product descriptions, replies, reports and summaries that a person then edits. The human stays the author; the blank page disappears.
  • Sorting — classifying support tickets, routing enquiries, tagging documents, pulling fields out of messy text. Repetitive judgement calls with a clear right answer.
  • Finding — search across your own documents, policies and past work, answering in plain language and pointing to the source.

Notice what these share: the output is easy for a person to check. That is the single best predictor of whether an AI feature will survive contact with a real team.

Where it doesn't belong — yet

Be careful anywhere a wrong answer is expensive and hard to spot: decisions with legal or financial consequences, anything that needs exact figures, and tasks where even your experts disagree on the right answer. In those places AI can still assist — gathering, summarising, flagging — but a person should decide.

The best AI feature is one your team forgets is AI. It just feels like the software got smarter.

Design for the wrong answer

Every model is sometimes wrong, so the interface around it matters more than the model itself. Show where an answer came from. Make editing faster than starting over. Validate structured output before it touches your database. Log what the model produced, so you can see where it struggles and improve it.

A small first project

Small, specific and checkable beats ambitious and vague. Once one workflow is genuinely faster, the next candidate is usually obvious — and your team will be the ones pointing it out.