Simplify what's heavy: the sticky-note rule for cutting steps and handoffs

Simplifying an operational flow is reducing two things at once: the number of trivial human decisions the process requires, and the number of handoffs between people or systems that break the continuity of the work. The operating rule fits in one sentence: if the criterion fits on a sticky note, it doesn’t need a committee. A spending approval below a certain threshold with a recurring supplier doesn’t need an email to three people. A routine incident with a known response doesn’t need escalation. A month-end close that goes through two intermediate Excel sheets that only move data from one place to another doesn’t need those two sheets. Simplifying is different from eliminating — in step 1 you remove the step entirely; here the step stays but its friction is removed. And it’s different from automating — code doesn’t enter yet, only a written operating rule. After this step, the flow is clean enough for a deterministic system to execute it without case-by-case human supervision.

That’s step 3 of the Zero Friction Method: simplify. It comes after eliminating what shouldn’t be there and standardizing what’s left, and before automating. The order matters: simplifying what hasn’t been eliminated is wasted work, and automating what hasn’t been simplified is building a fast system doing things that shouldn’t weigh as much as they do.

The sticky-note rule

The most reliable signal for identifying a simplifiable step is the sticky-note test. If the criterion a human uses to decide fits on a three-line note — “purchases under €500 from suppliers with a 12-month history get approved automatically”, “incidents of type X get resolved with template response Y”, “invoices with less than 2% variance from the purchase order get reconciled without review” — then that step doesn’t need a human every time. It needs a written rule and the authority to apply it.

The sticky-note test isn’t just rhetorical. It’s operational. When you ask the person who executes the flow “write me in three lines how you decide this case” and they manage to do it, that’s the rule. When they can’t, that’s a signal the step requires real judgment and stays as a human decision. The difference between the two is what separates the simplifiable step from the one that isn’t.

The mistake that kills the conversation is asking the manager for the criterion instead of the executor. The manager describes the idealized criterion, which is almost never the real one. The executor describes the criterion they actually apply in practice, which is almost always simpler and more binary than the organization officially admits.

The two vectors: decisions and handoffs

Simplifying operates on two distinct dimensions that tend to get confused.

Trivial decisions that get escalated. The flow contains a decision that, by formal definition, requires approval from three people, but in practice 90% of the cases follow the same pattern. A recurring purchase. A known incident. A variance within tolerance. Each of those cases generates emails, waits, reminders, and the decision when it lands is the same as always. Simplifying here means writing the criterion for the 90% as a rule and reserving the committee for the remaining 10%.

Handoffs between people or systems. The flow goes from person A to person B to person C, or from system X to intermediate Excel Z to system Y, and at each handoff there’s a cost: somebody copies, somebody pastes, somebody validates that the data didn’t get corrupted in transit. Those handoffs are pure friction. They’re not steps that add value, they’re steps that exist because the real integration between the two endpoints was never built. Simplifying here means identifying where the data crosses an artificial border and either removing the border or accepting that the handoff exists and reserving it for cases where it actually contributes.

The two vectors are usually intertwined in the same flow. The spending approval that escalates to three people passes through two different systems, with an intermediate Excel where somebody retypes. Simplifying solves both: the binary criterion for 90% of the cases and the direct connection between the two systems.

How it’s done, concretely

The protocol is direct. You need the map of steps that survived the elimination exercise and the list of canonicals that came out of standardization. On top of that material, you do a pass with two questions per step:

Does the decision being made here fit on a sticky note? If the answer is yes, write the rule, validate it with the functional manager, and that step gets marked as automatic approval with a threshold. If the answer is no, the step stays as a real human decision.
Does this step exist because the data is crossing an artificial border? If the answer is yes, document the border and mark it as a candidate for direct integration in step 4. If the answer is no, the step adds value on its own and stays.

The deliverable from this session is a table with four columns: step, type (trivial decision / handoff / real value), written rule (when it applies), final decision-maker. It isn’t a consulting report. It’s three pages at most, plain language, one entry per step.

What matters about this table isn’t the table. It’s that when a director of operations signs it, what they’re signing is that the executor of the flow can apply the automatic-approval rules without asking permission case by case. That authorization is the real unlock. The technology comes later and is the easy part.

Three typical examples

Spending approval. A two-hundred-person company processes several thousand invoices a year. The formal flow requires approval from the department head for each invoice. In practice, 80% of the invoices are from suppliers with 12-month-plus history, amount below that supplier’s average, and recurring concepts. Simplifying here is: spend below €1,000 with a recurring supplier and recurring concept gets approved automatically; the manager reviews only the remaining 20%. The manager recovers hours a week. Approval stops being a bottleneck.

Routine incident management. A support team gets a hundred tickets a month. Half of them are of three or four known types with documented template responses. Today every ticket goes through human triage before being assigned. Simplifying means: tickets that match one of the known patterns get the template response and close without going through triage. The support team stops triaging the routine and concentrates on the tickets that actually require judgment.

Month-end close with intermediate Excels. The finance lead builds two Excel sheets each month to move data from the ERP to the reporting tool. Those two sheets don’t transform the data, they only move it. Simplifying is identifying that those two sheets are a pure handoff between two systems and marking them for direct integration. After step 4, those two sheets disappear and the data flows from the ERP to reporting without human intermediaries.

In all three examples, simplification isn’t code. It’s organizational decision plus written rule plus permission to apply it. The code in step 4 executes the rule, but the rule was already there.

The most frequent mistake: confusing simplifying with automating

The trap we see repeated is jumping straight to step 4 without going through this one. A company identifies that spending approvals are a bottleneck and buys a workflow tool to automate them. The tool gets configured with the current flow: three approvers, escalation at each level, email waits. Automation adds speed on top of the old flow. The friction is still there, just digital instead of paper.

The mistake is assuming the tool will solve the complexity of the flow. It doesn’t. What the tool does well is execute clear rules. If the rules aren’t clear beforehand, what you’re automating is chaos.

Simplifying before automating means that when the step-4 tool walks in, what it has to do is as simple as possible: apply a binary rule, connect two systems directly, execute a template response. The simpler the flow at the moment of automation, the cheaper and more maintainable the final system.

Permission, again

As in step 1, what’s missing to simplify is almost never technique. It’s permission. The sticky-note rule for spending approval has been written in the department head’s mind for years. What wasn’t there was the formal authorization for that rule to replace the three-signature process. And the template response for routine incidents lives in the support team’s knowledge. What wasn’t there was the decision to accept that the template response closes the ticket without further validation.

Those decisions are always made by a director, not by a tool. And they’re almost always available when you ask for them with the right documentation: three pages, four-column table, written criteria, final decision-maker. The director signs or doesn’t sign each rule. When they sign, it applies that same week without code. When they don’t sign, it stays as a human decision and you document the why.

When the flow is simplified, step 4 runs on clear rules and direct connections. And the AI of step 5, when it arrives, operates on the few cases that require real judgment, not on the 80% routine that was already solved at simplification.

How many decisions in your most expensive flow fit on a sticky note today and, even so, still go through a committee?

If your company wants to identify which flow decisions fit on a sticky note and which handoffs between systems are pure friction, the 2-week operations roadmap delivers the written-rules table and the prioritized list of direct integrations, signed off by the functional manager.