# How to choose your first AI workflow

> Compare AI workflow ideas, identify blockers and choose a small first test with a clear owner, useful baseline and manageable consequences of error.

Author: HARTRO
Published: 2026-10-21
Topics: Agents, Engineering
Canonical URL: https://hartro.com/blog/choose-first-ai-workflow/

Choose a recurring workflow where you can inspect the inputs, recognise a good result and name the person responsible when something goes wrong. Then check whether improving it matters enough to justify the effort. The best starting point may use an existing product, a few rules or a simpler process.

A list of promising AI use cases helps start a conversation. It does not tell you which one to fund. “Automate finance” might mean extracting invoice fields, resolving disputed charges or approving payments. Those tasks involve different information, authority and consequences. Treating them as one opportunity hides the decisions that determine whether a project is sensible.

This guide works through three fictional choices and ends with a brief you can use to commission a first test.

## Describe one piece of work from beginning to end

Start with a task someone actually performs. Sit with that person while they work through an ordinary case, a difficult case and something they cannot complete. Follow the handovers as well as the screen activity.

Write a sentence with four parts: what starts the work, what information the person uses, what result they produce and who accepts it. For example:

> When a supplier invoice arrives, a finance colleague checks the document against the purchase order, prepares a proposed record and sends discrepancies to the budget owner.

That description reveals several possible improvements. Missing purchase orders might be the main delay. An existing accounting feature might already extract the fields. The useful AI task might be limited to interpreting varied descriptions, while rules handle totals and a person resolves discrepancies.

Faculty's [Decision Loops methodology](https://faculty.ai/en-gb/insights/articles/decision-loops-a-methodology-for-translating-business-problems-into-well-designed-ai-solutions) similarly works back from an objective through the decision maker, available actions and required analysis. The practical question is: if this output improves, what can someone do differently?

## Use value and feasibility, then inspect what they conceal

