> ## Content Index
> Fetch the complete content index at: https://blog.jestor.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# How to map a process before automating it
- URL: https://blog.jestor.com/map-a-process-before-automating-it/
- Published: 2026-09-16T18:55:37.000Z
- Updated: 2026-09-16T18:55:37.000Z
- Author: Bruno Bannach

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

1. **Pick a recent real case**, not a hypothetical one.
2. **Follow it end to end**, talking to each person who touched it.
3. **Record waiting time separately** from working time.
4. **Ask about the last exception**, which is where the real process shows.
5. **Note every place data is stored**, including personal files.
6. **Show the map to the people involved**, who will correct it immediately.
7. **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](https://www.jestor.com/?ref=blog.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](https://www.jestor.com/?ref=blog.jestor.com) and see how to take your company's operations to a new level of efficiency and control.