Processes
Mapping
Event Storming
Analysis

How to describe a process before automation — a step-by-step method

Before you start automating, you need to know what — and that's harder than you think.

Mateusz KozłowskiMateusz Kozłowski12 min read
How to describe a process before automation

Why automations without a process description almost always end badly

A scenario that repeats in every other company: the owner comes in with enthusiasm — wants to automate customer onboarding, order handling or invoice processing. We have the tool, we have the budget, let's start.

Three weeks later it turns out the automation works for 70% of cases. The remaining 30% are exceptions that “have always been there”, there was just never time to describe them. Klaudia in the office does it differently than Tomek. Customers from Germany have a different invoice path than Polish ones. On Mondays there's one flow, on Fridays — another.

The automation doesn't handle exceptions no one described. Instead of saving time, you now have to handle automation errors manually — which takes more time than before.

Why talking only to the owner isn't enough

The owner knows the business better than anyone. But with the volume of daily duties, they lose touch with the details of processes carried out by others. Not because they don't want to — it's simply impossible to be everywhere.

The process changed informally — without documentation, without updating procedures. Because a new person joined. Because the supplier changed. Because the system required a workaround. Such changes happen in every company — and that's exactly why, before you start automating, you have to uncover them.

The process description method — 5 steps

1. Pick one specific process

Don't try to describe the whole company at once. Pick one specific process — preferably one that:

  • You do regularly (daily, weekly, monthly)
  • Takes a disproportionate amount of your time
  • Contains repetitive steps that feel like pulling teeth
  • When something goes wrong, it hurts — financially or reputation-wise

2. Define the process boundaries (start and end)

Every process has an entry and exit point. Without those, the conversation quickly drifts and suddenly you're describing half the company.

Bad

“Customer service” — too broad

Good

From the moment a complaint email arrives to sending the refund confirmation.

3. Gather perspectives from all participants

Talk to every person who has contact with the process — not just the owner. Control questions:

  • What's your first step when this process begins?
  • What information do you need to start?
  • What happens when something goes wrong? (key!)
  • Do you do it differently depending on the situation?
  • What irritates you most about this process?

4. Draw a step-by-step process map

You don't need special software. Post-it notes on a wall or a simple diagram in draw.io / Miro will do. Rules:

  • Write down every step — even those that seem obvious
  • Mark decision points: if X then Y; if not X then Z
  • For each step note: who, in which tool, with what data
  • Don't skip points of disagreement between participants — mark them as a hot-spot

5. Identify edge cases

This is the step most often skipped — and the reason automations work for 70% rather than 100% of cases.

  • What happens when the customer doesn't reply to the message?
  • What if the data is incomplete or wrong?
  • What if the process involves a customer from another country?
  • What when the system is unavailable?
  • What is the exception to the rule that happens occasionally?

Ready-made process description template

Copy the template below and fill it in before talking to an automation expert or before implementing on your own. The more detail, the fewer surprises.

## OPIS PROCESU
Nazwa procesu: ___________________________
Częstotliwość: codziennie / cotygodniowo / comiesięcznie
Szacowany czas na jedno wykonanie: ___ min/godz.
Liczba wykonań miesięcznie: ___

## GRANICE PROCESU
Zaczyna się gdy: ___________________________
Kończy się gdy: ___________________________
Kto jest zaangażowany: ___________________________

## KROKI (każdy krok osobno)
Krok 1: [opis] | Kto: | Narzędzie: | Dane wejściowe:
Krok 2: [opis] | Kto: | Narzędzie: | Dane wejściowe:
Krok 3: ...

## WYJĄTKI I EDGE CASES
Gdy X się nie zgadza → ___________________________
Gdy brakuje danych → ___________________________
Gdy klient jest z zagranicy → ___________________________

## NAJWIĘKSZY BÓL W TYM PROCESIE
Co najbardziej irytuje: ___________________________
Co najczęściej idzie nie tak: ___________________________
Gdyby to można zmienić, co by pomogło: ___________________________

Event storming — when the process is too complex for a sticky note

For simple, single-stage processes a list of steps is enough. But when several people, several systems and many conditions are involved — reach for event storming. It's a workshop in which the team jointly maps the process by sticking colored notes on the wall. Each color has a meaning:

Orange

Events — what happens

Example: Invoice arrived in email

Blue

Commands — what someone does

Example: Save the invoice to Dropbox

Yellow

Actors — who does it

Example: Bookkeeper, Make.com system

Red

Hot-spots — a problem, ambiguity

Example: Who decides on amounts above PLN 5,000?

When it's worth sticking with paper — and why that isn't a weakness

Amid all the enthusiasm for automation, it's worth remembering: not everything needs an IT system. The brain handles some tasks perfectly well with analog tools.

  • Planning the week — a notebook or paper calendar provides focus that a screen cannot replace
  • Sketching concepts — a sketch on a piece of paper often speeds up thinking more than a digital diagram
  • Notes just for yourself — written by hand they stick in memory better (studies confirm this)
  • Quick TODO lists for the day — a sticker on your monitor beats most apps

Automation makes sense where data has to flow between systems, where people make mistakes from boredom or fatigue, and where time spent on repetitive tasks is too valuable. But not every tool has to be digital.

When to describe it yourself, and when with an expert?

Do it yourself when:

  • The process is done by one person (you)
  • You know it inside out and there are no exceptions
  • You want to build a simple automation in Zapier / Make.com
  • You have time to experiment

Invite an expert when:

  • The process involves several people with different perspectives
  • An error costs — financially or reputation-wise
  • You want to build a dedicated system for the team
  • You have the feeling that everyone does it their own way

Mateusz Kozłowski

Mateusz Kozłowski

Założyciel flowbiz · Ekspert automatyzacji procesów

Wdrażam automatyzacje, integracje i AI w średnich firmach na Pomorzu i w Kujawsko-Pomorskiem.

Więcej o autorze