Google Workspace Groups¶
Home / Guides & Runbooks / Google Workspace Groups
This document describes the Google Workspace groups configured on the anvil.co domain. It is intended as an onboarding reference so new team members can understand which group to email for a given purpose, how membership works, and how to request access or changes.
Overview¶
Groups serve three primary purposes:
- Distribution lists — send one email, reach the right set of people.
- Shared inboxes — route external communications (support, billing, privacy, info) to a team rather than an individual.
- Access control — grant shared access to third-party services (e.g., AWS, vendor dashboards, SaaS subscriptions) by adding group members rather than provisioning each person individually.
When in doubt about which group to email, default to the narrowest group that contains the right audience. Avoid emailing everyone@ unless the message is genuinely for the whole company.
Groups¶
admin@anvil.co¶
Administrative contact for company-wide subscriptions and account-level administration. Use this address when registering the company as the admin contact for SaaS tools, business services, or vendor portals where you want ownership to survive individual turnover. Not for day-to-day operational questions — use operations@ for those.
aws-root@anvil.co¶
Root account contact for AWS. This address receives root-level AWS notifications including billing alerts, security alerts, and account recovery messages. Treat this address as sensitive — it is tied to the most privileged access in our cloud infrastructure. Do not subscribe this address to newsletters or non-AWS services.
billing@anvil.co¶
Accounts payable and finance operations. Vendor invoices, payment reminders, receipts, and finance-related correspondence should be directed here. Use this address when registering as the billing contact with any vendor so invoices route to finance/ops rather than an individual's inbox.
dev@anvil.co¶
Developer account root — the registered owner for developer-facing accounts and services (e.g., package registries, developer platform accounts, API provider accounts where an organizational identity is needed). Not the same as engineering@; this is for account ownership of developer tooling, not for engineering discussion.
engineering@anvil.co¶
Primary distribution list for the software and robotics engineering team. Use this for technical discussions, engineering announcements, code review broadcasts, incident coordination, and cross-functional pings that need engineering attention. Default address for anything where you'd otherwise DM several engineers individually.
everyone@anvil.co¶
All-hands distribution for company-wide announcements and newsletters. Reserved for information that is genuinely relevant to every employee: company updates, all-hands logistics, policy changes, milestone announcements. Do not reply-all to everyone@ unless your reply is also intended for the entire company.
info@anvil.co¶
Catch-all for generic external inquiries. Auto-forwards to support and is often the address listed on the public website's contact form. If an inbound message is actually a support request, a sales lead, or a press inquiry, it should be triaged to the appropriate destination rather than handled on info@.
operations@anvil.co (ops@anvil.co)¶
Day-to-day business operations, including procurement, vendor management, facilities, office logistics, and internal operational questions. Use this address for things like "we need to order X," "vendor Y is asking about Z," or "who owns the contract for W."
privacy@anvil.co¶
Privacy contact for data-subject requests, privacy-policy correspondence, and regulatory notices. This address is typically listed in the privacy policy and terms of service. Membership should be limited to the people actually responsible for handling privacy requests.
prod@anvil.co¶
Production resources contact. Registered as the owner for production infrastructure accounts, production monitoring services, and production-tier service contracts. Treat as sensitive — messages to this address often concern live customer-facing systems.
support@anvil.co¶
External customer support. This is a public-facing group: any external sender can email it. Use this address on customer-facing materials, signatures, and documentation. Incoming customer questions, bug reports, and escalations land here.
Membership Policy¶
Membership in each group is scoped to the people who actually need to receive or act on messages sent to that group. General principles:
- Least privilege. Add people to a group only when they need the traffic. Being on a group is not a status symbol — extra members dilute signal and create noise.
- Role-based, not person-based. When someone changes roles, membership should follow the role transition. Offboarding must include removal from all groups.
- Security-sensitive groups (
aws-root,admin,prod,privacy) have tighter membership. Additions require approval from the owner of the corresponding system or domain. - Public groups (
support) accept mail from outside the organization. Internal groups do not, by default.
Requesting Access or Changes¶
If you need to be added to a group, removed from one, or want to propose a new group:
- To join an existing group: ping the group's owner or ask in the appropriate internal channel. Include which group and why you need to be on it.
- To remove yourself: same process — self-service removal is generally fine unless the group is tied to a formal role.
- To create a new group: new groups should be proposed with (a) a clear purpose that isn't served by an existing group, (b) an initial membership list, (c) an owner, and (d) whether the group needs to accept external mail. Avoid creating one-off groups for short-lived projects; use ad-hoc email threads instead.
Conventions¶
- Naming. Group names are lowercase, short, and describe either a function (
billing,support) or an account-ownership role (aws-root,prod,dev). Avoid team-specific acronyms. - External mail. Only
support@is configured to accept mail from outside the organization. If you expect a vendor or external party to email a group, verify it can receive external mail first, or usesupport@/info@as the external-facing entry point. - Aliases. Some groups have short aliases (e.g.,
ops@foroperations@). Either form routes to the same place. - Reply behavior. Default to replying to the sender, not the group, unless the whole group actually needs the reply.
Quick Reference¶
| Purpose | Group |
|---|---|
| I have an engineering question for the team | engineering@ |
| I have a vendor invoice to forward | billing@ |
| A customer is asking for help | support@ |
| I'm registering for a new SaaS subscription | admin@ |
| I need to announce something to the whole company | everyone@ |
| An external person is asking a generic question | info@ |
| I need to order something / vendor question | operations@ |
| Something about our AWS root account | aws-root@ |
| Privacy request or data-subject inquiry | privacy@ |
| Production infrastructure account correspondence | prod@ |
| Developer platform / registry account ownership | dev@ |