Google Workspace Shared Inbox for a Small Japan-Entry Team: Alias vs Group vs Delegation vs a Paid Seat

Direct answer

A three-person working team made up of two internal users and one outside agency usually begins with two paid user identities, not a paid mailbox for every role address. Use a Google Group when several people own a queue, an alias when one person owns the role, and delegation only when another internal user must operate a real mailbox. The agency needs a paid identity only when it must work inside the Workspace organization.

Research-based initial edition. This article is Evidence Level C and is not a hands-on test. The team and company below are fully synthetic. Japan Legible participates in the Google Workspace Referral Program, but this article contains no referral link or code and cannot generate a referral fee. Participation does not determine the recommendation. Product behavior and official URLs were checked on August 16, 2026. Live prices, taxes, legal retention, and security-certification conclusions are outside scope.

Short answer

License each person who needs an independent sign-in, storage, and sender identity. Then choose the lightest role-address model that preserves a clear owner.

For a synthetic three-person Japan-entry team with two internal users, an overseas founder and a Japan sales employee, plus one outside localization agency, a credible starting point is:

• japan@: a Google Group shared by the founder and sales employee;
• sales@: an alias attached to the sales employee's account;
• support@: a Group configured as a Collaborative Inbox for the founder and sales employee;
• legal@: either a single-owner alias or a real mailbox delegated to a trusted internal user, depending on whether it needs its own record and operating history;
• outside agency: an external Group member when it only needs selected messages, or a paid user only when it needs an organization-managed identity and access.

An alias is an alternate address for one user, not a shared account. A Group has managed membership and settings instead of one user's mailbox. A Collaborative Inbox adds assignment and resolution tools to a Group. Delegation grants access to an actual mailbox; an alias cannot receive delegation because it is not a Google Account.

Reader decision

The useful question is not "How many email addresses do we need?" It is "What kind of work and identity must each address hold?"

The reader decision is a pair: decide who needs an independent identity, then decide whether each role address needs one owner, a shared queue, delegated operation, or a separate paid user.

Reader decision

Option	What it represents	Best fit	Do not use it when
Alias	Another address for one existing user	One accountable owner, such as sales@	Several people need one shared queue or a separate sign-in
Google Group	A managed address with members	Distribution, intake, or a shared role	The role needs its own mailbox identity and storage
Collaborative Inbox	A Group with assignment and resolution controls	A small support or enquiry queue	Members only need passive copies or private mailboxes
Delegated mailbox	A real mailbox another user can operate	A trusted internal user must work inside the same mailbox	The address is only an alias, or the operator should have an independent identity
Paid user	An independent licensed identity	A staff member or managed agency user needs sign-in, mailbox, files, and policy controls	The requirement is only one more public address

Forwarding the same message to several inboxes is distribution, not automatically a shared work queue. A queue also needs visible ownership and resolution.

Evidence card

Evidence card

Dimension	Status in this draft
Vendor-documented claims	Official Google Workspace Help, Gmail Help, and Learning Center pages checked on 2026-08-16
Inferred claims	Operational conclusions drawn from that documentation for a synthetic team
Unknown claims	Mobile mailbox behavior, live prices, taxes, legal retention, and security-certification conclusions
Observed claims	0. This draft reports no hands-on observation, no controlled account test, and no measured delivery result

Verification gaps to keep explicit

These dimensions are part of the decision, but this first edition does not turn them into invented measurements:

Verification gaps to keep explicit

Decision dimension	Current status	What a future approved tenant run would record
Setup time	Unknown / not observed	Start and finish timestamps for each configuration, including propagation waits
Gmail usability	Unknown / not observed	Web and mobile steps for receiving, replying, changing From, and finding shared history
Recovery and offboarding	Unknown / not observed	Whether each address remains reachable after removing a member, delegate, alias, or paid user
Auditability	Unknown / not observed	The administrator-visible record of membership, assignment, delegation, and sender changes
New shared-inbox UI	Unknown / tenant-dependent	Whether the feature is visible in the tested Workspace tenant and what controls it exposes

