A task happens every week. Someone copies information, asks for approval, follows up, and eventually marks it complete. It looks like a good candidate for automation. But before choosing a tool, ask a different question: can the team explain the task in the same way?

If one person believes approval is optional and another waits for it every time, a faster notification will not settle the disagreement. Start by making the work visible. A sheet of paper and the people who actually do the task are enough for a first version.

Choose one journey, not the whole business

Pick a recurring piece of work with a recognisable beginning and end. “Manage sales” is too broad for a useful first session. “Turn an approved quotation into a confirmed delivery” is easier to discuss.

Write the starting event and the evidence that proves the work is finished. For example: a customer accepts the quotation; the delivery is recorded and the customer receives confirmation. Keep related activities outside this boundary on a separate list. You can return to them later.

Describe what happens today

Ask each participant to describe the most recent real instance, including the awkward parts. What arrived? What did they do? What did they need before moving forward? Avoid drawing the procedure everyone wishes they followed.

ASQ’s flowchart guidance recommends defining the process boundaries, arranging its steps, and checking the result with the people involved. Use a simple box for an action, an arrow for the next step, and a decision point wherever the route changes.

Beside each action, add the person or role responsible and the item they work with: an email, an order record, a document or a physical product. Mark any place where work stops while someone waits for information or a decision.

Make the handovers visible

Consider this fictional example. A small supplier receives an accepted quote by email. A salesperson checks the delivery address, operations checks availability, and a dispatcher books the delivery. The dispatcher sometimes receives only a screenshot of the quote, so they ask the salesperson for the address again.

The useful discovery is not “we need more notifications”. It is that the handover lacks an agreed set of information. The team could first require an order reference, confirmed address, delivery contact and promised date in one shared record. That change can be tested before any integration is built.

For each handover, ask:

  • What must the next person receive?
  • How will they know the task is ready for them?
  • What should happen if something is missing?
  • Who owns the task while it is waiting?

Separate the normal route from exceptions

A map that only handles the easiest case will be incomplete. Add a short list of common exceptions: incomplete details, unavailable stock, a changed request or an absent approver. You do not need to diagram every possibility in the first session.

Choose one exception and agree who decides what happens next. Avoid hiding it inside a vague step such as “resolve issue”. A useful instruction names the decision and the responsible role. If the answer depends on judgement, keep that judgement visible rather than treating it as an automatic rule.

Test one change before adding more

Choose a small experiment, such as a clearer handover template. Record a few comparable examples before and after the change. You might count how often someone has to request missing details, or how many items are waiting without an owner. Keep the measurement simple enough to maintain during normal work.

Agree a review date and a person responsible for collecting feedback. A trial is still useful if it reveals that the proposed change adds work without solving the original problem. Adjust it before expanding it.

A short exercise for your next team meeting

  1. Name one recurring task and define its start and finish.
  2. Walk through a recent example with the people involved.
  3. Draw the steps, decisions and handovers on one page.
  4. Circle one unclear handover or recurring wait.
  5. Agree one change, one owner and one review date.

Automation becomes a more focused discussion when the team can point to a clear rule, a reliable input and an expected result. Until then, improving the shared understanding of the work may be the most useful first step.

For a related next step, read our practical handover checklist for small teams.