How to choose your first AI workflow
Choose a repeated task with accessible inputs, a defined output and someone responsible for checking it. Measure the current work, including corrections and follow-up, before deciding what to automate. A narrow workflow that can be tested is a useful first candidate.
1. Choose a task with a clear finish
Write the task as one sentence: “When this arrives, prepare this output for this person in this system.” For example: when a freight enquiry arrives, prepare a booking draft for the operations coordinator in the booking system.
Define where the task stops. Preparing a draft does not include confirming a booking, making a payment or approving a claim unless those actions are explicitly in scope. List what the workflow must read, what it may change and who approves the next step.
Check whether your existing software already supports the task. A saved report, a form with required fields or a connection between two systems may solve the problem. Use AI where interpreting variable documents or correspondence adds value.
2. Bring ordinary and difficult input samples
Collect permitted examples of the records the team actually receives. Include complete submissions, missing fields, unfamiliar layouts and contradictory information. Record the expected output beside each example so a reviewer can judge the result against the source.
For the freight example, a useful sample includes the customer's enquiry, cargo details, a relevant agreed rate and the destination system's required fields. One enquiry might lack a cargo weight; another might give different delivery dates in its email and attachment. Both need a defined response.
Confirm how the workflow can retrieve current rates and create a draft in the booking system. Check account ownership, permissions and integration access before treating those steps as feasible. Avoid relying on someone repeatedly copying data into a demo.
Remove records you are not authorised to use, and agree where the remaining data may be processed. Our data and access guide covers the questions to settle during scoping.
3. Decide what happens when information is missing
For every required field, write a rule for a missing value, an uncertain match and a disagreement between sources. The workflow should show what needs attention and pass it to the responsible person. Guessing a value can make a complete-looking draft harder to check.
- Missing weight: leave it unresolved and prepare a request for the missing cargo detail.
- Conflicting dates: show both source references and require the coordinator to choose.
- No matching rate: route the enquiry to the pricing owner.
- System unavailable: retain the job's status and prevent a retry from creating a duplicate booking.
Agree which checks a reviewer performs and what information they need on screen. Put source references beside extracted values. Assign someone to resolve failed jobs, and make it possible to return to the manual process.
Test these cases before release. Microsoft's guidance on evaluating AI applications recommends pre-production evaluation with datasets and edge cases, followed by monitoring in production. A fluent answer alone does not establish that the workflow completed the correct task.
4. Measure time through to an accepted result
Record the period, task volume and work involved in the current process. Include reading, finding records, entering data, checking, corrections and chasing missing information. Keep waiting time separate from time spent working; they answer different questions.
Use the same definition of a completed task before and during the pilot. Track active minutes per accepted output, turnaround time, correction rate and the share of jobs that need extra help. A draft produced quickly can still leave substantial work for the reviewer.
A worked calculation
Suppose a team handles 120 enquiries in a month, spending 15 active minutes on each. That is 30 hours. If a pilot reduces the average to 8 minutes including review and corrections, the same volume would take 16 hours: 14 hours of capacity released.
These are illustrative numbers, not an All Squares result. They do not establish a cash saving. Deduct ongoing support effort and costs, and identify what the team could do with the released capacity before judging the value.
Keep comparable task types together. If the pilot only handles complete enquiries, compare it with complete enquiries in the baseline and report how many jobs remain manual. Comparing easy pilot jobs with the entire old workload would overstate the benefit.
5. Compare candidates before choosing a pilot
For each candidate, record the weekly volume, current effort, available samples, integration access, reviewer and consequence of an error. Choose work that has a useful benefit hypothesis and a practical test.
A supplier-quotation comparison could be suitable if prices, lead times and specifications can be checked against the original responses. A property correspondence workflow could be suitable if the output is a list of actions for a named manager. These are possible workflows to investigate, not accounts of completed client work.
Postpone a candidate if nobody owns its exceptions, access to a required system is uncertain or the team cannot say what a correct output looks like. Resolve those gaps before quoting a build.
Agree acceptance criteria with the owner: which fields must be correct, which cases require review, how failures are handled and what result would justify continuing. Start with drafts or a parallel run where practical. Microsoft's production monitoring guidance also distinguishes operational metrics from ongoing quality checks; keep both in the pilot review.
6. Bring a short brief to the opportunity audit
You do not need an architecture document. Bring enough detail to decide whether the first workflow is worth investigating:
- The task's trigger, output and stopping point.
- Permitted ordinary and difficult examples, with expected results.
- The systems involved and who controls access.
- A named process owner and reviewer.
- A baseline period, task volume and current effort.
- The exceptions that must be resolved before the next action.
All Squares starts with a free discovery call, followed by the Free AI Opportunity Audit to identify one or two priorities. Any implementation is scoped and quoted separately. Read how the engagement works, or bring one repeated process to a discovery call.
Questions before you start
Does the first workflow have to use AI?
No. If structured inputs and straightforward rules solve the problem, use them. The audit can recommend an existing tool, a process change, an integration or a custom build.
How do we know the pilot is ready to expand?
Review it against the agreed acceptance criteria, including difficult inputs, manual exceptions, support effort and the measured baseline. Expand when that evidence supports the next scope. A successful demonstration is a reason to test further.