Consulting approaches share considerable ground. [appliedAI](https://www.appliedai.de/en/offering/ai-strategy-consulting/) describes prioritising opportunities by return and feasibility. [BCG's discussion of AI pilots](https://www.bcg.com/publications/2026/why-ai-pilots-rarely-deliver-value) argues for concentrating on consequential workflows and redesigning the surrounding process. Both are useful checks against building something impressive with little operational effect.

Delivery accounts add detail to that comparison. [Heyra's methodology](https://heyra.ai/) includes interviews about manual work and exceptions, alongside operating ownership and build-or-buy decisions. Sierra's [account of agent engineering](https://sierra.ai/blog/meet-the-ai-agent-engineer) describes scoping with customers and integrating the systems needed to complete their work.

The useful combination is a business outcome you care about and a sufficiently close understanding of the work to test it. A high-level opportunity score cannot establish either on its own.

## Compare three competing workflows

**Everything in this example is synthetic.** The company, volumes, time estimates and constraints are invented to demonstrate the decision. They are not client results, benchmarks or tested savings.

Imagine an operations team considering these options:

| Candidate | Current work and potential benefit | Available evidence and owner | Consequence of error | First decision |
| --- | --- | --- | --- | --- |
| Route incoming enquiries | About 600 messages a month; initial handling appears to take 2–4 minutes. Better routing might reduce transfers. | Operations lead owns the queue. Historical messages and final destinations are available for an approved test. | A wrong destination delays a reply; sensitive messages need restricted handling. | Compare existing routing rules with an AI suggestion that a person confirms. |
| Prepare invoice entries | About 250 invoices a month; preparation appears to take 6–10 minutes. Drafting might reduce typing. | Finance owns the task, but access to representative documents and purchase orders has not been approved. | Wrong amounts, duplicates or changed bank details could affect financial records. | Defer the build; resolve access and review arrangements first. |
| Decide contractual exceptions | Roughly 20 requests a month; each can require substantial discussion. | No agreed decision owner or maintained record of which policy exceptions are permitted. | An incorrect answer could create a commitment the company did not intend. | Keep decisions with authorised people; clarify policy and ownership. |

Invoice preparation has a plausible larger pool of manual effort. It also has an immediate blocker. Contractual exceptions look expensive, but expensive discussion is not necessarily waste: it may be where the organisation makes a judgment it has never formalised.

Enquiry routing is the first candidate worth testing under these assumptions. That does not mean it is worth buying. If a handful of rules handles the recurring categories, the AI proposal still has to earn its place.

The ranking changes when the facts change. If routing takes seconds and most delay comes from unanswered messages, improving classification will do little. If finance approves the inputs and already has a reliable review process, invoice drafting could become the better candidate. Record what would change your decision rather than presenting the table as permanent truth.

## Do not average away a blocker

Use separate checks before comparing likely benefits. Three deserve particular attention.

**Can the test use representative information?** Having documents somewhere in the business does not establish that the project can access or process them. Identify the sources, permitted users and test environment. Sanitised examples can help development, but a test built only from clean examples cannot establish performance on missing pages or messy attachments.

**Who owns the result and the exceptions?** Name a person with authority to define acceptable work, resolve disagreements and decide what happens next. Also establish who maintains the process after the builders leave. “The business” is too vague to accept a delivery.

**Can a consequential error be contained and detected?** State what the system may suggest, change or send. A draft invoice entry is different from posting a record, changing supplier details or making a payment. Human review is only useful if the reviewer has the information, time and authority to catch the relevant mistakes.

An unresolved check means preparation or a narrower scope. It cannot be cancelled out by a large estimated benefit. Thoughtworks' [path to production](https://www.thoughtworks.com/en-us/insights/articles/Path-to-production-for-enterprise-AI) also separates decision gates for ownership, feasibility, controlled testing and operational handover. A first experiment need not reproduce an enterprise governance programme, but it does need explicit permission and responsibility.

## Give the simpler alternatives a fair trial

Before commissioning custom development, compare ways to achieve the same outcome:

- Remove a step, clarify an instruction or improve the intake form.
- Keep the work manual where judgment matters or the volume is too small.
- Use rules for stable categories, required fields and calculations.
- Test a capability already available in the team's software.
- Use AI for the part that needs interpretation, with bounded actions and review.

For the fictional enquiry queue, a better form could collect the product and region before the message arrives. Rules could route those fields directly. AI might still help with messages arriving outside the form, but that is a smaller project with a smaller benefit.

Estimate the remaining opportunity after these changes. Include checking, corrections and exception handling. Someone typing less does not establish that the team finishes useful work sooner. The [worked AI cost and ROI guide](/blog/ai-project-cost-and-roi/) shows how to carry those assumptions into an economic comparison.

## Design a test that can change the decision

For enquiry routing, first agree a destination policy with the queue owner. Then assemble permitted historical messages covering common categories, ambiguous requests and sensitive cases. Record the expected action for each, including “send for review.”

Run the current process, a simple rules approach and the proposed AI assistance against comparable work. Keep the real queue unchanged during this first test. Measure destination quality, consequential misroutes and the total human handling effort, including checking suggestions and fixing mistakes. Record cases where people disagree about the right destination separately: those may expose a policy problem rather than a model failure.

The decision might be to use rules, improve the intake process, continue testing AI on a narrower category or stop. A good test makes those outcomes possible. It should not require buying the full system before learning whether the central assumption holds.

There is no universal sample size or accuracy target that makes this safe. The cases, consequences and intended next step determine the evidence needed. A historical test also leaves questions about live adoption and operational reliability. Use the [AI pilot evaluation guide](/blog/evaluate-ai-pilot/) to define that next decision.

## Buy the next piece of evidence

A useful first brief should fit on a page:

| Question | What to record |
| --- | --- |
| What improves? | A specific operational outcome and the current baseline, with unknowns identified. |
| What is in scope? | The trigger, inputs, proposed output, users and excluded actions. |
| What must hold? | Approved data access, a named owner, review arrangements and unacceptable failures. |
| What will be compared? | The existing process and at least one plausible simpler alternative. |
| What happens afterwards? | The evidence needed to continue, narrow, prepare further or stop. |

Ask a supplier what they need from your team, which assumption they will test first and what you will receive if the answer is to stop. Keep responsibility for the final business decision explicit, including when an engineer works closely with the team. Our article on [forward deployed engineers and consultants](/blog/fdes-vs-consultants/) explores that delivery relationship.

If you have several ideas, bring one recurring workflow and its difficult exception to a [HARTRO workflow assessment](/services/ai-workflow-assessment/). The immediate task is to establish which option deserves a test and what that test must resolve.

*Sources checked on 21 October 2026. The workflow comparison and proposed test are illustrative; no client outcomes or tested savings are claimed.*