In this guide
All resourcesChoose a workflow with a visible start and finish, a responsible person, accessible information, and a way to check whether the change helps.
Start with the work, before the technology
A first project needs a clearer description than ‘we need AI’ or ‘we need a new system.’ Begin with a task the team recognizes: collecting a set of documents, assigning a new enquiry, or preparing a routine follow-up.
Watch the process happen. Identify where someone copies information, waits for another person, checks a record, or resolves an exception. The useful problem may be a missing owner or an unclear checklist, rather than a lack of software.
Keep the first task small enough to understand from beginning to end. A company-wide assistant can wait until the team knows which information, permissions, and daily tasks it should serve.
Write a six-question workflow brief
Answer these questions in plain language. A rough example is more useful than a long feature list. Use synthetic or redacted information for an early discussion.
- Trigger: what starts the work?
- People: who does it, who reviews it, and who owns the outcome?
- Inputs: which information is needed, and where does it come from?
- Steps and tools: what happens today, and in which systems?
- Exceptions: what is missing, ambiguous, duplicated, or likely to fail?
- Success: what observable change would make this worth doing?
Compare a few candidates
Look for recurring work with inputs the business is permitted to use and an outcome a person can inspect. Avoid selecting a task solely because its demo looks impressive.
The table is an illustrative shortlist, not a rating of your business. Check the assumptions with the people doing the work before choosing a pilot.
| Candidate | What to establish | A useful first boundary |
|---|---|---|
| Document collection | An approved checklist and a named reviewer | Prepare missing-item follow-ups for approval |
| New enquiry handoff | A clear routing rule and a system of record | Assign a task; keep unusual requests visible |
| Company-wide assistant | Many source permissions and different user needs | Begin with one team's approved procedure library |
An illustrative document-collection workflow
Suppose an accounting team repeatedly checks whether the documents needed for an engagement have arrived. The first improvement might be a shared checklist with an owner and a visible list of missing items.
An integration could update the checklist when an approved source receives a document. AI might help classify a document or prepare a draft message, if those outputs can be checked. Neither is required merely to make the outstanding work visible.
Illustrative workflow: approved checklist → documents received → missing items flagged → accountant checks the follow-up. No message is sent automatically, and professional decisions stay with the accountant.
Measure usefulness, including the review work
Record a simple baseline before changing the process: volume, hands-on effort, waiting time, exceptions, and rework. Pick a measure that reflects the problem instead of an attractive number that is easy to report.
After a pilot, include the time spent checking outputs, correcting errors, and maintaining integrations. A faster draft is only useful if the complete task becomes easier or more reliable for the team.
Use representative examples, including incomplete inputs and failures. Agree who reviews the results and what would make the business continue, change direction, or stop.
Choose the smallest useful next step
Compare a process change, configuring an existing tool, a supported integration, and custom software. If the current product can solve the task well, a new application may add more maintenance than value.
Before a build, bring the workflow brief, an example, the existing tools, access constraints, and a named owner. Agree the first release, its review boundaries, the evidence needed, and who will operate it afterward.
