How to Observe Real Work Before Proposing an AI Use Case

A complaint is a research lead, not yet an AI use case. Suppose an operations team says client onboarding briefs take too long and asks for an AI summariser. A workflow map drawn from memory may make drafting look like the problem. Completed cases may instead show that difficult briefs wait for missing commercial decisions and are rewritten after contradictory source fields are resolved. The complaint remains valid evidence of the team's experience, but it does not by itself establish where the recurring constraint sits, how often it appears or what consequence follows. That requires observing a bounded sample of real work and preserving evidence that challenges the initial story.

What should you define before observing a workflow?

Define the workflow's trigger, end condition, output, downstream user, participating roles and relevant case types before entering the field. Begin with recurring work and real outputs, not the broad question of where a team could use AI. Write down the questions the field round must answer: where information arrives, where it changes hands, which decisions alter the path and what distinguishes routine work from exceptions. Treat this boundary as provisional because observation may expose an upstream dependency or a downstream acceptance step that the remembered process omitted.

For the onboarding example, the boundary runs from an approved sales handoff to a brief accepted by a delivery lead. It includes routine, incomplete and changed-scope cases, plus coordinators, sales operations and delivery leads. The output is not merely a drafted document; it is an accepted brief that another team can use. Plan research around this definition and the unanswered questions. The method here is a practical editorial synthesis, not a standard protocol: choose the smallest proportionate combination of interviews, observation, artefacts, diaries and records that can answer those questions.

• Record the trigger, end condition and accepted output.
• Name the downstream user and every role at a consequential handoff.
• Include routine and exception case types relevant to the research question.
• List the decisions, variations and dependencies that need evidence.
• Revise the boundary when field evidence shows that the real work crosses it.

How can a recent-case interview reconstruct what happened?

Ask the participant to reconstruct one specific, recently completed case from trigger to accepted output. Open, neutral prompts keep the account anchored in experience: “What happened next?”, “What told you that?”, “Who did you contact?”, “What was uncertain?” and “Can you show the item you used?” Follow the sequence through inputs, decisions, handoffs, exceptions and revisions. Do not ask the participant to design an AI feature during this reconstruction; that would shift attention from evidence about work to speculation about a solution.

1. Establish what triggered the case and what arrived.
2. Reconstruct each action, decision and handoff in sequence.
3. Probe the information cues, alternatives, uncertainty and difficult judgements behind visible steps.
4. Ask to see the relevant form, message, checklist, draft or queue item.
5. Confirm what counted as an accepted output and where the case departed from the expected path.

Pair a routine onboarding brief with a difficult one and include people on both sides of important handoffs. Colleagues who perform a service together may be interviewed jointly, and an interview can be combined with a demonstration. Original workflow research has shown that demonstrations and artefacts can elicit details omitted from verbal descriptions. Cognitive-demand probing also helps reveal cues and judgements that a click-by-click map misses, though this compact sequence should not be described as the formal ACTA protocol. One case illustrates a path; it does not represent the whole workflow.

What should you watch in the normal work setting?

Watch the task with its usual equipment, documents, data, interruptions and dependencies. Note source switching, waiting, verification, rework, handoffs, workarounds and moments when incomplete or conflicting information requires interpretation. In the onboarding case, observe how a coordinator assembles a live brief: which sources are consulted, which fields trigger clarification, when work pauses and what must be checked before the delivery lead accepts it. Contextual observation can reveal barriers and support activity that are difficult to reconstruct later, but it remains a small, interpretive sample.

Choose an observation mode and record it. Silent observation preserves more of the natural flow but may leave motives unclear. Occasional questions add context with some interruption. Continuous explanation provides depth while changing the activity more substantially. Separate observed action from researcher interpretation in the notes so another reviewer can challenge the inference. A useful structure records case context, action, artefact reference, decision or uncertainty, handoff, interruption, consequence and interpretation. At the end, ask the participant to confirm, correct or qualify the reconstructed flow.

• Frame the exercise as research into the workflow, not an assessment of individual performance.
• Obtain informed participation and explain the chosen observation and recording modes.
• Collect only material required by the research question and restrict access to it.
• Reconfirm consent before introducing any new recording.
• Involve appropriate privacy, security, legal, labour, accessibility and domain owners where the work requires it.

Do not turn workflow research into employee surveillance. Avoid covert monitoring, continuous recording, keystroke capture, screenshots and individual productivity scoring. Securely handle any personal, customer, confidential or regulated information that enters the evidence set. These safeguards do not settle local legal or workplace obligations; the relevant organisational owners must do that. They do establish a sound research posture: participation is informed, collection is proportionate, the purpose is non-evaluative and the resulting interpretation remains open to participant correction.

