As soon as your support team becomes, well, an actual team with more than one person, shared inboxes need coordination. 

Small teams usually handle this by assigning one individual to specific times of day or specific topics. A team of two or three may have notifications come through Slack so whoever sees it first can just reply with an emoji reaction or “I’ve got this one.” And that works fine, as long as everyone continues to actively communicate.

But every person you add makes that harder. Two people accidentally reply at the same time. A conversation sits for three days because everyone assumes someone else was responsible for it. One person ends up handling 200 conversations while another handles 50.

That’s when a shared inbox starts to feel cumbersome. You can still make it work, but not with the same informal approach. You need a clearer process, and the shared inbox best practices below can help you build one.

1. Write down how the queue works

Before you change any process, write down everything that’s currently happening, or at least everything that is supposed to be happening. Most of this already lives in people’s heads. By putting it on paper, you have a visual of how much mental fatigue your staff are carrying around with them from task to task and what a new hire needs to learn.

At minimum, this can become a checklist for completion with every customer conversation. At best, it's your starting point for refining your shared inbox process.

Cover the basics:

  • Who handles which topics, channels, or hours

  • How quickly you aim to reply, and what counts as a reply

  • When to escalate, and to whom

  • What tone you use with customers

  • How to decide when a conversation is finished

  • When and how to follow up if a conversation ends on a sour note

  • What to do when nobody’s sure who owns a conversation

Once you start writing things down, you’ll likely discover you have an entire mini-wiki of information that’s been living in your head. Organize it and put it somewhere easy to find and easy to edit, and make it shareable across the team. While there are entire products built for this type of internal information, a shared Google Doc is enough to get you started. 

But a process doc nobody maintains goes out of date fast, and new hires will trust it anyway, so assign an owner to the document. 

Now take a step back and look at the list. There will likely be some glaringly obvious places where you can free up some bandwidth for your team. Every action that depends on someone remembering is a place for a decision tree, a tool setting, or automation. 

For instance, maybe “Joey handles all billing issues.” That’s an easy place to add some automated routing of messages (if you’re using a tool that allows for it). Set up a workflow so something that is tagged as billing is automatically assigned to Joey.

2. Give everyone their own login and the right permissions

I once worked at a company where our support emails all came into a single support@ email address hosted through Google Workspace and forwarded to our support tool. We all had our own login for the support tool, so on paper, access was handled. But for reasons I still don’t understand, one of my team members had a direct login to the Google Workspace account, with enough permissions to cause real problems.

That team member was eventually let go, and it wasn’t pretty. Within 48 hours of their departure, the mail forwarding from support@ to our support tool was turned off. I’m still in touch with this person, who insists they had nothing to do with it. But I used to work in the veterinary industry, which has a saying: if it looks like a zebra and smells like a zebra…it’s probably not a giraffe.

Either way, they never needed that level of access to do their job, and nobody thought to take it away when they departed.

Individual logins are the baseline. No shared passwords, ever. With this, you always know who replied, assigned, or closed a conversation. From there, give each person only the access their role needs. Most shared inbox tools let you set roles that control who can change settings, edit saved replies, or delete conversations. 

And remember: the accounts connected to your inbox (email hosting, forwarding rules, integrations) need the same attention.

Review access whenever someone changes roles. And for the love of all that is good, remove access before you let someone go.

3. Give every conversation a visible owner

“I think Sam’s on that one” isn’t ownership. A name attached to a conversation in a mailbox that everyone sees is.

How you create ownership depends on your tool. Ticket or conversation assignment is a core feature of any dedicated customer service platform. Every conversation shows who owns it, and assigned conversations can show up in that person’s personal view so they don’t get lost in the main support queue.

But if you’re working out of Gmail or Outlook inboxes, it’s a little tougher. 

In Gmail, a Google Groups Collaborative Inbox does let members take a conversation or assign it to someone else, as long as they have the right group permissions. If your email tool doesn’t have that option, you’ll have to find a more creative way to make ownership visible.

A few ideas:

  • Give each person their own category or label

  • Set up a folder for each team member or topic

  • Give each team member a color-coded flag

