Operated function · the front door
Six people can see it, which means no individual is failing when a message sits for two days. The ones that get answered are the ones somebody felt confident answering; the ones that needed three departments are the ones still there on Friday.
Everything arrives in the same place: a customer with a billing question, a supplier chasing a payment, an applicant, a complaint that will become a formal one if it is ignored, a genuine sales enquiry, and a large volume of things that are none of those. They are unsorted, and sorting them is the job nobody was given.
People self-select what they answer. That is not laziness — it is the only rational behaviour when everything is visible and nothing is assigned. The result is that the easy, familiar, in-my-area messages clear quickly and the awkward, cross-functional, possibly-serious ones accumulate, which is the exact inverse of the order that would serve the business.
The same person writes to three channels because the first two got no reply, and now three colleagues are drafting three answers to the same problem, or worse, two send and contradict each other. Nobody finds out unless the customer points it out.
Handoffs are performed by forwarding. Once a message is forwarded, it leaves the queue and its clock stops — so a request that has been alive for nine days across four people looks, at every individual step, like it was handled promptly.
And the serious ones are indistinguishable on arrival. A complaint that carries a regulatory clock and a routine grumble look the same in a subject line, and the difference is only discovered when somebody reads carefully, which happens when somebody has time.
When every arrival is visible to everyone and assigned to no one, the items that get worked are the ones somebody felt able to answer — so difficulty, not importance, determines what waits.
Adding people to a shared inbox makes this worse rather than better, because it further dilutes the sense that any individual is accountable for a specific item. The fix is not capacity, it is assignment.
Assignment requires classification, and classification is the part that is genuinely hard for a person to do quickly: reading enough of a message to know whether it is a billing question, a complaint with a clock, a supplier matter or a sales enquiry, and doing that for everything, including the ones that look boring. That is bounded, repetitive work and it is the part worth delegating.
What follows from classification is mostly mechanical: an owner, a class, an age, and a threshold at which age becomes visible to somebody who can do something about it. Once an item has those four things, the awkward cross-functional message stops being invisible, because it is aging in somebody’s name.
And the clock has to survive a handoff. A request that moves between three people is one request, and measuring it as three prompt steps is how an operation reports good service while a customer waits nine days.
Arrivals that have an owner — measured by items assigned to a named person within your threshold, against a baseline where ownership was implicit and therefore absent.
The age of the oldest unresolved item — measured by oldest-item age and the tail of the age distribution, which is where the cross-functional requests live.
Elapsed time that survives handoffs — measured by end-to-end age per request rather than per step, which is frequently several times the per-step figure.
Duplicate and contradictory replies — measured by threads receiving more than one independent response, before and after joining.
Whether serious items are identified on arrival — measured by complaints and clock-bearing items classified within your threshold, versus discovered on a later read.
What the front door actually receives — measured by volume by class — a breakdown most shared inboxes cannot produce, and which usually redirects work upstream.
any judgement on a complaint, a legal matter, a safety issue or a regulatory question. Those are classified and routed, never answered here. Nothing here decides an outcome for a customer, and a triage operation that started doing so would be making decisions without the authority or the context to make them.
Channels stay where they are — the inbox stays an inbox, the number stays your number — and the queue is the layer above them. Nothing migrates, and no customer is asked to use a different address.
Identity matching uses the contact records you already hold, which is what turns one person writing on three channels into one thread. Where identity genuinely cannot be resolved, the items stay separate and are marked as possibly related rather than merged on a guess — a wrong merge shows one customer another customer’s correspondence.
Replies go from the address the person wrote to, so a customer receives an answer from the channel they chose.
A front door receives things nobody intended to send there: personal information, a whistleblowing disclosure, a legal notice, a customer’s payment details typed into a message despite every instruction not to. The operation has to be scoped for that, because it will happen.
So classes exist for it. Anything identified as legal, regulatory, safety-related or a disclosure is routed immediately without being answered and without being summarised into a general queue. Where a message contains data it should not, that is flagged for handling under your policy rather than propagated.
Every item carries a receipt naming when it arrived, how it was classified, who owned it, and every handoff — which is what answers "nobody replied to me" and what a regulator asks for on a complaint.
Operational access is not permission to train. Correspondence arriving at your front door does not become material improving anything serving another organisation.
The class list is the artefact to review, and legal should own the definitions of the ones that route rather than answer. A front door that answers a complaint before it is recognised as one has created the problem the complaints process exists to prevent.
Privacy will ask what happens when something arrives that should not have. The answer is a handling class rather than a promise of care, and it is written before anything is connected.
Where an obligation attaches through a jurisdiction or a sector — complaint-handling clocks, disclosure protections, record retention — it is marked applicability-gated rather than presented as standing.
A single front-door channel over one week — read-only, nothing answered and nothing routed — classified against your own class list, with end-to-end age measured on each item.
The observation week produces the two things a shared inbox cannot show you: what actually arrives, by class, and how old the oldest items really are once handoffs are counted as one request rather than several prompt steps.
Both usually surprise. A large share of most front doors turns out to be one or two classes that should not be arriving there at all, and the fix for those is upstream — a form, a phone menu, a page — rather than any triage operation.
If you continue, the first delegation is classification and routing only, with nothing answered. Answering comes later, one class at a time, starting with a class where the answer is genuinely known and never with one that carries a clock.
Ticketing works well for the channel that feeds it and usually covers one class. The failure this addresses is the arrivals that never became tickets — the address anybody can write to, the number that goes to voicemail, the form that emails a distribution list. If everything already becomes a ticket with a named owner and an age that survives handoffs, this is a duplicate. The observation week settles it by measuring what arrives outside the ticketing system.
Then it should not, and the first delegation is classification and routing with nothing answered at all. That alone addresses the constraint, which is ownership rather than reply capacity. Answering is a separate decision, taken later, one class at a time, and never for a class that carries a legal or regulatory clock.
If that is true the observation week will show it, and it will show which noise, which is the actionable part — most high-noise front doors are receiving one or two classes that a form change or a phone menu would divert entirely. That is a fix you make once, upstream, and it is worth more than any triage. The risk of the current state is that genuine items are hidden inside the noise and their age is invisible.
That is a scoping decision and it can be honoured, but it needs to be precise, because a front door does not sort itself before arriving. Options are a channel excluded entirely, or classification performed with routing-only visibility and defined classes escalated unread. What cannot be promised is that a shared public address will not receive something sensitive — it will, and the operation is designed around that rather than around the hope that it will not.