Which methods reveal what interviews or observation can miss?

Artefacts, short task diaries and operational records extend the view across states, cases and time. Ask participants to explain the templates, checklists, spreadsheets, messages, drafts, paper notes and queue views used in a case. Their layout and markings may carry memory cues, priorities and coordination practices missing from the official process map, as an original workflow study found. Confirm what each artefact means and how it is used; possession of a checklist does not establish that it governs every case.

Use a brief diary when the relevant task is intermittent, distributed or unlikely to occur during scheduled observation. Tie each entry to a real instance, then clarify it later. An applied GOV.UK project used diaries near actual guidance use alongside interviews and observed tasks, but that example does not create a universal study duration or prompt frequency. Where usable records exist, inspect case sequences and timestamps for waiting, rework, duplicated handling, deviations, missed deadlines and recurring quality problems. Document work outside those systems because logs are partial evidence.

For onboarding briefs, compare the intake form, source records, messages, checklist, draft trail and correction comments. Diary entries can capture missing inputs and revisions close to each case, while available queue age, returns and missing-field reasons can test recurrence. Do not assume a timestamp explains why a delay occurred. Retain less common paths until their effort and consequence are understood; exceptions may carry substantial rework even when routine cases dominate. No illustrative process-mining distribution should become a universal threshold.

When does a pain point become a credible bottleneck hypothesis?

A reported pain point becomes a credible bottleneck hypothesis when evidence places a recurring constraint at a defined workflow point, connects it to an observable consequence and survives counterevidence. Triangulation does not mean voting among methods or treating records as superior to experience. It means asking whether cases, roles and evidence sources tell a coherent story while retaining what does not fit. Operational data may reveal waiting or rework, and participant confirmation may improve the mechanism, but neither establishes causation.

1. Recurrence: Does the constraint appear across more than one relevant case, role or evidence source?
2. Location: Where does the queue, wait, rework loop, information gap or judgement overload enter?
3. Consequence: Is it connected to observable delay, repeated handling, correction, inconsistent output, avoidable effort or risk?
4. Mechanism: How might the constraint produce that consequence, and do people doing the work confirm or correct the account?
5. Counterevidence: Which cases avoid the problem, what differs and which alternative explanations remain?
6. Actionability: Could changing this point alter the outcome, and is AI more suitable than a rule, ownership change, process redesign, training, better information or no intervention?

In the example, the hypothesis shifts from slow summarisation to missing decisions and contradictory fields in difficult cases. Routine briefs are completed quickly, longer briefs are not consistently slower, and system timestamps omit offline clarification. The evidence therefore supports a bottleneck hypothesis, not causal proof. If recurrence, location or consequence remains unclear, keep the complaint as an open lead and gather more evidence. If the account is coherent but uncertainty remains, design the smallest test that could distinguish the leading explanation from its alternatives.

Do not ask where AI fits until you can show where a recurring constraint appears, what follows and what remains uncertain.

What belongs on an evidence-backed AI opportunity card?

An evidence-backed opportunity card is a bounded decision record, not a sales pitch for AI. Record the workflow boundary, observed period, represented roles and case types, method mix, stated pain, observed pattern and operational consequence. Link substantive statements to field-note identifiers, redacted artefact identifiers, diary entries or record queries; mark anything else as an assumption. Preserve counterevidence, gaps, disagreement and alternative explanations instead of hiding them inside a composite confidence score.

• State who needs help with which bounded task and what better outcome is sought.
• Record information availability, data quality, permissions, security, privacy, labour, accessibility, domain and human-oversight constraints.
• Compare an AI assist with deterministic rules, workflow or ownership changes, training, better information and no intervention.
• Define the next smallest test, the assumption it addresses, relevant cases, success and failure evidence, an owner and a review date.
• End with one decision: test AI, test a non-AI change, gather more evidence or stop.

The NIST AI RMF Playbook's voluntary Map guidance supports documenting purpose, users, operational setting, value, limitations, impacts, scope and human oversight, while also considering non-AI alternatives. Official discovery guidance similarly retains an evidence requirement, owner, milestone and later test rather than treating workshop agreement as proof. For onboarding, first test required intake fields, an explicit handoff owner and a visible exception queue. Consider drafting assistance later only for fact-complete cases. Propose AI when a bounded task, recurring constraint, observable consequence, workable information and oversight support a testable advantage over simpler alternatives; otherwise gather evidence or stop.