Getting started
Which workflow should you automate first?
Find a worthwhile starting point with a practical scorecard for time, complexity, ownership and measurable improvement.
The useful part, upfront
- Choose a repeatable workflow with a clear owner and an observable result.
- Measure the time spent doing, checking and correcting the work.
- Start with a small boundary and agree how people will handle exceptions.
Look for work your team keeps chasing
The first useful automation project is often hiding in an ordinary working day. Someone copies the same information between tools, follows up a missing document, checks whether a job has moved or rebuilds a report from several spreadsheets. Each step looks small. Together, they consume attention the business needs elsewhere.
Start by identifying one of these recurring workflows. Describe where it begins, what needs to happen and what a finished result looks like. That is a more useful starting point than choosing an AI tool and searching for something to do with it.
This guide gives you a way to compare candidates before committing to a build. The aim is a manageable first project with a result you can measure, whether your business handles products, projects, appointments or professional services.
Map one real example from start to finish
Sit with the person who does the work and follow a recent example. Record what actually happened, including the spreadsheet beside the official system and the reminder someone kept in their inbox. Ask what happened the last time information was missing or a customer changed their mind.
Keep doing time separate from waiting time. A task may take ten minutes of effort but wait two days for approval. Those are different problems: faster data entry will not resolve an approval queue with no owner.
- Name the trigger: a new enquiry, an approved job, an incoming document or a scheduled reporting date.
- List each handoff: the person, the tool, the information needed and the next action.
- Define done: the correct record is updated, the draft is approved or the customer receives the agreed response.
- Mark exceptions: missing details, duplicates, cancellations and anything requiring judgement.
Compare candidates before picking a favourite
Use the checks below as a discussion guide. A workflow does not need to be perfect on every dimension, but gaps should become visible before the scope is agreed. The busiest process may have too many unresolved exceptions for a first pilot.
Shortlist two or three candidates. For each, write down what you know, what you are estimating and what you still need to confirm. This stops an appealing demo from doing the work of a business case.
More columns → Swipe, or focus the table and use the arrow keys.
| Check | A promising starting point | Investigate first |
|---|---|---|
| Frequency | Repeats often enough to observe | Only happens occasionally |
| Time | Handling and rework can be measured | The problem is described only as busy |
| Ownership | One person can define good work | Teams disagree about responsibility |
| Inputs | Required records are accessible | Key information is missing or unreliable |
| Exceptions | Common variations are understood | Every case follows a different path |
| Control | Outputs can be checked before action | Errors would be hard to spot or undo |
Draw a boundary your team can test
Consider a hypothetical business that receives job requests by email. Automating every step from enquiry to completion would involve scheduling, pricing, customer communication and delivery. A smaller first scope could prepare a job record from the enquiry and flag missing details for a person to review.
That boundary makes the test concrete: does it create accurate drafts, reduce handling time and make incomplete requests easier to resolve? Pricing decisions and customer commitments remain with the team. Once the first step works reliably, the next handoff can be assessed on its own merits.
Remove unnecessary steps before automating them. If two teams maintain the same list, agree which record should be authoritative. Otherwise, a new system may simply duplicate the same confusion faster.
Finish with a one-page pilot brief
A useful brief lets the operator, decision-maker and builder describe the same result. Keep it short enough to review together. Bring representative examples you are authorised to share, including awkward ones, and identify who can arrange access to the relevant systems.
- Problem: the repeated work, the people affected and its current weekly volume.
- Boundary: the trigger, the finished result and the steps excluded from this pilot.
- Inputs: the systems and records involved, with known quality or access gaps.
- Control: what a person approves, who handles exceptions and how work continues if the system is unavailable.
- Success: a target for handling time or turnaround, alongside an acceptable quality standard.
- Decision: who reviews the evidence and decides whether to extend, revise or stop.
Glow Saunas
See how Glow Saunas connected orders, suppliers and installation in one working system.
Explore the project