How to run a shared inbox without losing track of customers

A shared inbox lets several people see the same message. It still needs a way to show who is handling it, what happens next and when somebody should check again.

Without those three details, “I thought you were handling it” becomes a perfectly plausible explanation.

You can give a small team that visibility with its current mailbox and a shared list. Start by agreeing on ownership and a few usable statuses. Buy more software when you can name the work your existing setup cannot do reliably.

Give every open conversation a named owner

The owner is responsible for moving the conversation forward. They do not have to do every task personally. If they need a delivery estimate from the warehouse, they still own getting that estimate back to the customer.

Avoid assigning work to “sales,” “the office” or everyone copied into a thread. Those are destinations. A person needs to accept the next step.

Choose a simple claiming rule: the first available person taking responsibility records their name before replying. Agree on a backup for absence and a person who checks unassigned messages during the team's normal coverage hours.

Do this in the inbox if it supports assignment. Google Groups' Collaborative Inbox assignment tools let permitted members take or assign a conversation and mark it complete. If you already have that setup, use its assignment field rather than maintaining the same ownership information in two places.

Otherwise, a shared register can carry the missing details. Keep a link or stable reference back to the conversation; the register should not become a second, partial inbox.

Use statuses that tell the next person what to do

Try four statuses to begin with:

Unread is a display state, not an ownership decision. Opening a message on your phone should not make it disappear from the team's work.

“Waiting” needs particular care. “Waiting for customer” is useful only when the team can see what was requested and when the owner will look again. Choose dates that fit the promise you made and the urgency of the work; there is no sensible universal deadline for every inbox.

Keep promotional mail and messages requiring no action out of this register. Logging every newsletter gives you more administration without improving customer service.

Set the order of work before the inbox gets busy

Triage is the short check that decides where a message belongs and how soon somebody needs to act. The person covering triage does not have to answer every question. They do need to spot an approaching customer promise, assign the work and expose anything the team cannot cover.

Use a few questions in sequence:

1. Does this message belong to an existing request? Add it to that work and alert its owner. A new subject line does not necessarily mean a new job.
2. Does it need action? Close obvious duplicates and no-action mail with a reason. Preserve the original conversation where it remains relevant.
3. Is there an immediate consequence or a promise due? Put a delivery change before today's dispatch ahead of an ordinary pricing enquiry. Use the business consequence, rather than the sender's use of “URGENT,” to explain the priority.
4. Who can move it forward? Assign one owner with the relevant access and authority. If nobody is available, the triage person escalates the gap.

Acknowledging receipt is useful when the real answer will take time. Make it specific: “We have the photographs. Arun is checking whether Friday collection is possible and will confirm the options by Thursday afternoon.” That is a proposed response for the fictional example, not a promise every business should adopt.

Avoid “someone will get back to you soon” if the team cannot tell what soon means. Equally, do not promise a fast resolution when the next step depends on a customer, technician or supplier. Promise the next update you can control.

A status needs a route back into active work

Every Waiting conversation needs a return condition. A customer's reply, an internal answer or the check-again date should bring it back to the owner's attention. In a manual setup, that means explicitly reviewing incoming replies and today's due checks. In an inbox product, it becomes something to demonstrate during evaluation.

If the customer never sends the photographs, choose an appropriate follow-up and closure rule for this kind of enquiry. Record the outcome as “Closed: photographs not received after follow-up,” rather than “Resolved: repair booked.” If the customer returns later, reopen the original request or link the new one to it. The history should explain what actually happened.

Walk one conversation through the system

Here is a fictional example from a small furniture-repair business.

A customer emails about a damaged table and asks whether it can be collected on Friday. Leila opens the message, records herself as owner and asks for two photographs. She sets the status to Waiting, with “Customer to send damage photographs” as the dependency and Thursday morning as the next check.

The photographs arrive later that day. Leila needs a technician's assessment before promising a collection. She changes the next action to “Ask Ben to confirm repair suitability and Friday collection capacity.” The customer has not yet been promised Friday.

Before leaving for a day off, Leila hands the conversation to Arun. The register reads:

Owner: Arun, accepted Wednesday afternoon.
Status: Waiting.
Needed: Ben's repair assessment and collection availability.
Next check: Thursday, 10 a.m.
Customer promise: We will confirm the options by Thursday afternoon.
Source: The original enquiry and photographs in the shared conversation.

Arun can continue without asking Leila to reconstruct the story. Once the customer accepts an offered slot and the booking is recorded, he closes the conversation with that outcome.

Notice the difference between completing a reply and completing the request. “Email sent” may be an intermediate step. The agreed booking is the finish line in this example.

If Leila needs both a repair assessment and a price, keep those as two internal tasks under the same customer request. Ben can own the assessment without becoming responsible for the whole customer conversation. Arun still has to assemble the answer. Our meeting-action guide shows how to define those smaller commitments so “ask the technician” turns into a result someone can use.

Make outgoing replies visible too

Test the shared mailbox from two team members' accounts. Send a harmless internal test message, reply from the shared address, and check that the second person can find the reply and identify its sender.

Microsoft describes shared mailboxes as a way for a group to receive and respond from a common address in its Outlook sharing guidance. That does not remove the need to check your actual configuration.

For example, Microsoft documents a setup in which messages sent from a shared mailbox are saved in the sender's Sent Items, with configuration options for keeping a copy in the shared mailbox. Ask the administrator to check this if replies seem to vanish from the shared history.

Use individual access permissions. Passing around one person's password makes ownership and access harder to manage. Restrict the shared mailbox and register to the people who need them, particularly when enquiries contain customer details.

Make handover part of the working day

At the end of a coverage period, look at three groups: unassigned conversations, overdue check-again dates and promises due during the next person's shift.

For a handover, record the new owner and ask them to acknowledge it. An email forwarding a problem is not evidence that somebody has taken responsibility for it.

Run this arrangement for one normal working week. Note duplicate replies, conversations nobody claimed, forgotten waiting items and time spent updating the register. These observations give you a useful buying brief if the manual coordination becomes burdensome.

Tell a coordination problem from a capacity problem

If work has an owner and next step but the queue keeps growing, changing labels will not create more time. Count new actionable requests and closed requests over the same period, using your agreed closure definition. Keep spam and duplicates separate so they do not flatter the completion figure.

In a fictional week, a team begins with 18 open requests, receives 42 new requests and closes 35. With no other adjustments, it ends with 25 open requests: 18 + 42 − 35. Reassigning those 25 may make responsibility clearer, but the team has accumulated seven requests of work.

Look at why. An increase in enquiries may call for extra coverage. Many requests waiting on the same technician may call for a regular assessment slot. Repeated requests for the same missing photograph may be better addressed by the intake instructions. Tracking the cause gives the team a choice; staring at an unread count does not.

For a first weekly review, use three questions: How old is the oldest unassigned request? Which customer promises were missed? Which waiting reason is holding up the most work? Read the actual conversations behind the answers before deciding what to change.

A specialist inbox may become worthwhile when you need reliable simultaneous assignment, several service queues, reporting or more involved coverage. Judge it against those needs and the awkward conversation above. A fresh interface cannot decide who owes the customer an answer.

During a trial, have two people open the same test conversation, claim it, draft a reply and hand it over. Then make an internal dependency overdue and send a customer reply to a closed request. See whether the tool makes each change obvious from the second person's account. That exercise is more revealing than comparing the length of feature lists. Use the software pilot scorecard to keep the evidence and remaining manual work together.

The shared inbox triage playbook gives you a place to write the claiming rule, statuses, backup arrangements and handover routine. Start with the rule your team can remember when the inbox is busy.