408 messages in a week. Thirty-three were actual customers

One shared inbox was absorbing the whole company. Sorting it had quietly become somebody's job.

Operations and communication
Two weeks

A Dutch sun-shading installer

One public address received customer questions, supplier invoices, newsletters, job applications and bounces in a single stream. We measured a real week of it, built fifteen routing rules from one typed source, and measured the same week again.

408 to 33
messages a person must read
11 to 0
invoices filed into the wrong bin
1 per 14 days
measured false-positive rate

The challenge

Every small business has this inbox. It is the address on the van, on the website and on every invoice, and over years it becomes the place where everything arrives.

The cost is not the sorting itself. It is that genuine customer messages sit in a queue behind supplier invoices and marketing mail, and response time becomes a function of how busy the morning was.

The temptation is to write filters immediately, from intuition about what arrives. We did not do that, because intuition about mail volume is reliably wrong - and an unmeasured filter that archives a real customer enquiry is worse than no filter at all.

What we did

01

Measure before writing a single rule

A full week of real mail was inventoried read-only first, so the rules were designed against what actually arrives rather than what people remember arriving.

02

One typed source of truth

All fifteen routing rules are generated from a single typed definition rather than being clicked into a provider UI, so they can be reviewed, diffed and re-applied.

03

Dry run by default

The provisioning script does nothing unless explicitly told to apply. Every change was previewed against real messages before it touched a mailbox.

04

Measure the same week again

The before and after were computed over an identical set of messages, so the improvement is a comparison rather than an impression.

05

Report what a filter cannot fix

The inventory surfaced two structural problems no rule can solve, plus an access misconfiguration. These were reported separately rather than buried in the automation work.

How it works

Double-labelled messages: 4 to 0

Overlapping rules had been filing the same message into two places, which makes any downstream count wrong.

Misfiled invoices: 11 to 0

Supplier invoices were landing in an orders bin. Eleven in the sample week, none afterwards.

27 invoices recovered

The supplier-invoice bin had been empty because nothing routed to it. It now receives the mail it was created for.

One false positive per fortnight

The residual error rate was measured rather than asserted, so the team knows exactly how much to trust it.

Leads filed as newsletters

An entire lead source was being archived as marketing mail. Over four months that was dozens of genuine enquiries nobody saw.

A form that mostly was not the form

Of the messages matching one form's subject line in a month, under a third were actually that form. Any rule built on the subject alone would have been wrong two times in three.

A structural problem no filter fixes

Sales replies were going out from the shared address rather than the sales address, which no inbound rule can correct. Reported as a process finding.

An access review finding

The inventory surfaced misconfigurations in mailbox and calendar access, including one unauthenticated feed. Raised directly and separately from the routing work.

Technologies

TypeScript Node.js Google Workspace API Automation

The result

Across the measured week, 408 messages arrived. Of the genuinely inbound messages no rule touched, 33 remained in the inbox - and every one of those was a real customer conversation.

That is the number that matters. Not "we filtered 90% of mail", but "what is left is exactly the thing a person should be reading".

The secondary findings were arguably worth more than the automation. An entire lead source had been silently archived for months. Nobody knew, because nobody had counted.

No employee names, mailbox addresses, message contents or customer details are published here. Access findings are described in general terms only; specifics were reported privately and directly.

Related work

A Dutch sun-shading installer

Before the invoice button went live, we built the thing that stops it

The system was about to start emailing customers. Nothing prevented it from emailing all of them.

TypeScript PostgreSQL Prisma
A Dutch sun-shading installer

We read seven months of quotes and found we were building the wrong thing

The roadmap was built on what was easy to read. Not on what the business actually sells.

TypeScript Node.js PDF parsing