Whatever tool you use, keep an “unassigned” view and treat it as your real backlog. Anything sitting there is something nobody has claimed yet. That number should trend toward zero by the end of every day, and if it doesn’t, you’ve found your first process to fix.

4. Choose a distribution model that matches your team

Once ownership is visible, the next question is how conversations get to their owners in the first place. There’s no single right answer here. What you choose to do will depend on your volume, size, specialization of your team, and what your tool can do. Most teams end up using a mix of the following.

First in, first out / self-assigned

Everyone works from the same queue. Start with the oldest unassigned conversation, assign it to yourself, and answer it. This works with any tool and requires zero set up. It’s the way I’ve always worked by default

Pros: It's simple, and the oldest conversations get handled first.

Cons: It invites cherry-picking. Easy conversations go fast while tricky ones sit until someone gives in and claims them. People may also forget to check conversations already assigned to them, so “in progress” work can sit longer than it should.

Manual triage

One person reviews all new conversations and assigns them out to whichever team members make sense.

Pros: A human decides what the conversation is about and who is best suited to handle it.

Cons: It gets overwhelming when the volume spikes, and it means you’re pulling someone away from helping customers directly. If they’re also managing their own conversations, it can get messy. Rotate the role by hour or day so nobody falls behind.

Rules-based (automated) routing

Remember, Joey handles all billing conversations. This is where that line from the process doc turns into a rule. Most email tools allow for labeling based on subject or body keywords, receiving email address, or sender email. Dedicated support platforms can take this a step further and assign these directly to the right person or team with automated workflows. 

Pros: Predictable requests go straight to the right person.

Cons: Rules only catch what they’re written for. Anything worded differently doesn’t get routed.

Round robin

With round-robin routing, new conversations go to each teammate in turn.

Pros: Everyone gets an equal share of the volume and has to stretch beyond the topics they know well. 

Cons: Equal isn’t always fair. Someone can fall behind on conversations if they don’t know how to answer them, while your fastest people (every team has that one person who’s basically a machine) run out of work.

Balanced assignment

The next conversation goes to whoever has the lightest load. Tools like Help Scout offer both round robin and load-balanced routing, with assignment limits so nobody gets buried.

Pros: Nobody gets swamped and fast team members can have greater impact.

Cons: It counts conversations, not how time-consuming they are to answer.

Skills-based routing

Conversations go to people based on what they know, like a specific product, language, or technical level.

Pros: Customers reach someone best equipped to solve their problem.

Cons: More setup and upkeep, and it bottlenecks if your only expert (like your only Spanish speaker) goes on vacation.

AI-based routing

Some platforms read a message’s content to decide where it goes. Zendesk’s intelligent triage, for example, classifies new requests by topic, sentiment, and language, which you can use for routing.

Pros: It catches requests that don’t use the keywords your rules expect.

Cons: It needs monitoring, takes setup, and usually costs significantly more.

5. Stop duplicate replies before they happen

One of the most common problems with a shared inbox is two people answering the same customer at the same time. At best, it’s wasted time. At worst, the customer gets two different answers and is left confused trying to figure out which is right. Either way, it looks bad and  doesn’t build much trust for future issues.

In a Gmail or Outlook inbox, the fix is usually a rule that is left to the individual to follow: claim the conversation before replying. Assign, label, or move the conversation using whatever ownership system you set up in #3, then start writing a reply. You’ll also want to refresh and recheck the thread right before hitting send, especially on conversations that have been sitting for a while.

Dedicated support tools like Help Scout usually handle this for you through features like collision detection, which show when a teammate is viewing or replying to the same conversation, and it pauses your reply if someone else adds a reply or note while you’re still writing.

Even with collision detection, it’s still ideal to train your team to claim a conversation first, just in case. Machines aren’t perfect, either.

6. Keep internal discussion inside the conversation

Every team has discussions behind the scenes about customer conversations. Who knows how to fix this bug? Can we offer this customer a discount or refund? 

When that discussion happens in Slack or a forwarded email, the context splits off, and the next person to pick up that customer has no idea any of this discussion happened. Not to mention, one wrong reply-all and your internal commentary lands in the customer’s inbox.

