Before you automate, how does the work really happen?

Choose a manageable piece of work with a recognisable outcome. Preparing a maintenance visit or assessing a changed order is more useful than a broad instruction to map everything the business does. Identify the starting event, the person responsible and the point at which someone else can rely on the result.

Write down what you want to learn. Perhaps requests repeatedly return for clarification. Perhaps only one person can approve an exception. Ask what prevents others from proceeding, rather than starting with the conclusion that a new interface is required. An observation should be capable of changing your proposed solution.

Include different circumstances. An experienced employee may fill a gap from memory that stops a newer colleague. A quiet office demonstration may omit interruptions encountered during a busy shift. Record the boundaries of what you have seen. A few visits can reveal important questions without representing every part of the operation.

Explain the purpose, the notes you intend to take and who will see the findings. Employees should know whether they are helping to investigate a workflow or participating in an assessment. Do not quietly turn one into the other. Provide a way to pause when a customer interaction or sensitive task makes observation inappropriate.

The GOV.UK guidance on contextual research explains how watching people in their usual environment can reveal barriers and workarounds. It also recognises a trade-off: questions improve understanding but interrupt the natural activity. Decide when to watch and when to ask for an explanation, rather than treating a narrated demonstration as identical to ordinary work.

Keep the record proportionate to the question. You may need to know that a delivery condition was found in an email, without copying that email or the customer's details. Agree any recording separately and secure the resulting notes. A useful account of the work does not need to become a collection of entire customer files.

Follow the handover, the phone call and the wait for an answer. Ask what the employee needed to establish and what could go wrong without that check. Do not infer that a paper note proves resistance to software. It may hold a commitment that the application cannot express, or it may persist after its original purpose has gone.

These are fictional examples to illustrate an investigation, not reported IndustrylinQ client results.

On a small screen, scroll horizontally to read the full table.

Each implication is a possibility to investigate. A conversation may be the right way to handle a difficult judgement. Removing it is not an improvement if the business loses a necessary check. Understand the function of a workaround before deciding whether to retain it, replace it or remove the underlying cause.

Build a short account of each observed case: what triggered it, what information was available, what decision followed and what was passed on. Distinguish active work from elapsed time. A gap between two application events does not tell you how long an employee spent processing the request.

Keep the observation separate from the employee's explanation and your own interpretation. Ask the people involved to correct the account. What happened before you arrived? Which important exception did not occur during the visit? Treat those answers as additional evidence to investigate, rather than rewriting your notes to imply that you witnessed them.

The GOV.UK guide to experience mapping brings together several people's experiences to expose steps and dependencies. It recommends separate maps where journeys differ substantially. Applied to business work, this means resisting a single tidy diagram when planned maintenance and an urgent repair follow materially different routes.

Include the recipient of a handover. A record can look complete to its sender while leaving the next person unable to act. Their questions help define what a usable outcome should contain, including unresolved conditions and the authority to make the next decision.

Imagine a fictional team that routes every amended order to its most experienced colleague. Observation suggests that others cannot find the customer's current agreement. Automatically forwarding all changes to the same person would preserve that dependency. Making agreements accessible and clarifying decision rights may open a better option.

Consider whether the work needs clearer information, a different allocation of responsibility or fewer unnecessary steps. Then decide which parts software should support. Preserve professional judgement where it is valuable, and specify when an employee should seek help. Autonomy requires a usable basis for action, not simply the removal of an approval button.

Try the proposed approach against familiar cases before turning it into a large development brief. Can someone proceed without knowing an undocumented arrangement? Is an exception visible? Can the next colleague use the output? A sketch or revised instruction may be enough for an initial test. It will not, by itself, establish an hours-saving estimate or justify an investment.

A worthwhile investigation ends with a clear problem, supporting observations and remaining uncertainties. Assign responsibility for the next step and tell participants what changed because of their contribution. Otherwise the business gains a diagram while employees continue doing the same detective work.

Start with one responsibility and follow it through the actual working environment. Business process analysis can connect the customer promise with practical organisation and delivery. Once the intended change is understood, software strategy can help determine whether to adapt, integrate, build or simplify the way the work is organised.