What a Friction Map is, and why you quantify it before automating anything
Before you connect a single API, you need to quantify the problem. Most automation projects fail, or drag on without control, for the same reason: nobody measured the process before touching it. The decision to automate gets made on intuition (“this eats up a lot of our time”), and intuition doesn’t help you prioritize, justify a budget, or know afterward whether the result was actually good.
A Friction Map fixes that. It’s a working document, not a decorative report: it records three variables for each process considered for automation, and from them calculates a single figure that can actually be compared, prioritized, and audited later.
The three variables
1. Estimated manual duration. How long it takes to run the process from start to finish, once. Not the ideal duration from a procedures manual, but the real duration, including interruptions, double-checks, and waiting. You get this by observing the process or asking the person who runs it every week, never the person who designed it three years ago.
2. Cost per hour of the person running it. This isn’t gross salary divided by hours worked; it’s the real cost the company bears for that hour (salary, social charges, the opportunity cost if that person could be doing something higher-value). If you don’t know it precisely, use a conservative figure: €20/hour is the default value in the website’s calculator, adjustable by role.
3. Weekly frequency. How many times the process repeats in a normal week, not the quietest week of the quarter. A process that happens 15 times a week weighs far more than one that happens once, even if the second one feels “more urgent” at a glance.
The calculation
With those three figures, the real annual cost of the inefficiency comes from a simple multiplication:
annualManualHours = hoursPerWeek × people × 52
annualManualCost = annualManualHours × costPerHour
A concrete example: an invoice-reconciliation process that takes two people 6 hours a week, at a real cost of €22/hour:
annualManualHours = 6 × 2 × 52 = 624 hours/year
annualManualCost = 624 × 22 = €13,728/year
That figure — €13,728/year — is what gets compared against a Build budget (€1,500–€5,000, depending on scope) to decide whether the project makes economic sense. Without this calculation, the decision to automate or not gets made with the same quality of information as deciding whether to replace the office sofa: by perception, not by data.
Common estimation mistakes
The most frequent one is measuring the “happy path” of the process and ignoring exceptions. If a process takes 10 minutes when everything goes well but generates 40 extra minutes of work once a week because of a recurring exception, that exception time is also friction, and it also needs to be counted — usually folded into the estimated manual duration as a weighted average.
The second mistake is underestimating how many people are actually involved. Many processes aren’t run by a single person: someone enters the data, someone else reviews it, a third person approves it. Every one of those people counts toward the people variable, even if their involvement is partial.
The third is failing to distinguish between the cost of the task and the cost of the interruption. A 5-minute task that breaks someone’s concentration six times a day doesn’t cost 5 minutes; it costs 5 minutes plus the time it takes to regain focus. If that interruption is systematic, it belongs in the estimated duration — it shouldn’t get waved away because “individually it’s not much.”
From measurement to decision
The Friction Map isn’t an academic exercise: it’s the deliverable of the Audit phase (free, see the Method section) and the first document of the project. It’s used to decide what to automate first (the processes with the highest annual cost, not the flashiest ones), which technical solution to apply (usually a bridge between systems via n8n), and what a realistic budget for the Build phase looks like.
Once the system is built, the same measurement logic doesn’t disappear — it becomes Zyntops Log, which automatically compares the real duration of the automated process against the estimated manual duration from this initial Friction Map. That way the savings figure isn’t a first-day promise; it’s a number that keeps getting verified every month.
Checklist before automating a process:
- Has the real duration been measured, including exceptions and interruptions?
- Have all the people involved been counted, even if their participation is partial?
- Does the hourly cost reflect the real cost to the company, not just gross salary?
- Is the weekly frequency calculated on a representative week, not the quietest one?
- Does the resulting annual cost justify the Build phase budget?
If the answer to that last question is no, the process isn’t ready to be automated yet — and that’s also a valid conclusion from a Friction Map.