Until those observations exist, the tables below are architecture choices derived from published documentation, not measured implementation results.

The five configurations

1. Alias

Use an alias when one person owns the role and another login would add no useful boundary.

Vendor-documented. Google documents an email alias as an alternate address attached to a user's account. Messages sent to the alias route to that user's primary inbox. The alias is not a Google Account, so it cannot be used to sign in to Workspace services. Google also states that up to 30 aliases can be added to one user without extra cost.

Inferred. An alias is a good fit for sales@ when one Japan sales employee owns every response, or legal@ when the founder alone owns legal correspondence.

Do not use an alias as a disguised shared inbox. Google states that only one user can use an alias for receiving mail. If several people need to assign, track, or resolve conversations, use a Group or a real mailbox with an explicit access model.

Sending from an alias is a separate Gmail configuration step. The Admin console address alone should not be treated as proof that every user can immediately send with the intended From identity.

2. Standard Google Group

Use a Google Group when the address belongs to a role or team rather than one person's mailbox.

Vendor-documented. Google's administration documentation describes creating a Group and controlling its members and access settings. The address is managed around membership, not around one user's sign-in.

Inferred. That makes japan@ a sensible Group when the founder and Japan sales employee should both receive and own new enquiries.

Do not make every role a Group. sales@ should remain an alias when one employee owns the motion, because extra recipients can obscure accountability.

3. Collaborative Inbox

A Collaborative Inbox adds work-state controls to the Group model.

Vendor-documented. Google documents features for assigning conversations, marking them complete, duplicate, or requiring no action, and searching by resolution status or assignee. Those functions require the right permissions and conversation history.

Inferred. That distinction matters for support@: copies can hide ownership, while a Collaborative Inbox can name an assignee and resolved state. It does not create a service policy, but it gives that policy a visible queue.

4. Delegation

Use delegation when another trusted user must work inside an existing Gmail account without sharing its password.

Vendor-documented. Google documents that a delegate can read, send, and delete messages in the account. Google also says a delegate cannot chat as the account or change its password. Google states that an alias cannot receive delegation because it is not a Google Account.

Inferred. Delegation can fit legal@ when it is a real mailbox and a trusted internal user must process its messages.

Do not use delegation to avoid creating an identity for a person who needs one. A new employee or embedded agency operator who needs independent sign-in, files, and accountable activity needs a managed user decision, not silent access through another person's mailbox.

5. Paid seat

Buy a paid user when a human needs an organization-managed identity and Workspace access.

Vendor-documented. Google presents Workspace pricing per user and by edition. The live price can change with edition, market, commitment, and offer, so this draft does not preserve a number. Use the official pricing page on the purchase date.

Inferred. For the synthetic team, the founder and Japan sales employee each need a paid identity. The outside agency needs a paid identity only when it must sign in under the organization's domain, hold files, send as itself, or enter the organization's access lifecycle.

Reply identity and history

Vendor-documented. Sending from a different address or alias is a separate Gmail configuration step, and a delegate's address appears when the delegate sends.

Inferred. Reply identity should be part of the architecture, not an afterthought. Confirm which From address the operator expects to use before relying on the Admin console alias assignment alone.

Unknown. How each model renders replies, conversation history, and sender identity on every mobile mail client is not observed in this draft. Verify on the actual devices and mail clients the team uses.

Offboarding

Design each role address so access can be removed without losing the public route or hiding the next owner.

Use this checklist when an employee or agency leaves:

1. Remove the person from every Group and Collaborative Inbox.
2. Record and transfer Group ownership or management roles.
3. Remove mailbox delegation in both directions.
4. Reassign or remove aliases attached to the departing user's account.
5. Name a current owner for japan@, sales@, support@, and legal@.
6. Test inbound delivery to each public role address.
7. Test the intended From identity where send-as was configured.
8. Review downstream forms, CRM routes, newsletter replies, and vendor accounts that still reference the old address.
9. Handle the user's files, calendar, and account lifecycle under the organization's separate offboarding policy.

This checklist is operational, not legal-retention advice.

Contractor boundary

