The company grew from 20 to 50 people. Three moments when e-mail approvals stopped working

E-mail approvals do not stop working in a single day. They stop working three times, differently each time, and each time the company finds a stopgap answer. Only the third answer costs enough for somebody to start looking for a system. What follows is the same company and the same purchase order, seen at twenty, thirty and fifty people.

Twenty people: e-mail, and the room next to you

The order needs the manager's approval and a check by accounting. An employee sends a message with the quote, the manager replies with one word, the accountant is copied in. It works perfectly, just not because of the e-mail. E-mail carries the attachment. The order of steps, the deadlines and the knowledge of who is in today all come from everyone sitting within sight of each other.

At this size you need no system, and nobody will honestly sell you one. That is worth remembering, because later it is easy to assume the company has always worked this way and to miss the fact that the condition for it working has quietly disappeared.

Thirty people: the spreadsheet appears

At thirty people there is a second floor and the first manager who does not sit with the team. Status is the first thing to go. Nobody knows whether the order is waiting for the manager or already for accounting, because an e-mail thread has no stage, only replies stacked one under another.

The company does not change the flow at this point. It hires one person's memory to run it. Somebody starts keeping a “what is where” spreadsheet and phoning round the overdue items every day. The spreadsheet is a second copy of the truth, accurate for exactly as long as that person is at work and remembers everything.

Fifty people: the spreadsheet stops being enough too

At fifty people, with remote work and several managers, a number of things give way at once. A new employee does not know the unwritten path, so they write to whoever seems right. The word “ok” in the third message of a thread cannot, a year later, be tied to any particular version of the quote. A message sent to somebody on holiday waits in their inbox while the sender is convinced the matter is moving.

The spreadsheet will not catch this, because it records only what somebody reports to it. Your company now has two flows: the real one in the inboxes and the declared one in the spreadsheet. Neither is complete.

What Opero makes of this chronology

In Opero the order stops being a thread and becomes a record of a custom object: it has its own fields, numbering and file card. You describe the flow once, as a process made of stages and transitions, and attach it to that object.

• A stage instead of guesswork. The record sits at a named stage, for example “Manager approval” or “Accounting check”. The answer to a question about status is in the record, not in somebody's memory.

• The addressee is a function. A stage points at a role, so the task goes to a position rather than to a single surname. One person's holiday then does not hold up the order.

• A transition with a condition. A record leaves a stage only through an available transition, and a transition can require a condition to be met, such as an attached quote. When it is not met, the user sees the reason straight away.

• A form at the stage. The requester sees a different set of fields from the approver, because you configure the form separately for creating, viewing and editing. Permissions reach down to a single field, so a threshold amount need not be visible to everyone.

• A reminder with nobody reminding. The rules engine works on the principle of “when a condition occurs, carry out an action”, so an order sitting at a stage longer than an agreed time sends a notification to the person responsible and to the manager by itself. That is precisely the work somebody with a spreadsheet was doing at thirty people.

• History instead of archaeology. Every run is recorded and can be replayed step by step: who executed the transition, when, and on what data.

A report replaces the “what is where” spreadsheet. A summary with drill-down shows how many orders sit at which stage and for how long, and clicking a figure leads to the individual records. The manager does not have to ask how many cases are waiting. They open a dashboard where the number is already calculated.

One thing does not arrive with the system. If the company has never decided who approves orders above a certain amount, configuration will not settle it. What it will do is show the gap plainly: a stage with neither a role nor a person assigned appears on the list as a task with no owner. That is an uncomfortable piece of information and usually the most valuable one.

The conclusion from this chronology is an awkward one. E-mail approvals did not break at fifty people, because they never existed. At twenty people the shared room did their work, at thirty one person's memory did it, and at fifty nobody does it at all. The right moment for a process does not arrive when e-mail starts to hurt. It arrives when the reason e-mail worked in the first place disappears.