Set up a customer-support shared inbox

A shared inbox gives customers one dependable address and prevents support from living inside a founder's personal email. The setup is more than adding colleagues to a mailbox. The team needs to decide which messages count as support, who owns each conversation, what happens during absence and how an old answer can be found.

This guide describes a light operating system for small teams. It works whether the underlying tool is Google Groups Collaborative Inbox, a Microsoft 365 shared mailbox, a CRM inbox or an email-led help desk. The exact buttons differ, so confirm the provider's current instructions for the platform you choose.

The minimum viable setup

Keep the first version small. A dozen labels and several routing rules often create more ambiguity than one accountable owner and a daily review.

1. Create a stable support identity

Choose an address customers can remember and that will survive staffing changes. Document who controls it, where its domain settings live and which aliases forward into it. If sales, billing and technical support use different addresses, decide whether they converge into one queue or remain separate. Do not publish a new address until someone has tested incoming mail from outside the organisation and a reply back to that sender.

Set a human-readable sender name and a short signature with the business name and expected coverage. If an automated acknowledgement is used, state that the message was received and when a person is likely to respond. Do not imply that an automated note is a personalised answer.

Check deliverability after configuration changes. A support address that receives messages but sends them from the wrong identity undermines trust and complicates thread matching when the team later adopts a help desk.

2. Give people individual access

Avoid distributing a single password. Microsoft distinguishes Full Access from Send As and Send on behalf permissions for a shared mailbox; one capability does not automatically grant the other. Its recipient permissions guide is the right reference when configuring Exchange Online. Test both opening the inbox and sending a reply with the intended identity.

Google Groups' Collaborative Inbox guidance describes taking and assigning conversations and marking them complete. Those actions depend on group history and moderation permissions, so invite a non-admin colleague to test the real workflow. A plain Gmail delegation or a group address is not automatically the same as a ticket queue.

For any platform, remove access promptly when people change roles, use multifactor authentication where supported and decide whether contractors can see all conversations or only a limited queue. Customer email often contains personal information; grant access for the work, not for convenience.

3. Decide who can claim and reassign work

Write the rule in one sentence: the first person who begins investigation claims the conversation; the current owner is responsible for the next customer update until they explicitly transfer it. Allow anyone covering the queue to reassign an absent owner's work, but require a note explaining the next action.

If the tool supports assignment, use it consistently. If it does not, a shared label or folder can act as a temporary convention, but the team must check it before replying. Personal stars or unread state are poor ownership markers because they can differ by user and do not describe responsibility.

Test simultaneous work. Have two colleagues open the same case, one begin drafting, and see whether the other is warned. If not, add a manual check before sending. Collision prevention is a practical reason to consider dedicated shared-inbox software, but it does not replace the owner rule.

4. Keep statuses few and meaningful

Use “new” for unclaimed work, “working” for an owned case with a next action, “waiting” when the next step is outside the team, and “resolved” when the customer outcome is complete. Waiting must not mean forgotten. Give waiting cases a review date and identify whether the team is waiting for the customer, a supplier or another internal group.

Do not create a label for every product or customer type on day one. Add categories only when they change routing, reporting or a saved answer. A category that nobody uses to decide anything is administrative noise.

Set a reopen rule. If a customer replies to a resolved conversation, it should reappear for a person to review. Verify this behaviour in the actual platform; never assume a closed folder is watched.

5. Write the handover and escalation rule

A useful handover note contains the customer's request, what has been checked, what has been promised, the current blocker and the next action with an owner. If the inbox has no private notes, use an approved internal method that protects customer data; do not forward sensitive material casually or hide essential context in an individual chat.

Decide which cases require escalation, such as a payment issue, security concern, service outage or customer deadline. Say who is on call and what happens if that person is unavailable. For ordinary work, avoid turning every uncertain answer into an escalation. The owner can ask a specialist while retaining responsibility for the customer update.

6. Create a small reply library

Prepare answers for the recurring requests that are genuinely stable: receipt acknowledgement, request for missing order details, status update, and a clear resolution summary. Use placeholders for the customer-specific facts and require the agent to review them. A saved reply should shorten typing, not remove judgement.

Include the next step and timing in every reply. “We are looking into it” is less useful than “We are checking the courier scan and will update you by tomorrow afternoon.” Do not promise times that the coverage schedule cannot support. Review templates when policies, products or delivery partners change.

7. Run a daily queue sweep

At the start and end of the support day, one person checks new unowned messages, working cases with overdue next actions, waiting cases that need chasing and reopened conversations. This can take a few minutes in a tiny team, but it needs to be assigned. Rotate the duty deliberately rather than assuming someone will notice.

Once a week, count incoming cases, resolved cases, oldest open cases and avoidable repeats. A basic spreadsheet is acceptable initially. If producing these figures becomes a larger project than using them, the team may be ready for a help desk with reliable reporting.

Where software changes the setup

HelpDesk offers an email-led ticket queue for teams that want stronger ownership without building an elaborate operation. Freshdesk can add knowledge, a portal and richer routing as the workload grows. HubSpot Service Hub is most interesting when the inbox should share a customer record with sales or account teams. Zoho Desk is a value-led help desk path, though edition limits matter as automation grows.

Choose the smallest route that solves the actual failure. Run the same claim, handover and reopen test in each candidate. A broad platform can still make an everyday email reply slower; a light product can lack the reporting a manager needs. Our shared inbox software comparison covers those trade-offs in more detail.

Pilot and publish

Start with a small number of real conversations or an internal test address. Test an outside sender, a forwarded thread, a reply to an old subject, an attachment, a colleague's absence and a customer reply after closure. Confirm the customer sees only the intended message and sender identity, not private notes or internal forwarding.

Then publish the address where customers already look: contact page, order email, product help or account area. Retire confusing legacy addresses only after forwarding and monitoring them. Review the first week each day and correct the process before adding more automation.

Bottom line

A shared inbox is ready when every customer message can be claimed, understood by another colleague and revisited until the promised outcome. If the team cannot maintain those basics in the chosen inbox, see when to move beyond it and trial a ticket queue.

Sources and further reading

• Google Workspace: Collaborative Inbox setup and assignment permissions.
• Microsoft Learn: manage mailbox recipient permissions.
• HelpDesk: manage automation rules for a later, structured-ticket route.

The setup sequence and product-fit advice are Support Sorted's editorial guidance.