How to Set Up a Shared Inbox That Doesn't Drop Enquiries

Why shared inboxes drop things

The failure is not carelessness. It is a predictable consequence of how shared visibility works.

When five people can see a message, each of them has a reasonable belief that one of the other four is handling it. Nobody is being lazy; everyone is making the same sensible inference. The message that gets dropped is usually the awkward one that needs a bit of research, because it is the easiest to leave for whoever knows more.

Three specific patterns account for most of it:

Read but not answered. Someone opens it, decides it needs thought, and closes it. It is now marked read, so it is invisible to everyone else.

Answered but not finished. A holding reply goes out. The actual answer never follows, and the thread looks handled.

Handled by two people. Both reply, sometimes differently, which is worse than nobody replying.

The rules that fix it

1. Every message gets a name within a set window

   Two hours during working hours is a reasonable default. Assignment is not the same as answering: it just means one person now owns getting it finished.

   This single rule removes most drops, because the reasonable assumption that someone else has it stops being available.

   The most important rule

2. One person triages each day, on a rota

   Their job is assignment, not answering. Fifteen minutes twice a day is usually enough for a small team.

   A rota also means the load of triage is visible and shared, rather than quietly falling on whoever is most conscientious.

   Twice a day, 15 minutes

3. Agree what finished means

   Resolved and archived, or waiting on the customer with a follow-up date. Nothing sits in an ambiguous middle state.

   The waiting-on-customer state is where enquiries quietly die, so it needs a date attached or it is not a state, it is a bin.

   Two end states only

4. Use one holding reply, and honour it

   "We have this, you will hear from Priya by Thursday" is worth sending. An automatic reply promising a response time you do not meet is worse than silence.

   The promise is the part that matters, not the automation.

   Only promise what you meet

5. Never reply from a personal address

   Once a conversation moves to one person's inbox, it is invisible to everyone else and lost when they are away.

   This is the most common way a well-run shared inbox develops holes, and it usually happens with the most important customers.

   Keep it in the shared thread

6. Route the categories that need routing

   Sales enquiries, support, invoices, and recruitment need different people and different urgency. Sorting by hand every day is work you can remove.

   Route on arrival, but let a human reassign. Automatic routing that cannot be overridden creates its own dead ends.

   Route, but allow override

The one number to watch

Not volume, not response time averages. The age of the oldest unanswered message.

Averages hide exactly the failure you care about. An inbox answering 95% of messages in an hour and leaving three untouched for two weeks has an excellent average and a real problem, and the three are usually the difficult or valuable ones.

Check it daily, in one glance. If the oldest is older than your target, that is the work.

Two supporting numbers, checked monthly rather than daily: how many messages were reassigned (high reassignment means routing is wrong), and how many were answered by two people (means assignment is not happening early enough).

For sales enquiries specifically, speed carries more weight than almost anything else you could optimise. Research published in Harvard Business Review, auditing 2,241 companies, found the average response to a web lead was 42 hours and that 23% of companies never replied at all, while those responding within an hour were around seven times more likely to qualify the lead. An enquiry inbox with a two-day tail is losing deals before anyone has a chance to sell.

What to automate, and what not to

The line is the same one drawn in our guide to what to automate first: automate what people forget, not what they decide. Automatic replies to customers are the specific case worth avoiding beyond a simple acknowledgement, because the failure is public and uncorrectable.

Two further things worth having in place. A written note of who owns the inbox, what the targets are, and what happens when someone is away, following the rules in internal docs people actually read. And a plan for coverage when the usual triager is on leave, which is exactly the kind of single-route dependency covered in preparing the business for someone going on leave.

The test for whether any of this is working is not how it feels. Pick a week from two months ago, find five enquiries, and check what happened to each. If you cannot tell, the process is not producing a record, and a process without a record is one you are trusting rather than running.