Process

A recipe sits between chopping the onion and serving dinner: it is the path between the two, written in a way you can follow again next week. That is a process. Except in a company, the recipe is almost always in three people’s heads and nowhere on paper.

Both examples below are processes. The most common mistake is thinking only the second one counts.

Issue an invoice. Trigger: the service was delivered. The path: open the city government system, enter the customer’s information, issue it, download the PDF, send it by email. Outcome: the customer received the invoice. It takes ten minutes and happens forty times a month.

From order to delivery. Trigger: the customer approved the proposal. The path: open the work order, schedule the team, execute, issue the invoice, collect payment, check that everything turned out well. Outcome: service delivered and paid for. It crosses three areas and takes two weeks.

The small one is usually the easiest to improve, and it is the one no one mentions when you ask, "what are the processes here?"

Calling something a process when it has no trigger, path, and end. Four mix-ups show up in every interview:

• A department. "Finance" is not a process. "Closing the cash register" is.
• A system. "Omie" is not a process. "Entering the invoice in Omie" is.
• A problem. "Lack of organization" is not a process. "Counting inventory" is.
• A one-off event. Moving headquarters is not a process. Does it repeat? Then it is.

The test is short: can you say what makes this start and what makes this end? If not, you are looking at an area, a tool, or a complaint.

• Map the process with the people who do the work, not the people who describe it. The person who executes remembers the exception; the person who describes it remembers the manual.
• Ask about the month, and leave the org chart aside: "from day 1 to day 30, what repeats?". Monday morning, what is waiting for each person? At the end of the month, what changes?
• Also count what the person approves, what they are only notified about, and what gets in their way when things go wrong, even if it belongs to another area. That is where the company gets stuck, and no one sees it because everyone looks only at their own piece.
• A process that comes out of two people’s mouths with different names is a single process. Unify it before slicing, or you will draw the same work twice.
• Only after the process is legible do you ask what part of it becomes a task. Slicing something no one has written down is guessing.

One line per process, with four columns: trigger, who it passes through, outcome, and how many times per month. The last column is what orders the queue: high volume with a short path is where the first agent usually fits.

Process is the middle step in the chain that supports the rest of the dictionary: outcome (what the company wants) → process (how to get there) → task (the unit that gets delegated) → goal (the verifiable instruction inside it).

Skipping that step is the most common way to start wrong. Whoever automates an outcome builds a promise; whoever automates a task without knowing which process it came from builds a piece that fits nowhere.