If your team answers customers from a shared Gmail account, you already know the failure modes: nobody knows who replied, emails get read and then lost, and two people answer the same message. This is one shared mailbox where every conversation has an owner and a status — and it runs on your Google Workspace, on your own server.

Run it yourself, or have us run it. The source and the container image are public, so self-hosting is a real option. Or we deploy it for you — no Google Cloud, DNS or server knowledge needed on your side.

Why not just use Gmail?

Google’s built-in way to let more than one person work an inbox is delegation — giving someone access to your account. It’s built for an assistant managing one person’s email, not for a team handling customers. Google documents the limits themselves:

	Gmail delegation	Shared mailbox
Who owns a conversation	Nobody — the concept doesn’t exist	Assign it to an agent
Where a conversation stands	Read or unread. Nothing else	New · In progress · Waiting · Escalated · Closed
What the customer sees	“Their email address appears”	Always your mailbox address
Response deadlines	Nothing tracks them	SLA timer, auto-escalation
Reporting	None	First response, resolution, per agent
Discussing a ticket internally	You’d have to email about it	Internal notes on the thread, invisible to the customer
Canned replies	Manual text snippets	`/` insert with fields filled from the ticket
People at once	“~40 typical” — fewer when APIs are used	Your whole team
Getting someone set up	“Up to 24 hours” — the invite expires in a week	They log in

A shared mailbox doesn’t delegate into someone’s personal inbox. It sits alongside your Gmail — same addresses, same threads — and adds the layer a team needs: ownership, status, deadlines, reporting.

Limits quoted from Google’s delegation documentation for Gmail.

On Microsoft 365?

Shared mailboxes are a Microsoft 365 feature too, and the same pattern plays out there — often a little harder. If that’s your situation, here’s how the two compare side by side:

	Microsoft 365 shared mailbox	Shared mailbox
Getting someone in	Add it in Outlook, wait for it to appear	They log in
Who’s handling it	Nobody knows	Assign it to an agent
Two people reply at once	Both do, nobody sees	Live presence + collision detection
What the customer sees	A shared mailbox can’t send as itself in every client — often a personal address, or a dead-end	Always your mailbox address
Status and deadlines	Read or unread	New · In progress · Waiting · Escalated · Closed, with SLA
Reporting	None	First response, resolution, per agent
Mobile	Painful	Works

This runs on Google Workspace, and if that’s where you’re headed anyway, the mail migration is part of getting there.

Why not a cloud shared inbox?

Hiver, Front and Gmelius solve the same problem, and they’re good products. But they’re cloud services — which means your customers’ email is stored on their infrastructure, in a region they choose, under their security posture, for as long as you’re a customer.

For plenty of companies that’s a fair trade. It stops being a fair trade when:

you have data-residency obligations or client contracts specifying where data may live
your customers’ email contains information a third party shouldn’t be holding
you need the system to keep working if the vendor changes its pricing, its terms, or gets acquired
you’d simply rather not add another company to the chain between you and your customers

Your customer conversations never touch our servers

This one runs on your server — your office, your VPS, or your own AWS/GCP region — and the mail flows through the Google Workspace you already own. There’s no third place your customer conversations get copied to.

	Cloud shared inbox	Shared mailbox
Where customer email is stored	The vendor’s infrastructure	Yours
Which region	Their choice	Your choice
Who can access it	Their staff, under their policies	Your team only
If the relationship ends	You lose access	Your database is yours
Your own backup and retention rules	Limited to what they offer	Whatever your policy requires

You choose where it lives — on-premise, or a specific cloud region
No vendor access to customer data — we don’t hold a copy, because there isn’t one
Straightforward for compliance — residency obligations and internal policies are easier to satisfy when nothing leaves your control
Your mail stays in Gmail, where it already is — what this adds is the team layer on top, without adding another company that holds your customer data

Real-time presence and collision detection

This is the problem a shared password makes impossible to solve, and it is the part we spent the most time getting right.

When two people work the same inbox, nothing tells them the other is there. Both open the same email, both start writing, and the customer gets two different answers.

Live presence fixes the first half. You can see who is online and what they are working on right now — and you can see who is inside a conversation before you open it. Presence appears in the conversation list and on the kanban board, not buried in a side panel, so you know a thread is taken before you click it.

Collision detection fixes the second half. The moment someone starts drafting a reply, the composer locks for everyone else and names who is writing. You cannot type over them, and you cannot send a second answer to an email that is already being handled.

Under the hood it is a heartbeat, not a lock you have to remember to release: presence expires on its own if a tab closes or a laptop sleeps, so a dead session never blocks a live one.

Who is viewing a thread — shown in the list and on the board, with overlapping avatars and a pen marker while someone is drafting
A locked composer — Reply is disabled and the banner names the agent already writing
Presence that self-heals — stale sessions drop out automatically, so you are never waiting on someone who has gone home
Live over SSE — updates arrive in about a second, not on a refresh

What You Get

One shared queue, visible to everyone

