Email Triage and
Approval Visibility

The problem

In a founder-led group, the inbox is where the real requests arrive: approvals to give, decisions to make, suppliers waiting on an answer, staff waiting on a sign-off. The work of reading each thread, deciding what it actually needs, and moving it to the right place falls on one person. That person becomes the router for the whole organisation.

The failure modes are familiar. An approval sits unread and a payment slips. A thread that only needed a two-line reply stays open for a week. Nobody can say with confidence what has actually been approved, because the record of it is scattered across threads in slightly different words. The operator carries the whole state in their head, and the state is never complete.

What was built

An intake layer that reads inbound mail and sorts it by what it needs, not by who sent it. Routine matters that fall inside a standing rule are handled as routine. Requests that genuinely need the operator are surfaced as such. Threads missing the information required to act are sent back to the sender for that information rather than pushed onto the operator to chase.

Above the intake sits an approval-visibility surface. Instead of a list of unread messages, it shows the state of requests: what is waiting on the operator, what has been approved and when, and who is waiting on whom. Replies are prepared as drafts, shown in full, and wait for the operator to send. The system reads and organises the inbox; it does not speak for the operator.

How it works

Four rules keep the layer trustworthy enough that the operator can act from it instead of re-reading the raw inbox.

Classify by what it needs

Each thread is sorted into what it asks of the reader: an approval, a decision, a piece of information to note, or a clarification the sender still has to supply. Sorting by need rather than by subject line is what separates the few threads that require the operator from the many that do not.

Route by who owns the missing piece

When a thread cannot be acted on because something is missing — an amount, a purpose, an attachment that never arrived — the system routes by who owns that missing reality. If the sender owns it, the clarification goes back to the sender as a drafted question. Only a decision that genuinely needs the operator's authority or judgment is surfaced to the operator. Uncertainty is not escalated by default.

Approval as a state, not a thread

An approval is recorded as a state with a subject, a requester, and a timestamp, so the answer to "what has been approved?" is a surface rather than an archaeology exercise across threads. A request that has been answered leaves the waiting list; one that is still open stays visible until it is closed.

Draft-first, always

Every reply is drafted and held. The operator reviews and sends. This is a fixed boundary, not a setting waiting to be relaxed: the system has no authority to send mail in the operator's name. It removes the drudgery of composing a reply without removing the judgment of whether to send it.

What changed

The operator stopped being the router. The morning pass over the inbox became approve, edit, or send, rather than read, sort, decide where each thread goes, and then act. Approvals stopped disappearing, because a request that needs an answer stays on a visible waiting list until it is closed rather than sinking below the fold.

The human equivalent is an executive assistant who has learned, over a long time, which mail matters and how the principal decides. That judgment takes many months to build in a person and leaves when the person does. The rules here are written down, applied consistently from the first day, and stay with the business.

Where this transfers

The pattern fits any leader whose inbox is the real approvals and decisions queue for the business — common in founder-led SMEs, where the owner is still the final sign-off on much of what happens. It does not depend on high mail volume; it depends on how much consequence flows through the inbox and how much of it currently lives only in the owner's head. What is fitted to each business is the classification map: which matters are routine under a standing rule, which need the owner, and what information a request must carry before it can be acted on.

Limitations

Classification is not perfect, so the operator still prunes what was sorted wrongly and corrects the rules over time. Evidence that arrives only as a photograph of a document cannot be read reliably; the system asks the sender for a typed summary rather than guess at the contents. And the send boundary is deliberate: the system never sends on its own, which means a genuinely urgent reply still waits for the operator to press send.