Understand the work
Process mapping template: draw the work before you automate it
A process map shows how a job gets from a request to a useful result. It records the steps, who carries them out and the decisions that send work down different paths. Start with one real job, including the awkward bits. The free map and worksheet below help you do that without buying another tool.
A useful map explains how the work actually happens, including the variations that change what someone does next.
Choose the map that answers your question
If you want to see what happens next, draw a flowchart. A box represents a task, an arrow shows where the work goes, and a diamond marks a decision. Put the question inside the diamond and label each outgoing arrow with the answer that takes you that way.
If work moves between people, use a swimlane map. Each row belongs to a person or team. Place their tasks in that row so a handover is visible when an arrow crosses into another row. The downloadable SVG provides that structure, with space for a decision and a return for missing information.
A value stream map asks a further question: how much time is spent working, waiting or doing something again? Use the value stream mapping tool when you need those measures. This guide starts with the route the work takes.
| Symbol | What to write in it |
|---|---|
| Start or finish | The event that begins the job, or the result that ends it. |
| Task box | A verb and a specific object, such as check the client agreement. |
| Decision diamond | A question with named routes, such as is the information complete? |
| Arrow | The next step, with a label when a decision changes the route. |
Why reporting is harder to map than it looks
Reporting is Said’s example of a job whose complexity only becomes clear when you examine its different versions. He has always wanted reports to give clients as much useful information as possible. That means the requirements change from one client to the next.
One neat line marked “build report” hides those differences. You have to work through the iterations to understand what can be shared and which requirements need their own route. The software needed to deliver those routes can be different too.
Said also points to a less glamorous problem: keeping people motivated to maintain that information. A beautiful map goes out of date if the team changes its reporting routine and nobody updates it. Give someone responsibility for the map, and make correcting it part of using it.
Follow a real job before describing the ideal one
Ask a person who does the work to walk you through a recent example. Open the records and tools they actually used. A written procedure can help, but the interesting detail is often the extra step someone has learnt to take because the procedure does not cover it.
Agree where the job starts and finishes. “A client asks for a monthly report” is a workable start. “The client receives a reviewed report with the agreed explanation” is a workable finish. “Reporting” on its own leaves too much room for everyone to mean a different thing.
- Write one action in each box, with the person responsible.
- Record the information or system that action needs.
- Add a decision where the next step changes.
- Show where missing information sends the job backwards.
- Mark a handover that needs acknowledgement before work continues.
Keep the first drawing rough. If two people disagree about a step, record the disagreement and look at an example. That is useful information about the process, rather than a reason to tidy the drawing until everyone stops arguing.
Keep the different client routes visible
Account manager
Confirm what this client needs
Check the agreed questions, reporting period and current requirements.
Reporting system and analyst
Gather the required figures
Use the sources for this version of the report. Flag a missing source rather than treating it as a zero.
Analyst
Choose the reporting route
A standard report follows the common route. A client-specific question needs its own analysis and explanation.
Person responsible for the account
Review the figures and interpretation
Check that the period, definitions and explanation match the client’s situation.
Account manager
Release and record the version
Send the reviewed report and keep the requirements used to build it.
This is an invented map. Missing figures return to collection; a changed client requirement returns to the first step.
A variation is worth showing when it changes the information, the decision, the person involved or the result. Different colours in a slide deck may be a presentation setting. A different definition of a sale changes the analysis and belongs on the map.
Once you can see the routes, look for a stable common part. You might share collection and checking while keeping the client’s questions and commentary separate. The map helps you discover that boundary; it does not require every client to receive the same report.
Use the worksheet with your team
Worked example
A monthly reporting map
Invented teaching example. No client outcome is claimed.
BOUNDARY
Request: prepare the agreed monthly client report.
Finish: a person reviews the figures and explanation before release.
COMMON STEPS
Check requirements, collect figures, validate the period, prepare a draft and review it.
DIFFERENT ROUTES
Client A needs performance against the agreed plan.
Client B needs an explanation for a change in one channel.
A missing data source returns the job to collection; it is not filled with an invented number.
OWNERSHIP
The account manager confirms changes in client requirements.
The analyst records a new analysis route before it becomes part of the next report.
Take the map back to someone who performs the job. Ask them to follow a normal example and an awkward one. If they have to invent an extra box while explaining it, add that box before using the map to scope a build.
Use the map to choose one useful change
You may find repeated typing, an unclear agreement or a long wait for approval. Each calls for a different response. Automating a task cannot repair a requirement that nobody has agreed.
Mark the change you want to test and the result you would expect. Keep the wider opportunity in view: the same agreed reporting definitions might later support client questions or another service. That later use still needs its own design and checks.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.