How to Set Up a Shared Support Inbox in 5 Minutes

In short: to set up a shared support inbox, create a workspace, connect your support email (either by connecting Gmail or Outlook directly, or by forwarding your support@ address), pick a template for your statuses and tags, invite your team with the right roles, then send a test email from an outside address to confirm it arrives as a ticket and your reply threads correctly. Active work is about five minutes.

Most small teams start customer support in a shared Gmail or Outlook inbox. It works, until three people reply to the same customer, someone forgets a ticket exists because it scrolled past, and nobody can tell you the average response time. Here's the complete walkthrough, every step, from an empty account to a working shared inbox your whole team can use.

Total time is genuinely around five minutes of active work, the steps below take longer to read than to actually do.

What is a shared support inbox?

A shared support inbox is a single email address, usually something like support@yourcompany.com, that an entire team works from together, where each incoming message becomes a trackable item with one clear owner rather than an email sitting in everyone's view at once.

That last clause is the whole distinction. Several people having access to one mailbox is not the same as a shared support inbox, it's just a mailbox with shared credentials. What makes it a support inbox is that every conversation can be assigned, has a status, carries internal discussion that the customer never sees, and can be measured.

Shared mailbox vs shared inbox tool vs help desk

These three terms get used interchangeably and they really aren't the same thing.

Most teams reading this are on the first row and need the second or third. The good news is that modern tools blur the line between rows two and three, you generally no longer have to choose between "lightweight" and "has reporting."

Before you start

Have these three things ready and the rest goes smoothly:

• A support email address you can either connect directly (Gmail or Outlook) or forward, e.g. support@yourcompany.com
• A second email address you can send a test message from, so you can verify the setup end to end before customers see it
• A short list of teammates to invite, and a rough idea of who should have admin access versus who just needs to reply to tickets

1Create your account and workspace (1 minute)

Sign up and name your workspace, usually your company name. This becomes the shared space your whole team works from; every ticket, teammate, and setting lives inside it. You don't need to get the name perfect, it's editable later.

2Choose how tickets reach you (1-2 minutes)

This is the step most guides skip, and it's the one that actually determines how support tickets show up. There are three channels, and you can turn on as many as you want, they all feed the same inbox:

Email, the main one for most teams. You have two options:

• Connect Gmail or Outlook directly (fastest): log in once, grant access, and every new email in that inbox becomes a ticket automatically. No DNS changes required.
• Forward your support@ address instead, if you'd rather not connect an account directly. This points your existing address at a dedicated inbound address and takes a couple of extra DNS steps, better suited to a team with someone comfortable editing DNS records.

Help portal, on by default, no setup needed. Every workspace gets a public page where customers can search your help articles and submit a request without needing an account. Every submission becomes a ticket automatically. You don't have to do anything here to turn it on, but it's worth knowing it exists, some customers prefer a form over email.

Manual tickets, also on by default. For requests that come in by phone, in person, or in a chat that doesn't have its own integration, anyone on the team can log a ticket by hand directly from the inbox. This matters more than it sounds like it would: it means every support interaction ends up in the same system, not just the email ones.

You don't have to pick just one. Most teams end up using email as the primary channel and manual tickets for the odd phone call, turn on what fits and adjust later.

3Pick a starting template (30 seconds)

A blank ticketing system is intimidating, an empty settings page for statuses, priorities, and tags is exactly the kind of thing that makes "5 minutes" turn into an afternoon. Starting from a template (IT support, general customer support, whatever fits your team) gives you sensible defaults (statuses, tags, a couple of saved replies) that you can rename or extend later, instead of building your taxonomy from scratch.

The goal of a template isn't to be perfect, it's to remove the blank-page problem so you can start using the tool today and refine it next week.

4Invite your team and set roles (1 minute)

Send invites to whoever needs access. Each person gets one of two roles:

• Agent (the default), full ticket access: reply, assign, add internal notes, change status, apply tags. This covers what almost everyone on a support team actually does day to day.
• Admin, everything an Agent can do, plus access to settings: connecting or disconnecting channels, billing, managing the team, and anything else that changes how the workspace itself is configured.