The best support inbox tools solve this with internal notes and @mentions, so the discussion stays attached to the conversation for whoever comes next.

If your tool doesn’t have notes, set a rule: Any time you discuss a conversation elsewhere, include a link to customer conversation and record the outcome in whatever system is tied to your customer’s account, like your CRM.

7. Define what “done” means

In the process doc we discussed in step #1, you wrote down how to decide when a conversation is finished. Now make that visible in the inbox, because “done” isn’t one thing.

Some conversations are resolved. Some are waiting on the customer. Some are duplicates, and some never needed a reply at all. If they all end up in the same “closed” pile, you can’t tell what your team actually solved, and conversations that still need a follow-up disappear.

Most tools support more than one end state. A Google Collaborative Inbox lets you mark conversations as complete, duplicate, or no action needed. Support platforms typically use statuses like pending and closed, plus snooze to bring a conversation back on a set date.

Two rules help here:

  • Use pending or snooze instead of leaving conversations open as a reminder to yourself. An open conversation should mean someone needs to act. 

  • Close or archive conversations that no longer need attention.

Do not delete anything ever. Okay, I’m sure some things can be deleted, but that’s rare. It’s much better to just close or archive something. You never know when you might need the historical data.

8. Build one shared tagging system

Tags, labels, categories, or topics are how you find patterns in your inbox: what customers ask about most, which issues spike after a release, or where your saved replies need work. It’s a ticket handling best practice, but it only helps if everyone uses the same tags.

Left alone, a team will create “billing,” “Billing,” “invoice,” and “payment-issue” for the same thing. Your reporting gets split four ways, and nobody can find anything.

Agree on a short list of tags and give one person ownership of it. New tags go through them. Use tags for what a conversation is about, and use folders or views for where it sits in your workflow. Then review the list every quarter or so and merge or retire anything that’s drifted.

9. Maintain saved replies as a team

Saved replies (also called templates, canned responses, or macros, depending on what tool you’re using) keep answers consistent and save your team from typing the same answer 40 times a week. 

The trouble starts when everyone builds their own. Before long, you have five versions of the same answer, two of them out of date, and customers get a different response depending on who replied.

Keep one shared reply library, with one version of each answer. Like your tags, give it an owner who updates replies when a policy or product changes. When someone writes a great answer to a new question, add it to the team's saved replies.

But always remember to treat saved replies as a starting point. Adjust each one to the customer’s actual question before you hit send.

10. Revisit your rules as the team changes

Every setup step in this article is built for the team you have right now. Every time your team changes, something in your system goes stale.

When someone joins the team, check that they’re included in your routing, have the right permissions, and know where the process doc lives. When someone leaves or changes roles, remove them from routing pools and assignment rules and update their access. When you add a new support channel or product, make sure your rules, tags, and saved replies cover it.

Then, every few months, clean house. Retire the tags, views, and saved replies nobody uses, and update the process doc so it matches how your team actually works today.

Start where the most friction lives

Ten best practices is a lot to take on at once, and you don’t have to do it all. Look at what’s causing your team the most trouble right now and start there.

If customers are getting duplicate replies, start with ownership and collision detection. If conversations are slipping through, set up an unassigned view and a distribution model. If new hires keep asking the same questions, write the process doc and clean up your saved replies.

Most of these shared mailbox best practices work in whatever tool you’re using today. But as your team grows, you’ll probably find yourself doing more and more of it by hand. That’s usually a sign that it's time to leave Gmail or Outlook and invest in a tool that can handle some of the routine work so your team can spend its time on what actually matters: helping customers.

If you’re at that point, try Help Scout for free and see how much of your process it can take off your plate.

Like what you see? Share with a friend.
Anne-Marie Traas
Anne-Marie Traas

Anne-Marie is a Fractional Head of Customer Success focused on providing an optimal customer experience in every interaction. She specializes in driving process and product improvements, creating thorough and easy-to-understand product documentation, and teaching others how to communicate more effectively through the written word. You can find her on her website.