List view and kanban board — work from a familiar inbox, or see the whole backlog as columns
Assignment — every conversation has an owner, and everyone can see who
Statuses so work can’t hide: New, In progress, Waiting on customer, Escalated, Closed
Internal notes the customer never sees, attached to the email itself
Live presence — see who’s online and who’s already drafting a reply, so nobody double-answers
@mentions with in-app and desktop notifications

Deadlines that enforce themselves

SLA per ticket with a visible countdown — green on track, amber as it approaches, red when overdue
Automatic escalation — an overdue ticket moves to Escalated on its own, with an audit note
Reporting — open and closed volume, SLA overdue count, average first-response and resolution time, per-agent workload
Scope the report — filter to one mailbox and one period (week, month, quarter, year, or all time), so you can answer “how did support do this month” and not just see a combined total
Customer satisfaction surveys — an optional one-question survey on close, rated and tied to the ticket

The email side, done properly

Replies stay in the customer’s existing thread — customers see a normal reply, not a new email
Real file attachments from customers are stored and downloadable
Canned responses inserted with /, with details filled in from the open ticket
Signatures per agent, with optional auto-insert
Contact history — every past conversation with that customer, plus their other open tickets
Existing mail as archive, not backlog — choose at setup whether to import your history. If you do, it arrives searchable and attached to each customer, not as hundreds of months-old open tickets; a reply on an old thread brings it back as a live ticket
Bulk clean-up — search, select all matching, archive or mark as spam in one action
Non-English mail handled correctly — accents, emoji and encoded subject lines survive intact

Booking a meeting, without leaving the thread

Sometimes a conversation needs a call, not another email.

Check real availability — read straight from the mailbox’s own calendar
Send a normal calendar invite — the customer gets a Google Meet link like any other meeting
The meeting is recorded on the ticket — so what was agreed doesn’t disappear into someone’s calendar
The ticket moves itself to waiting on customer

No separate scheduling tool to sign up for, and no emailing back and forth to find a time.

Runs on your server, not ours

Your Google Workspace, your Gmail — connected through Google’s own API with domain-wide delegation, so customer mail flows through the mailbox you already have
Your infrastructure — it runs on your own server, so your customer conversations stay yours
Sign in with Google — agents use their existing Workspace account
Multiple mailboxes — support@, sales@, billing@ in one place, with per-mailbox access for your team

How It Works

Two ways to run it. The source is public — github.com/wannaco/gw-mailbox — under the PolyForm Internal Use Licence, so running it for your own organisation is free.

Run it yourself. Pull the image, point it at your domain, and connect your mailboxes. You need Docker, a domain and a Google Cloud project — the service account, the domain-wide delegation and the OAuth client are documented step by step in the repository. The Google Cloud side is the part people underestimate, not the server.

Or let us run it. Handled end to end on your infrastructure — never a shared instance of ours. Nothing for you to install, and nothing to configure in Google Cloud.

1. A short setup call

A screen-share, once. We stand up your instance on your server and set up the domain, HTTPS and the Google Workspace delegation with you on the line. You don’t need an IT department for this. If you do have one, they get to watch the security scoping happen rather than take our word for it.

2. Your mailboxes, connected

We connect your mailboxes — support@, sales@, billing@ — and set per-mailbox access for your team. If you want the mail you already have brought over, we import it: it arrives as searchable archive attached to each customer, not as a backlog of months-old open tickets. New mail starts arriving as your live queue. Your team keeps using Gmail normally throughout.

3. Team-ready, then monitored

Your team signs in with the Google accounts they already have. We run a live walkthrough with them on your real conversations, not a sample set. After that we keep watching the instance — sync health, failed deliveries, uptime — so a problem reaches us before it reaches your customers.

Why not just install a plugin?

Fair question: why not something from the Google Workspace Marketplace and be done with it?

Because this isn’t a marketplace plugin

Connecting a tool to your mailboxes means granting it domain-wide delegation — permission to read and send mail as every user in your domain. That’s a security decision, and it deserves to be made deliberately rather than clicked through on an OAuth screen.

Marketplace plugins are usually multi-tenant: your mail travels through the vendor’s servers, in a region they choose, under their policies. This runs on your own server. There’s no additional company holding your customer conversations — the mail stays in the Gmail you already have, and the app sits alongside it.

What you avoid by doing it with us

Google Cloud, by hand. No service accounts, no OAuth scopes, no DNS records, no SSL certificates to figure out.
The security question on your own. The delegation is scoped to exactly the mail and calendar permissions the product uses — and it stays revocable from your admin console, by you, at any time.
Finding out something’s wrong from a customer. We verify the sending identity, the sync and the permissions before your team replies to a real person.
An install that quietly stops working. Once it’s live, it’s monitored — we’re told about a failed sync, not your customers.

Who It’s For

It’s worth having when more than two or three people answer customers, when response time actually matters, or when losing one conversation costs more than fixing the process.

If you’re a team of two answering ten emails a day, a label and a shared password is honestly fine — and we’ll say so rather than sell you this.

Still weighing it up?

We wrote up what actually breaks when a team shares one Gmail account — the five failure modes, what a shared inbox fixes, and what to look for when comparing tools. No pitch, and it’s useful even if you don’t use ours.

Shared Mailbox for Google Workspace