Give admin access to one or two people, not the whole team. This isn't about trust, it's about keeping settings from drifting because five different people each changed something once. Everyone else gets Agent by default, which is already enough to do real support work from day one.

5Test every channel you turned on (1-2 minutes)

This is the step people skip and then panic about later, always verify end to end before you tell customers anything is live.

• Email: send a message from your second address to your support address and confirm it shows up as a ticket. Check that the sender's name and email are correct, and that it lands in the right default status.
• Help portal: open the portal link and submit a test request. Confirm it appears in the inbox the same way an email would.
• Manual tickets: log one by hand for a fictional "phone call" to confirm the flow feels natural for your team.

If you're using email forwarding rather than a direct connection, give it a minute or two, forwarded mail isn't always instant.

6Reply from inside the tool (30 seconds)

Reply to your test ticket from inside the inbox, not from your email client. Confirm the customer copy arrives as a normal, correctly threaded email reply, not a new, disconnected message. This is the whole point of the switch: once this works, your team stops needing to touch the email client at all.

Gmail vs Outlook: what's different

The end result is identical, but the path has a few provider-specific quirks worth knowing before you start.

Google Workspace and Gmail. Connecting directly is the smoothest route. If you'd rather forward, Gmail requires a confirmation step: it emails a verification link to the destination address before it will forward anything. That confirmation email arrives in your new inbox as a ticket, open it, click the link, then return to Gmail and select "Forward a copy of incoming mail to." People routinely miss that second half and wonder why nothing arrives. Note that Google Groups behaves differently from a standard Gmail mailbox; if support@ is a Group, forwarding is configured in the Group's settings, not in Gmail.

Microsoft 365 and Outlook. Direct connection is again the fastest path. If you forward instead, be aware that many organisations disable external forwarding by default through an anti-spam policy, so the option may appear greyed out. That's a tenant policy, not a bug, and an administrator has to allow it before it will work. Shared mailboxes in Microsoft 365 also handle forwarding separately from personal mailboxes.

Anything else. Zoho Mail, GoDaddy, cPanel, iCloud, and most hosting providers expose a straightforward "Email Forwarding" or "Mail Forwarding" setting in their control panel. The mechanics are the same: point your existing address at the new inbound address.

Shared inbox vs ticketing: what you actually gain

• Assignment. Every ticket has an owner, so "I thought you were handling that" stops happening.
• Internal notes. Coordinate on a ticket without cc'ing the customer by accident.
• Status tracking. See what's open, pending, and resolved at a glance instead of guessing from an unread count.
• Response-time visibility. Know whether you're actually hitting your own bar for how fast you reply.
• A searchable history. Every past conversation with a customer in one place, rather than scattered across whoever happened to answer.
• Continuity when someone leaves. Nothing important lives in a personal mailbox that gets deprovisioned.

Troubleshooting: if something doesn't work

Test email never arrives. Check these in order; it's almost always one of them:

1. The spam/junk folder. New sending setups sometimes trigger filters for the first few days.
2. That you connected the account you meant to (it's easy to accidentally grant access to a different Gmail account if you're signed into more than one).
3. If you're forwarding rather than connecting directly, that the forwarding rule actually saved on your email provider's side, some providers require a confirmation click before a forward goes live.

Ticket shows up but the reply doesn't reach the customer. Double check the ticket's requester email is correct, if the original message had an unusual "reply-to" header, it can occasionally differ from the visible sender address.

Portal submissions aren't appearing. Confirm the portal is actually published, it only shows up once your workspace has finished onboarding, which happens automatically once you complete step 3 above.

Your first week: what to set up next

Once the basics are working, a few small additions make the day-to-day noticeably smoother:

• Saved replies for the two or three questions you answer most often, set them up once, insert them in one click from then on.
• Tags that match how your team actually categorizes issues, if the template defaults don't quite fit.
• The dashboard, check it after a few days of real tickets to see your actual response times, not a guess.

None of this requires an engineer, a consultant, or a kickoff call. If your team is still working out of a shared inbox, the actual barrier to switching is usually much smaller than it feels, the hard part is deciding to do it, not the setup itself.

If you're not yet sure whether you need this at all, the five signs you've outgrown a shared email inbox is the better place to start. And once you're up and running, our email support best practices covers the habits that matter more than any feature.