Before buying automation, agree the input, the completed handoff and who owns the exceptions. If those are unclear, map the process first.
Look for a dependable pattern
A good candidate has recognisable inputs and a result your team can describe. Start with a recent request and trace it to completion. Record who touched it, where information was copied, and what caused waiting. A frustrating task may still need a human decision; the useful opportunity could be preparing the information around that decision.
For example, a new client enquiry might need a brief, a named owner, and a discovery slot. Preparing the brief can be repeatable even when deciding whether the project is a fit remains personal.
A WORKED EXAMPLE
Assess a new-client intake workflow.
A worked example for planning, not a claim of measured savings: enquiries need a brief before discovery.
- Repeatable preparation
Collect agreed fields, prepare a summary and flag missing items.
What to checkThe account owner can verify the summary against the source.
- Human judgement
Leave project fit and commercial commitments with the account owner.
What to checkThe workflow does not turn a submitted enquiry into an accepted engagement.
- Pilot evidence
Compare preparation effort, correction work and complete handoffs.
What to checkThe team experiences less work overall, rather than a new review burden.
Check the exceptions before the happy path
Review a complete request, one with missing details, a duplicate, and a request that belongs elsewhere. Decide which can follow rules and which should stop for review. If nobody can explain the exceptions, map them before buying an automation.
An automated acknowledgement is not a completed handoff. The owner still needs enough context to act, and the original request must remain available when a generated summary is uncertain.
Compare the whole task
Measure preparation, checking, and correction as well as the time saved on typing. A system that creates a new queue of confusing exceptions can move work rather than remove it. Agree one or two measures with the people doing the task.
Use representative examples to test whether the output is useful. A small pilot should answer a specific question: can the team finish this handoff with less effort and acceptable quality?
Choose the smallest useful scope
Begin with one channel, one type of request, and one destination. Write down who owns failures and how the team can work manually if the system is unavailable. Expansion should follow evidence from the first workflow.
Your first deliverable can be a workflow map rather than a build. Clear ownership, better form labels, or a setting in an existing tool may solve the problem without a new system.
PUT IT TO WORK
Map one recent handoff.
Choose a request your team completed this week. With the person who handled it, reconstruct the input, the decisions and the final handoff on one page.
- Name its input and completed outcome.
- Record the owner and existing tools.
- List three exception cases.
- Agree one measure and a manual fallback.
A workflow candidate brief: trigger, inputs, accountable owner, completed outcome, three exceptions and a baseline measure.
If the inputs and finish are clear, discuss a single-workflow pilot. If decisions change with every request, begin with process mapping and approved rules.
Free editable notes for your team. No email needed.
Which recurring task should your team stop chasing?
Tell us what triggers the task, where it slows down and who needs the result. We can start with a general example.
You’ll see what we deliver, what your team needs to provide, and how the result is reviewed. A written proposal confirms the scope and price before work begins.
Review scope & deliverables