Take one recently finished job and trace it with the person who did it. Start at the request. Stop where someone accepted the result.
Write down what each person needed, what they did and what they passed on. Include the waits and the drafts that came back. You are looking for the point where a change would help the people doing the job.
For example, a project-start pack might wait because the signed proposal and a later email describe different work. Faster drafting leaves that scope question unanswered. Someone needs to settle it with the client first.
If you are still choosing a job to examine, use the first-workflow guide. This exercise starts once you have one in mind.
Pick one recent example and set its boundary
Choose a job that finished recently, so people still remember it. An ordinary one tells you more than the worst week of the year. Use an example you have permission to discuss. A description with names and sensitive details removed may be enough.
Decide where the job starts and what counts as finished. ‘Client onboarding’ leaves the start and finish unclear. ‘From signature to the first approved project brief’ gives the team two points it can trace.
Sit with the person who did the work and, if you can, whoever checked it. ASQ recommends defining the boundaries and checking the map with the people involved. Use their walkthrough to catch steps that happen outside the main system. A manager's account of how the job should run is worth noting, but map what happened this time.
Trace what actually happened
Write each step as something a person did: found, checked, asked, rewrote, waited, sent. Include the work around the main system, such as an inbox search, a phone call, a spreadsheet kept on someone's laptop or asking the one colleague who remembers. ‘Ask Jo’ is a step if the job can't continue without it.
For each step, record who did it, what they started with and what they produced that the next step needed. Keep the wording plain. You're describing the work for a colleague, not drawing a process standard.
As you go, tag each entry with where it came from:
- Seen: you can point to it in the example you are tracing.
- Told: someone reported it. Note who. It may well be right, but you haven't seen it in this example.
- To check: nobody is sure yet.
Keep the tags beside the entry. When a colleague asks where it came from, the answer should be on the map.
Separate doing from waiting
A job that feels slow is often a job that waits. The effort at each step may be reasonable while the work sits in an inbox, a review queue or a request for missing files.
Record waiting on its own line. If you have no timings, describe what happened: ‘waited for the client's brand files until a reminder went out’ is honest and useful. Keep the wait separate from your explanation of why it happened, and don't turn a feeling into hours you haven't measured.
A faster draft can leave the review queue untouched. Record both parts before estimating the effect on turnaround. If much of the delay sits in a queue, the first change may concern when and how that decision gets made.
Mark the returns and the decisions
Find the places where work went backwards: a draft returned, a question sent back, a step done twice. Note why. Missing input, two sources that disagree and a reviewer changing direction each call for a different response.
Then mark the decisions. Which judgements did a person make, and which should stay with a person? Write the role next to each one. These become the edge of any help you add later. A system might prepare, sort or flag, but each decision stays where the map says it lives.
Try a simpler change alongside AI
For each sticking point, ask what the plainest fix would be. A clearer intake form, one agreed place for the current version, a checklist, a review slot in the diary or a feature you already pay for might solve it. Where someone assembles and interprets material from several places, AI-assisted preparation with a person checking the result could help.
Write both options down. They aren't rivals. A better intake often makes any later AI step more reliable. If the useful change is better everyday use of tools your team already has, ChatGPT + Claude Implementation may be the relevant route. A map doesn't prove you need a custom system; the guide to ChatGPT, Claude or a custom AI build covers that decision.
Finish with one next check
Look at your ‘to check’ entries and choose the one that would most change what you do next. Name who will look into it and what they will do. Keep it small. A coordinator might look at recent project starts and note where each requirement came from. Agree how many permitted cases the coordinator will check and when the team will look at the findings.
When the check comes back, you can improve the current method, test one assisted step or leave the job as it is. Any of those is a good outcome if the evidence supports it. The AI transformation roadmap helps you decide what comes after this change, and the measurement guide helps you tell whether it worked.
A blank one-job map
Blank one-job map. Copy it into a document or spreadsheet. Use one row per step, in the order the work happened, and tag each entry Seen, Told or To check. A blank cell is fine. A guess written as a fact isn't.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Step | Person | What they started with | What they produced for the next step | Waiting or return | Decision kept by a person | Still to check |
|---|---|---|---|---|---|---|
| 1 | ||||||
| 2 | ||||||
| 3 | ||||||
| 4 | ||||||
| 5 |
Below the map, add three lines:
- What we hope this job could make possible:
- Simpler change worth trying:
- Next check, who does it and when the team reviews it:
A fictional example: a design studio's project start
Fictional teaching example. The studio and its work are invented; the timings and business effects have not been measured.
A small design studio wants its designers to begin each new project with what they need and to keep their first days for design. At the moment, project starts feel scrappy. The studio coordinator suspects the project-start pack, the document that gathers the confirmed scope, deliverables, dates and client files before the team begins.
She traces the most recent project with the project lead, from the signed proposal to the kickoff.
Completed fictional map: one project start.
If columns don't fit, scroll sideways. Keyboard: focus the table and use the arrow keys.
| Step | Person | What they started with | What they produced for the next step | Waiting or return | Decision kept by a person | Still to check |
|---|---|---|---|---|---|---|
| 1. Confirm the job | Studio director | Signed proposal | Project added to the job list | None recorded (Seen) | Director accepts the project | |
| 2. Find current requirements | Coordinator | Proposal, client email thread, shared drive | List of deliverables, dates and files | Waited for the client's brand files; a reminder went out (Seen in the email thread) | How long the wait lasted and why the files were late (To check) | |
| 3. Prepare the pack | Coordinator | Requirements list, studio template | Draft project-start pack | Returned: the proposal lists three concepts, a later client email asks for five and an earlier date (Seen) | Whether proposals and later emails often disagree (To check) | |
| 3a. Settle the scope | Account lead | Proposal and the later email | Agreed scope recorded in the project file | Pack paused until the scope was settled (Seen) | Confirms agreed scope with the client and records the decision | |
| 4. Review the pack | Project lead | Draft pack | Approved pack | Review queued behind client deadlines (Told by the project lead) | Project lead decides the pack is ready | How long packs wait for review (To check) |
| 5. Hand over to the team | Project lead | Approved pack | Kickoff and first tasks | Follow-up questions in chat during the first days (Told by the designers) | Designers plan their first concepts | Who checks what designers still need? (To check) |
- What we hope this job could make possible: designers begin with what they need and keep their first days for design. Not measured.
- Simpler change worth trying: one agreed scope note per project, updated by the account lead whenever the client confirms a change.
- Next check, who does it and when the team reviews it: the coordinator looks at recent project starts the studio has permission to review. She notes where each requirement came from, whether the sources disagreed and whether files arrived late. The studio agrees how many cases she will check and when the team will look at the findings.
Pause for confirmation. The proposal and later email disagree. The account lead confirms the agreed scope with the client and records the decision before the coordinator prepares the pack again.
Read the map and its open questions
The director confirms the job. The coordinator finds current requirements and prepares the pack. The project lead reviews it and hands over the approved work. If the sources disagree, the account lead confirms scope with the client, records the decision and returns it for preparation. The file wait was seen in this fictional case; the project lead reported the review queue, and designers reported follow-up questions in their first days. Drafting effort and waiting durations remain unknown. Check how often files arrive late, how often sources conflict and what the designers still need after handover. Uninterrupted design time is a hope to measure, not a demonstrated result.
One project start, traced. Fictional example. Lines show the sequence, and the dashed return shows a hold for a human decision.
The studio began by asking how to write the pack faster. Its map points to a file wait, a scope disagreement and a reported review queue. The coordinator still needs to check the time spent drafting and waiting. One agreed scope note is a change the team can try now.
The account lead confirms any change with the client. An assisted draft would need to flag the disagreement and wait for that decision. The studio can then find out whether the revised process gives designers a clearer start.
Bring the map to a conversation
Build n Bloom's AI Transformation service helps businesses investigate changes like this and build the agreed capability with the people who will run it. If you'd like to talk it through, book a free 25-minute Fit Call. Start from a piece of work and what you'd like your team to be able to do. The map is optional, and no confidential files are needed. You keep a short reviewed provisional Fit Note, with its timing agreed during the call.
Run a specialist advisory firm? See how we work with advisory firms.