Your first AI project should start with a workflow

An AI project becomes easier to evaluate when it starts with a specific job. “Add AI to the business” leaves too many decisions open. “Help the team turn incoming enquiries into a reviewed brief” gives you a beginning, an end, and someone who can tell you whether it works.

The aim of a first project is to learn whether a system can improve a real workflow under the conditions your team faces every day.

Start where the work repeats

Choose a task you can observe. Incoming enquiries, meeting notes, document intake and internal questions can all be candidates. The useful question is where people repeatedly read information, make a small decision and pass something along.

Write down the trigger, the person responsible, the information they need and the next action. Include the awkward cases: missing details, conflicting instructions and customers who change their minds.

A workflow with no clear owner is difficult to improve. Assign someone who understands the task and can review the pilot's output.

Separate rules from judgment

Some parts of a process have an exact answer. If a required field is missing, ask for it. If an appointment slot is occupied, do not offer it. Ordinary software rules can handle those steps.

Other parts involve interpreting language: summarising an enquiry, recognising the intent of a request or drafting a reply from approved information. Those are places to test AI assistance.

Keep the distinction explicit. A model can suggest an action while a separate rule checks whether that action is permitted. Give the system only the tools and data it needs for the job.

Define a useful result

Decide what you will measure before building. A useful measure belongs to the workflow: time spent reviewing a brief, missing information caught before a handoff, or the number of drafts that need substantial correction.

Collect a small, representative set of examples from the current process. Remove personal information where it is unnecessary. Keep difficult examples in the set rather than testing only tidy inputs.

For each example, write down what an acceptable result would look like. This makes review more concrete than asking whether an output “looks good”.

Keep the first release bounded

A first release can prepare a draft without sending it. It can recommend a category without changing the customer record. It can highlight an exception without deciding what happens next.

These boundaries let the team learn where the system is dependable and where it needs supervision. They also make it possible to stop the pilot without interrupting the original process.

Before allowing an external action, define who approves it, which records it can change, and how a mistake can be corrected.

Write the pilot brief

A useful brief fits on a page:

• The job: what the system should help someone complete.
• The inputs: the information available at the start.
• The output: the specific artifact or action the team needs.
• The boundary: what the system must hand back to a person.
• The test: how the team will judge representative examples.
• The owner: who reviews results and decides whether to continue.

Start with a job the team recognises. Build around its constraints. Expand only when the evidence from that workflow supports the next step.