Business process discovery for workflow automation

This is the business process discovery method AR Labs uses to find out how a small service business really runs before designing any automation for it. It combines interviews with recordings of real work, analyses those recordings with AI agents (language models run in a loop with tools, so they can act as well as reply), and keeps a strict line between what was seen and what it is taken to mean. It is written for owners deciding how to prepare for automation and for anyone running discovery for one. We developed and used it on the music school automation case study; the guide on how to map a business process before automating it gives a version an owner can run alone.

Why recordings, not just interviews

People describe their work as they think it runs. Recordings show how it does run. In the music school engagement, interviews gave the workflows in words, and the first recordings showed that the email inbox, not the lesson platform, was the machine running the school: labels as pipeline stages, scheduled-send for re-contact, snooze as the follow-up timer. Nobody had described it that way, because to the people doing it, it was just how they used email.

Recordings also have a limit. Silent footage shows actions but not reasons, so a decision made from memory looks like nothing happened. We now ask for at least one narrated session, in which the person thinks aloud while working. In the music school engagement, that one narrated session became the strongest evidence and moved the centre of the design.

How it works

flowchart TD
  C["Capture: the client records real work"] --> AC["Audio check: is it narrated?"]
  AC -->|"narrated"| TR["Transcribe in full, with timestamps"]
  AC --> EX["Extract keyframes at a fixed cadence"]
  TR --> FO["Vision fan-out: agents describe frame runs"]
  EX --> FO
  FO --> LOG["Timestamped workflow log, tagged by process"]
  LOG --> MOD["Current-state model: who touches what"]
  LOG --> INV["Problem inventory and error ledger"]
  LOG --> CEN["Time census and switch count"]

1. Capture. The client records their screen while doing ordinary work. Long recordings arrive in parts; we check for duplicates and asks for files to be sent as documents rather than video messages, because messaging apps re-compress video and small text becomes unreadable.
2. Audio check. If a recording has narration, every clip is transcribed in full with timestamps using Whisper, OpenAI's open-source speech-recognition model, run locally. The transcript becomes a second evidence stream.
3. Extract. Keyframes are pulled with ffmpeg at a fixed interval. The music school's first round used about ten seconds; later rounds used five, which catches spreadsheet edits and form flows mid-action.
4. Vision fan-out. The frames are split into contiguous runs of about 40 to 60, and each run goes to one vision-capable AI agent. Each agent gets a short primer on the tools likely to be on screen, phrased as open questions so that new tools get documented rather than mistaken for known ones; a fixed set of process tags (intake, scheduling, re-engagement, cancellation, billing, summary, delegation, admin); its slice of the transcript; and a structured output format with an explicit instruction to flag evidence of time cost, errors or lost information. This step is pure extraction, so it runs on a lower-cost model tier.
5. Synthesise. The main session merges the agents' returns into one timestamped workflow log, with each event tagged by process and the flagged evidence collected in one ledger.
6. Update the downstream model. Each round updates the current-state model, the problem inventory and the time census. Frames are promoted to evidence stills only when a specific claim cites them, one still per kind of claim.

Keeping evidence honest

The evidence is kept in four layers: what was observed, what it means, what was decided, and what the client is shown. Each layer cites the one before it and never restates it. A source log is never edited to fit a conclusion; if a summary and its source disagree, the summary is wrong or the source is incomplete, and the analysis says which. Inference is marked as inference, and anything never caught on camera is recorded as never observed rather than modelled as seen.

Two other rules keep the numbers usable. Timestamps stay local to the clip they came from, so every claim can be checked against the footage. And measurements from different kinds of session are not averaged: an ordinary admin day and a peak scheduling session measure different work, and each keeps its own census with a note saying so.

What discovery produces

Our client delivery framework asks its first stage, Discover, to produce four things, and this method feeds each of them:

• A current-state map. This is a structural model of standing relationships, a who-touches-what matrix of people and systems with the evidence and a confidence rating for each relationship, rather than a flowchart of one workflow. Process flows are drawn from it, so they stay consistent.
• A data-readiness assessment. For each system: does the data exist, can it be reached through an API, and is it usable as it stands.
• A risk register, covering technical, organisational and privacy risks.
• An outcome statement, which says what the system will change and for whom. Discover is complete when we and the client can both fill it in.

From discovery to design

We run Discover and Define in six moves: close the evidence, ask the commercial questions early, test the problem with the client, agree the boundary, shape and show the design, then cost and close. A gate, the point a stage cannot pass until a condition is met, is something the client said or signed, never a document we wrote. Design goes only as deep as the agreed boundary needs, and AI drafts and extracts but does not decide requirements or speak for the client.

Testing the problem means showing the client the current-state model, with its gaps, and making it easy for them to disagree. The output of that conversation is a correction in the client's own words. Evidence gathering closes at a stated point and reopens only when a conversation with the client disproves a hypothesis, not because more interesting material has arrived.