Gmail shared inbox to helpdesk: a Google Workspace guide
Plenty of businesses run support from a Gmail address. It works until it doesn't. This guide covers the options Google Workspace gives you, the signs you have outgrown a shared inbox, and how to connect a helpdesk to Gmail without handing over the keys to your whole domain.
Published · 7 minute read
Shared inboxes in Google Workspace
Microsoft 365 has a thing called a shared mailbox. Google Workspace does not, so teams pick one of three set-ups.
A Google Group as a collaborative inbox
Customers email support@, which is a group. Members see the conversations and can take or assign them. It costs nothing extra and is quick to set up. It has no priorities, no response deadlines and no customer history, and reporting on who answered what and how fast is close to impossible.
A user mailbox with delegated access
support@ is an ordinary Workspace user, and staff are given delegated access to it. Everyone sees the same mail, so it feels like one shared inbox. The trouble is that it is exactly that: two people can answer the same email, nobody owns a message, and anything read and left alone looks handled.
A helpdesk on top of the mailbox
The mailbox stays where it is and customers keep emailing the same address. Each email becomes a ticket with an owner, a priority and a deadline, replies thread back onto it, and you can see what is waiting. This is the step most teams take once the inbox starts losing things.
Signs the inbox has stopped working
- The same customer email gets two answers, or none.
- Somebody keeps a spreadsheet to track what the inbox cannot.
- Nobody can say how long customers wait for a first reply.
- Work depends on the one person who knows which emails matter.
- Customers ring to ask whether their email arrived.
None of these is about volume. A team of four can hit every one of them on thirty emails a day, because the problem is ownership, not quantity.
How a helpdesk connects to Gmail
There are two ways for software to reach a Gmail mailbox. One is a person signing in and approving access. For a shared support address that is fragile: access is tied to whoever clicked, and Google treats the Gmail permissions involved as restricted, which puts any vendor using them through verification and a recurring security assessment.
The other is a service account. Your Workspace admin creates it in a Google Cloud project you own and authorises it through domain-wide delegation to act as the support mailbox. Nobody signs in, nothing is installed for staff, and you can withdraw it at any time from the Admin console.
A setup checklist for your IT admin
01Connect a user mailbox, not a group
If support@ is a Google Group, create a user mailbox such as helpdesk-inbox@, add it to the group, and connect that. Customers notice nothing.
02Use a project that does nothing else
Create the service account in its own Google Cloud project, with the Gmail API enabled and no other roles. If your organisation blocks key creation, allow it for that project only, create the key, then switch the block back on.
03Grant two scopes and no more
In the Admin console, domain-wide delegation needs the service account's client ID and two scopes: gmail.modify, to read and mark messages as read, and gmail.send. Delegation usually works within minutes, and Google says it can take up to a day.
04Insist the vendor limits itself to one mailbox
Because delegation cannot be narrowed to one user, ask any helpdesk vendor how they stop the key reading other people's mail. The right answer is an approved list of mailbox addresses that the software refuses to go beyond.
05Keep the ticket reference in the subject
Gmail's own threads are not a reliable ticket boundary, because unrelated messages can end up grouped together. A helpdesk should match replies on its own ticket reference in the subject line, and keep it there when it replies.
06Treat the key like a password
Anyone holding the key file, with delegation in place, can read and send mail in your domain. Store it once in the helpdesk, keep no copies, and delete it in Google Cloud if you ever stop using the service.
How Dispatch Layer works with Google Workspace
Dispatch Layer connects to your Gmail mailbox the way this guide describes: a service account in your own Google Cloud project, two Gmail scopes, and an approved mailbox address it will not go beyond. Every email becomes a ticket with the right customer, a priority and an SLA clock, replies thread back onto it, and your team answers from the address customers already know. Microsoft 365 works the same way.
Common questions
- Does Google Workspace have shared mailboxes?
- Not in the way Microsoft 365 does. The usual options are a Google Group set up as a collaborative inbox, or an ordinary user mailbox such as support@ that several people are given delegated access to.
- Can a helpdesk read a Google Group?
- Not through Gmail's API. A Google Group is not a mailbox, so there is nothing for the API to read. The fix is simple: create a user mailbox, add it to the group so it receives every message, and connect that mailbox instead. Customers keep emailing the group address.
- How does a helpdesk connect to Gmail?
- For a business, the cleanest route is a service account in a Google Cloud project you own, authorised by your Workspace admin through domain-wide delegation for two Gmail permissions: read and modify, and send. Nobody signs in, and nothing is installed for staff.
- Is domain-wide delegation safe?
- It is powerful. Google cannot limit it to one mailbox, so a key with delegation could act as any user in your domain. Keep the key in a project used for nothing else, grant only the two Gmail scopes, and choose a helpdesk that refuses to touch any mailbox except the one you approved.
- Can we still reply as support@ if a different mailbox is connected?
- Yes. Add support@ as a Send mail as address on the connected mailbox in Gmail settings, and replies go out from the address customers know.
Using Simpro as well? Read our practical guide to the Simpro API.