Start with the workflow, not the model

Many AI conversations begin with a product question: which model, platform, vendor, or chatbot should we choose?

That question matters later. At the start, it can distract from the more important decision: what work should change, for whom, and under what conditions?

A team can evaluate software for months and still have no usable workflow. The more reliable starting point is to map one piece of work before choosing the technology that supports it.

Define the work before the tool

Before scoping a build, we clarify four things:

• Trigger: What starts the workflow? It may be an after-hours inquiry, a shipped order, a newly received document, or a customer who has become inactive.
• Process and inputs: What happens between the trigger and the intended outcome? Which systems, documents, or people provide the information required at each step?
• Accountability and review: Who receives the output? Which decisions or communications require a person to review or approve them?
• Outcome: What should improve if the workflow works? Examples include response time, manual effort, setup time, or follow-up completion.

A project becomes easier to assess once those answers are written down. Without them, the team risks automating an undefined process or adapting its process around a vendor’s limitations.

The workflow can change the proposed solution

A workflow map often reveals that the best solution is simpler than the original AI brief.

An EU health and supplement retailer initially asked about AI. The operational issue was different: the webshop and warehouse held separate stock records, which staff reconciled manually. The appropriate solution was a carefully tested two-way synchronisation, not a large AI platform. It covered roughly 7,000 products and removed recurring manual reconciliation.

In other cases, language capability is central. A workflow may need to read a dense protocol document, classify information, or prepare a response based on live data. In those cases, a model is valuable—but as one component inside a process whose inputs, owner, and review rules are already defined.

Build the durable part first

Models will continue to change. A well-designed workflow should make it possible to replace or update a model without redesigning the business process around it.

The durable work is elsewhere: connecting the right data, defining the trigger, setting approval rules, logging important actions, and agreeing how success will be measured. Those decisions outlast a particular vendor release.

A contained first implementation creates evidence

A first workflow should be narrow enough to ship and assess without creating a broad transformation programme.

For example, an Avena Fitness reactivation campaign moved from kickoff to its first send in three weeks using the client’s existing member list. The point was not speed for its own sake. The point was to create evidence while the original process was still visible: what happened before, what changed, and whether the result justified a next step.

Before shortlisting a vendor, document one workflow. If you would like an experienced second view, bring the trigger, the people involved, and the outcome you want to improve to a workflow review.