# Sharing one mailroom across a distributed team > How distributed teams can share a single virtual mailroom without chaos — roles and permissions, routing rules by sender or category, assignment and SLAs, an audit trail of who acted on what, Slack and email notifications, multiple business entities under one account, and clean onboarding and offboarding. Canonical URL: https://mailnow.ai/articles/distributed-team-shared-mailroom When a team is in one office, the mailroom is whoever happens to be standing closest to the bin. Somebody opens the envelopes, walks the bills to accounting, drops the legal notices on the founder's desk, and shreds the rest. It's chaotic but it works because everyone is in the same room. The moment that team is distributed across cities, time zones, or continents, that informal system breaks down — and the mail starts piling up in a shared inbox nobody owns. This article is a practical guide to running a single virtual mailroom for a distributed team without the chaos: who can do what, how mail finds the right person automatically, how you measure that nothing is rotting, and how you keep a clean record of who acted on what. Everything below is how mailnow.ai is designed to work for shared accounts. The principles apply to any mature digital mailroom, but the specific knobs and defaults are ours. ## Roles and permissions: don't give everyone the keys The single biggest source of distributed-team mailroom chaos is giving every teammate the same level of access. Five admins on a single account is a recipe for accidental shred actions, deleted notices, and finance staff seeing personal letters they shouldn't. A shared mailroom needs a small role hierarchy and a default of least privilege. We model four roles and recommend you use all four. Owners can change billing, add or remove members, and delete the workspace; there should usually be one or two of these. Admins can manage routing rules, assignments, integrations, and other members but cannot change billing; this is the right level for an operations lead or office manager. Members can act on mail items in categories they're assigned to — open, forward, deposit, shred, comment — but can't change rules or invite people. Reviewers are read-only; they can see scans and summaries but can't take action, which is the right level for an outside accountant, lawyer, or contractor who needs visibility but shouldn't change anything. - Owner — billing, workspace deletion, member management. One or two people, usually the founders. - Admin — routing rules, assignments, integrations, member management. Operations lead or office manager. - Member — act on mail in their assigned categories. Most of your team lives here. - Reviewer — read-only access, scoped by category if needed. Outside accountants, lawyers, contractors. > **A category is a permission boundary, not just a label** — When you scope a member to the 'Finance' category, they only see scans and act on items routed there. HR letters, founder personal mail, and legal correspondence stay invisible. This is what makes a single account safe to share with a bookkeeper or a virtual assistant. ## Routing rules: get every item to its owner automatically Routing rules are the difference between a mailroom that runs itself and a mailroom that needs a human triager every day. The goal is for 80%+ of incoming mail to land in the right category, assigned to the right teammate, before any human looks at it. The remaining 20% — ambiguous items, new senders, things that span categories — gets human triage by whoever has the Triage role that week. There are three useful rule types and they compose. Sender-based rules match on the company on the envelope: anything from your bank goes to Finance, anything from the IRS goes to Compliance, anything from your law firm goes to Legal. Category-based rules use what the AI extracted from the contents: any item classified as 'Check' goes to the deposits queue, anything classified as 'Government Notice' is flagged time-sensitive and routed to Compliance, anything classified as 'Marketing' goes straight to archive. Recipient-based rules match the addressee line: mail addressed to Sarah goes to Sarah, mail addressed to the company default goes to the shared queue. - Sender-based — 'From: Stripe, Inc.' → Finance category, assigned to bookkeeper. - Sender-based — 'From: IRS' or 'From: Department of Revenue' → Compliance, time-sensitive flag, assigned to founder. - Category-based — AI classification 'Check' → Deposits queue, no assignee (next-available picks it up). - Category-based — AI classification 'Marketing' → Archive immediately, no notification. - Recipient-based — 'Attn: Sarah Chen' → personal queue, only Sarah sees it. Rules run in order, top to bottom, with the first match winning. Put your most specific rules first (a single sender) and your broadest rules last (a fallback that routes anything unmatched to a Triage queue). The Triage queue should never be empty for long — if it is, your rules are too loose; if it's overflowing, your rules are too tight or you're missing a category. ## Assignment and SLAs: making sure nothing rots Routing decides what category an item belongs to. Assignment decides which human owns it next. The two are related but separate, and both matter: an item with a category but no assignee is still nobody's problem in particular. The simplest model that works for distributed teams has three assignment patterns. Direct assignment names a specific person up front — appropriate when one teammate clearly owns a sender or category (the bookkeeper owns Finance, the founder owns IRS letters). Round-robin assignment cycles through a group — appropriate for queues like Deposits or Triage where any of several people can act and you want even load. Self-serve assignment leaves items unassigned in a shared queue, and whoever picks one up owns it from that point forward; this works for low-volume catch-all queues where naming a default would create artificial bottlenecks. Layer SLAs on top of assignment. Every category should have a target time-to-first-action — the moment somebody opens the item, comments on it, forwards it, or marks it handled. Reasonable defaults: 24 hours for normal mail, 4 business hours for time-sensitive flagged items (IRS, courts, banks), and same-day for checks awaiting deposit. When an item is approaching its SLA, the assignee gets a personal nudge; when it breaches, an admin gets a notification too. The point isn't to punish anyone — it's to make 'I forgot' visible before it becomes 'we missed the deadline.' > **Don't set a 1-hour SLA on routine mail** — Aggressive SLAs feel productive in the planning meeting and burn out the team in week three. Reserve fast SLAs for the small set of categories where speed actually matters (government notices, checks, anything time-sensitive) and let the rest run on a comfortable 1-business-day clock. ## Audit trail: who did what, and when Every action on a mail item should be logged, attributed to a specific user, and impossible to delete. This is what lets you answer the only two questions that matter when something goes wrong: who saw this, and what did they decide? Forwarded, shredded, archived, deposited, commented on, downloaded — every one of these creates a line in the item's history with the user, the action, the timestamp, and any note attached. The audit trail also gives you defensible records when an outside party (a regulator, an auditor, a court) asks what your company did with a piece of mail. 'On March 14 at 9:42am Eastern, the IRS CP2000 notice was opened by Sarah, forwarded to outside counsel at 10:15am, and the original was forwarded to the company's tax attorney by USPS Priority Mail with tracking #...' is a much stronger answer than 'I think we sent it to our lawyer.' ## Notifications: Slack, email, and not too many of either The biggest mistake distributed teams make with shared mailrooms is wiring up a 'new mail' Slack channel that pings every time anything arrives. Within a week, everyone mutes the channel and you've made the situation worse than email — at least email gets read. Notifications need to be scoped, throttled, and meaningful. We recommend three notification streams per workspace, and almost never more. The first is a low-volume #mail-urgent Slack channel that fires only when an item is flagged time-sensitive (government, legal, bank, or anything matching a saved 'urgent' rule). This channel should average a few messages per week, not per day, so the team trusts it. The second is per-user direct notifications: when an item is assigned to you, you get a Slack DM and an email with a one-line summary and a link. The third is a weekly digest sent to admins with the count of items handled, items pending, and any SLA breaches — useful for catching trends without daily noise. - #mail-urgent Slack channel — only time-sensitive items, a few per week. - Per-user DM and email — when an item is assigned to you, with a one-line summary. - Weekly admin digest — counts, breaches, and trends. - Skip: a 'new mail' firehose channel. Skip: per-item email to the whole team. ## Multiple business entities under one account Many distributed teams run more than one entity — a US C-corp for the operating business, an LLC for IP holding, a separate entity for a side product, a personal mailbox the founder also wants to consolidate. A shared mailroom should support multiple entities cleanly, with separate mailing addresses but a single login, billing relationship, and team list. Each entity gets its own real US street address (with a unique suite or unit number), its own Form 1583 on file, its own routing rules, and its own categories — all under the same workspace. Members can be scoped per-entity if you want; for example, the IP-holding LLC's mail might only be visible to the founders and outside counsel, while the operating company's mail is visible to the whole ops team. Billing rolls up to a single invoice with a per-entity line item, which keeps your accounts payable simple. > **Don't pile entities into the same address** — Putting two LLCs at the same suite number to save a few dollars a month creates real legal headaches — pierced corporate veil arguments, confused USPS deliveries, ambiguous registered-agent service. Each entity should get its own distinct address line. The savings of merging them are not worth the downstream cost. ## Onboarding and offboarding teammates Distributed teams change shape constantly: someone joins, someone leaves, a contractor's engagement ends, an outside firm rotates the partner assigned to your account. Every one of these transitions is a chance for either an access leak (the offboarded person still has the password to your shared mail account) or a coverage gap (nobody picks up the categories they used to own). A shared mailroom needs both onboarding and offboarding to be a single, deliberate action. Onboarding a new teammate looks like this: an admin invites them by email, picks their role (Member, Reviewer, etc.), scopes them to specific categories, and optionally adds them to round-robin assignment groups. They receive an email, set a password, enable two-factor authentication, and they're in. If their role is 'bookkeeper for finance,' they see exactly the Finance category and nothing else. Offboarding is the symmetrical action and it's the one teams forget. When somebody leaves, an admin removes them from the workspace; their session is invalidated immediately, their assignments are reassigned (round-robin queues redistribute automatically; direct assignments need a one-time bulk reassign), and their audit trail entries remain in place — you don't want history to disappear when a user does. Reviewers and contractors should be on a calendar reminder: 'review at end of engagement' for outside firms, 'review quarterly' for any access that should be temporary. 1. On day 1: invite, role, category scope, 2FA enrolled. Welcome message points at the categories they own. 2. On day 30: review whether the assignments make sense, adjust SLAs if they're too tight or too loose. 3. Quarterly: audit the user list. Anyone who hasn't logged in for 90 days probably shouldn't have access. 4. On the way out: remove from workspace same day, reassign their queues, document the handoff in the audit log. ## A sample team setup Here's how a real eight-person distributed startup might configure a shared mailnow.ai workspace. The company is a US Delaware C-corp with a separate Wyoming LLC for IP holding. The team is split across San Francisco, Lisbon, and Bangalore, with an outside accountant in Austin and outside counsel in New York. - Owners (2): the two co-founders. Manage billing and the workspace itself. - Admins (1): the head of operations in Lisbon. Owns routing rules, member management, integrations. - Members (3): bookkeeper (Finance category), people-ops lead (HR category), and the head of operations (everything except HR and Personal). - Reviewers (2): the outside accountant (Finance, read-only) and outside counsel (Legal + Compliance, read-only). - Routing rules: ~25 sender-based rules covering banks, processors, the IRS, three state revenue departments, the law firm, the accountant, and major vendors. A handful of category-based rules (Check → Deposits, Marketing → Archive, Government Notice → Compliance + time-sensitive flag). One fallback rule sending unmatched items to Triage. - SLAs: 4 business hours on time-sensitive, same-day on checks, 1 business day on everything else. - Notifications: #mail-urgent in Slack (averages 3 pings/week), per-user DMs on assignment, Friday digest to admins. - Entities: the Delaware C-corp address routes everything described above. The Wyoming LLC address has its own minimal setup — only the two founders and outside counsel see it. The whole thing took the head of operations about three hours to configure on day one. After that, it runs on roughly fifteen minutes of attention per week — mostly clearing the Triage queue and sanity-checking the Friday digest. Mail volume can roughly double without changing the setup. ## Common mistakes to avoid - Making everyone an admin 'so they don't get blocked.' This is how you get accidental shred actions and unhappy compliance reviews. - Setting up one giant 'Mail' Slack channel that pings on every item. It will be muted within a week. - Skipping the fallback Triage rule. Without it, items that don't match any rule sit in limbo with no owner. - Putting your accountant on the Owner role. Read-only Reviewer is almost always what you actually want. - Assuming offboarding 'happened' because the email account was deactivated. Workspace access is separate; remove it explicitly. - Combining two entities at the same address to save a few dollars. The legal and operational cost is much higher than the savings. ## Set up your shared mailroom in an afternoon A shared mailroom for a distributed team is mostly a configuration problem, not a tooling problem. Pick the right roles, write a small set of routing rules, add SLAs only where speed matters, wire two or three notification streams, and document the onboarding and offboarding ritual. Once it's in place, the system runs itself and the chaos you used to feel every time a piece of mail arrived simply goes away. mailnow.ai gives every teammate scoped access to the same digital mailroom, with full audit history and per-entity addresses, on the same flat monthly price — so you can get an entire distributed team's mail under control today and add the next teammate in a few minutes flat.