Agree on a Naming Convention for Team Mailboxes

Start with the work the mailbox exists to do

Before choosing words, describe the mailbox’s stable purpose in one sentence: for example, “receives questions about product returns” or “handles requests for building access.” The wording should remain true if the current staff member leaves, a team lead changes, or the work is reassigned.

Prefer a function or service over a person’s name, job title, or temporary initiative. A mailbox named for an individual can become confusing when that person changes roles. A project label may age poorly once the project ends. If a mailbox is genuinely for a short-lived project, make its limited purpose clear and agree on what should happen when the work closes.

Set a pattern people can apply consistently

Choose a small set of conventions before creating more addresses. Decide whether names use a function alone, a function plus a team or location, or another compact structure. Keep the order consistent so colleagues can predict how a new mailbox will be named. Use familiar, plain words; avoid internal shorthand that new staff, partners or customers may not understand.

Keep names concise without making them cryptic. Two functions that sound similar may need a distinguishing term, such as “returns” versus “warranty,” if those duties are actually separate. Conversely, do not add a location, department or qualifier merely because it is available. Every extra element should help someone choose the right address or understand its purpose.

A team might choose the pattern: [function] or [function]-[location] when location genuinely changes who handles the work.
Examples: returns; facilities-north.
Avoid: alex; new-project; misc-team.

Check for overlap before approving a name

Compare a proposed name with the existing mailbox list and ask what a colleague would infer from each one. If two names appear to cover the same work, clarify whether they serve different audiences, queues or processes before adding another. If the distinction takes a long explanation, the names may need to be more explicit—or the team may need to reconsider whether both mailboxes are necessary.

Also check whether the name could imply a service or authority the mailbox does not provide. A label such as “billing” may suggest responsibility for invoices, payment questions, or both. Agree on the intended scope and describe it in the team’s internal documentation. A mailbox name is a useful signal, but it does not by itself define the team’s actual commitments.

Write down ownership as well as the naming rule

A convention works best when a team records who approves new names, who maintains the mailbox, and how staff should request a change. Keep the record brief and accessible to the people who administer or use the addresses. Include the mailbox’s purpose, intended audience, responsible role or team, and any important boundary—for instance, whether it handles incoming requests or also sends replies.

Describe responsibility by role where practical rather than tying it to one named employee. That makes the record easier to keep current, but it does not remove the need to assign real people to carry out the work. Check that someone is accountable for monitoring messages and arranging coverage, and that relevant colleagues know whom to contact when the mailbox’s purpose is unclear.

Know when a rename needs a wider review

A spelling correction or a clearer label for the same unchanged function may be a naming decision. A change from “returns” to “customer-care,” however, could signal a broader scope. Before approving a name that reflects changed work, ask whether the audience, kinds of requests, sending authority, coverage, escalation route or responsible team will also change.

If any answer is yes or uncertain, review those responsibilities separately. Confirm who may access the mailbox, who responds, what falls outside its remit, and where messages should go when they need another team. Do not assume that renaming an address automatically changes its access, routing, permissions or operating process. Those details depend on the organization’s setup and should be checked by the people authorized to administer it.

Make the change, then verify the result

Use a short approval checklist: Does the name describe enduring work? Is it distinct from existing names? Can a new colleague understand it? Is the responsible team recorded? Does the proposed wording reveal a change in scope or access that needs a separate review? Resolve uncertainty before communicating the new label.

After an authorized administrator makes an approved change, confirm the displayed name and address with the people who use the mailbox, and update the team’s documentation and relevant internal references. Check that users can still identify the mailbox’s purpose and know who handles its work. In BITTU Mail, workspace mailbox and domain administration is available to authorized admins, with controls depending on role, plan and provisioning state; confirm the actual setup in the workspace rather than assuming a naming change alters responsibilities.

If people interpret the new name differently, pause further changes and clarify the purpose and ownership. The convention is working when colleagues can select the right mailbox, explain what it handles, and identify who is responsible without relying on a particular employee’s name.