How to map a process before automating it
The fastest way to map a process is to follow one real case from start to finish, rather than asking people to describe how it works. Descriptions produce the official version. Following a case produces the actual one, including the workarounds nobody mentions.
Why interviews produce the wrong map
Asked to describe a process, people describe the intended version. The exceptions, the informal approvals and the parallel spreadsheet are omitted, partly from habit and partly because they feel like admissions.
A system built on that description then fails on contact with reality.
What following a real case reveals:
- Steps nobody mentions because they feel obvious
- Informal approvals that never appear in any document
- The parallel spreadsheet that holds the real data
- Where cases wait, and for whom
- Which steps exist only to compensate for an earlier one
Questions to ask at each step
| Question | What it reveals |
|---|---|
| What triggers this step? | Whether it is automatic or waits for a person |
| Who does it? | Role rather than name |
| What do they need to do it? | Inputs, often missing |
| How long does it usually wait? | Where the delay really is |
| What happens when it goes wrong? | The exception path |
| Where is the data kept? | Usually more places than expected |
Step by step to map it
- Pick a recent real case, not a hypothetical one.
- Follow it end to end, talking to each person who touched it.
- Record waiting time separately from working time.
- Ask about the last exception, which is where the real process shows.
- Note every place data is stored, including personal files.
- Show the map to the people involved, who will correct it immediately.
- Mark which steps exist only to fix an earlier problem.
Why waiting time is the number that matters
Mapping usually focuses on what people do. In most processes, the time is spent waiting rather than working, often at a single stage. Recording waiting separately shows that automating the work would change almost nothing, and that the constraint is elsewhere.
Why choose Jestor
In Jestor, once mapped, the process can be built directly without a separate implementation phase, with SLA per stage confirming whether the waiting times you observed hold at volume. Building without code means the map and the system can be refined together.
Frequently Asked Questions
Why not just interview people about the process?
Because they describe the intended version rather than the actual one. See jestor.com.
What is the most revealing question?
Asking about the last exception, since that is where the real process shows.
What should be measured during mapping?
Waiting time separately from working time.
Video Tutorial: Step by Step
With Jestor, you can automate workflows, connect teams, and build internal systems your way, all without code and powered by AI. Discover Jestor at jestor.com and see how to take your company's operations to a new level of efficiency and control.