Inferred. Give the outside agency access only to the role or Group needed for its defined engagement. Do not give it founder-mailbox delegation simply because that is technically convenient.

Do not make an outside agency a broad Group member merely because membership is technically possible. Give it only the messages and files required for the engagement. A paid identity is a separate decision from message access: it licenses an organization-managed identity, it does not by itself justify broad access.

Mobile unknown

Unknown. Mobile behavior is not documented to the depth this draft needs. Whether aliases, Groups, Collaborative Inbox assignment, delegation, and send-as behave identically in the Gmail mobile app, the Google Admin mobile app, and third-party mail clients is not observed here.

Before launch, check the official current pages and confirm behavior on the exact devices and mail clients the team uses. Do not present this draft as a substitute for that check.

Cost formula

Model the recurring license cost as:

licensed people x current verified per-user price for the chosen edition and billing term

Then review tax and currency at checkout rather than importing them into an evergreen article.

Cost formula

Operating size	Minimum identity assumption	License-count formula	What shared role addresses change
1 person	One founder needs one identity	1 x current price	Aliases and Groups can add role addresses; they do not create another human identity
3 internal people	Three internal people need three identities	3 x current price	Shared addresses can be aliases or Groups; do not add a seat merely for japan@
10 people	Ten internal people need ten identities	10 x current price	Add users for people; add Group structure for teams and queues

Decision matrix

Start with the people, then add role addresses around explicit ownership.

Decision matrix

Public address	Documented model	Recommended shape for the synthetic team
japan@	Group with managed membership	Group for founder and sales employee
sales@	Alias on one user account	Alias on the Japan sales employee
support@	Collaborative Inbox	Group as Collaborative Inbox only when both internal users assign and resolve conversations
legal@	Alias or real mailbox	Alias unless a distinct record and delegated operation are justified
Outside agency	External Group member or paid user	Constrained Group membership; paid identity only for organization-managed work

If the outside agency only needs selected enquiries, constrained membership may be enough. Assess a paid user when it must sign in under the organization's domain, hold files, send as itself, or enter the organization's access lifecycle.

What Workspace does not solve

No address model replaces an owner, response rule, or customer record. An alias is not a second account or queue. A Group is not a person. A Collaborative Inbox does not define response or escalation policy. Delegation does not erase the mailbox owner's accountability. A paid user does not prove that broad access is appropriate.

Google's documentation describes product behavior. It does not decide which records your team must retain, which evidence is legally sufficient, or which configuration satisfies a certification. Confirm those questions with qualified owners for the actual organization and data.

Disclosure

Japan Legible participates in the Google Workspace Referral Program and may receive a reward if an eligible new customer signs up through a clearly marked referral link. This draft contains no referral link, referral code, or promotion code, so no reward can be generated from this draft. The relationship does not determine the recommendation. Participation in the referral program is separate from product suitability, and this article does not compare the referral program against other programs.

Limitations

• Evidence Level C: research-based from published sources; not a hands-on test.
• Fully synthetic three-person scenario; not a customer case.
• No live delivery test and no real account mutation.
• Mobile mailbox behavior unknown.
• No live price, tax, legal retention, or security-certification conclusion.
• Official documentation and URLs can change after 2026-08-16.

Reproduction

The research protocol for this article is research/labs/google-workspace-email-architecture/protocol.yaml. Its dry-run reproduction command is:

npm run run:evidence-lab -- google-workspace-email-architecture --dry-run

The lab remains pre-observation. Running the dry run records no observation and performs no external action.

Update log

Update log

Date	Change
2026-08-12	Original guide drafted and official Google sources checked.
2026-08-16	Moved from guides to entry-stack; commercial relationship synchronized to referral; draft rewritten with labeled evidence card, five configurations, contractor boundary, mobile unknown, cost formula, decision matrix, and reproduction sections.

Use Google Workspace for a small Japan-entry team to decide whether Workspace is the right foundation. Use Google Workspace versus Zoho Workplace when the suite itself is still undecided.

Review the current Google Workspace pricing only after the identity count and operating model are clear.