> For the complete documentation index, see [llms.txt](https://missiveapp.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://missiveapp.com/docs/setup-guides/client-facing-service-firms.md).

# For client-facing service firms

A single shared address for client mail works right up until the day nobody's sure who's answering.

## 1. Decide your structure first

This decision shapes everything else, so make it before you create a single team or rule.

A **team inbox** in Missive is a shared space where mail from a shared account arrives and waits until someone claims or assigns it. The question is what each team inbox should represent.

There are three common structures:

* **By client.** One team inbox per client. Best when you have a small number of high-touch, high-value retainer clients.
* **By service line.** One team inbox per service you offer, for example bookkeeping, tax, and payroll. Best when you serve many clients across a few defined services.
* **By department.** One team inbox per internal function, for example client services, business development, admin, and IT.

You can mix structures. A common pattern is department teams for the firm plus a handful of dedicated team inboxes for your largest clients.

See [Creating a team](/docs/core-features/team-inboxes/creating-a-team-space.md) to set these up.

## 2. Route client mail automatically

Most firms start with a single catch-all address like `clients@firm.com` where everything lands. That's fine. The work is moving mail out of the catch-all to the right place automatically.

You do this with **rules**: an instruction that runs when a message arrives and performs actions like moving it to a team inbox, assigning it, or labeling it. See [Rules](/docs/advanced-features/rules.md).

### Route by client list using contact books

A **contact book** is a set of contacts you can use inside rules. This is the most scalable way to route client mail, because onboarding a new client becomes a one-step update instead of a new rule.

Create a contact book for each group you want to route, for example "Bookkeeping clients" or "Pod 1 clients," and import your client list into it. See [Contacts](/docs/core-features/contacts.md). Create an incoming message rule with the condition **From** → **in contact book** → your client book, and the action **Move to team inbox** → the matching team. When you take on a new client, add them to the contact book. The rule keeps working unchanged.

Contact conditions also include **not in contact book**, which is how you exclude senders (covered below).

### Route by domain or keyword

For clients or services you can identify by sender or subject, route directly:

* **By domain:** condition **From** → **ends with** → `@clientco.com`, action **Move to team inbox**.
* **By keyword:** condition **Subject** or **Text** contains a keyword like "proposal" or "discovery," action **Assign** to the right person or **Move to team inbox**.

Each condition matches a single value, so to catch several keywords, add one condition per keyword and set the group to **At least one condition must match**. See [Conditions](/docs/advanced-features/rules/conditions.md).

### Keep internal and personal mail out of client routing

To stop banking, internal, or personal mail from being treated as client mail, add a condition group set to **None of the conditions must match**, listing the senders or domains to exclude. Conditions can be nested into groups. See [Complex rules](/docs/advanced-features/rules/examples/complex-rules.md).

### Use AI rules for contextual triggers

When you need to sort by what a message is actually about rather than by sender or keyword, use an AI rule. Add a single **Add label(s) with AI** action and give it the list of categories to choose from, for example "Categorize: client request, invoice, software notification, newsletter." One AI evaluation picks from the whole list, so you don't need a separate rule per label.

{% hint style="info" %}
To keep AI cost down, filter with standard conditions first and apply AI only to the messages that need it. AI rules require the Productive or Business plan plus a connected AI provider. With your own provider key, Missive adds no markup on AI usage.
{% endhint %}

See [AI rules](/docs/advanced-features/rules/ai-rules.md) and the [Automation examples](/docs/advanced-features/rules/examples/automation.md).

## 3. Make ownership clear

Once mail is routed, the next step is giving each conversation an obvious owner so nothing is dropped.

### Team inbox triage

A team inbox is a shared queue. When a conversation there is assigned, archived, or closed, it's removed from the team inbox for everyone, so acting on a conversation clears it for the whole team. See [Triage and assignment](/docs/core-features/triage-and-assignment.md).

### Three ways to involve a teammate

These aren't interchangeable, and picking the right one prevents most "I didn't see it" problems:

* **Assign** the conversation to give it a clear owner. It moves to the assignee's Inbox and appears in their **Tasks view** (the list of everything assigned to them). Assigning also makes that person start **watching** the conversation, so they see every new reply. Use assignment for anything someone needs to act on.
* **Add someone to a conversation** for visibility without making it their task. You can choose whether it shows in their Inbox or is just available for reference.
* **@mention** someone in an internal comment to pull them in. This always shows the conversation in their Inbox.

See [Collaboration](/docs/core-features/conversations/collaboration.md).

### Members vs. observers

Each person on a team is either an **active member** (notified of new messages) or an **observer** (access without notifications). We recommend making partners and senior managers observers on client-service teams, so they can monitor the work and step in without being flooded by every incoming message. See [Creating a team](/docs/core-features/team-inboxes/creating-a-team-space.md) for the full comparison.

### Give a contractor access to one client, not everything

If a contractor only works one or two clients, route those clients into their own team inbox and add the contractor to that team. They get exactly the mail they need without access to your whole catch-all, which may contain sensitive mail for other clients.

## 4. Know what has been handled

Teams coming from a single shared mailbox worry that cleaning up an inbox will hide or delete mail for everyone. It won't: **archive** keeps a conversation searchable in the **All mailbox**, **close** marks assigned work done and reopens on a new reply, and only **trash** removes it for everyone. See [What's the difference between archive, close, and trash?](/docs/core-features/conversations/faq.md) for the full comparison.

For a client firm we recommend **assign then close**: assign a conversation to give it an owner, then close it when the work is done. This keeps team inboxes clean and gives you an accurate count of outstanding work.

### From universal to individual unread/read states

Each user has their own read and unread state, so a shared inbox can look permanently unread. That's by design: read status is tracked per person, not per message.

Triage by assigning and closing, not by marking as read. You can still see which teammates have read a conversation from their avatars at the top. See [Conversations FAQ](/docs/core-features/conversations/faq.md).

## 5. Send as the firm, not as yourself

Client-facing firms usually want outbound mail to come from the firm or the right service line, not from an individual's personal address. Two features cover this:

Use a **shared address** ([Sharing options](/docs/core-features/connected-accounts/sharing-options.md)) when mail to one address like `clients@firm.com` should be worked by several people while you control who sees what. Use an **alias** ([Setting up aliases](/docs/core-features/aliases-and-signatures/setting-up-aliases.md)) for an extra sending identity on an account, like `bookkeeping@firm.com` or `tax@firm.com`, shared with colleagues so they can send from it without access to the underlying mail.

Each alias can carry its own name and signature, so a reply from `tax@firm.com` can look different from one sent from `bookkeeping@firm.com` even though the same person sent both. See [Aliases & signatures](/docs/core-features/aliases-and-signatures.md).

{% hint style="info" %}
This also supports a draft-and-review workflow: a junior team member drafts a reply from a shared address, and a senior reviews it before it sends.
{% endhint %}

## 6. Stay on top of response times

Firms with client commitments usually want a safety net so nothing sits too long.

Create an incoming message rule with the condition **Unreplied and open after** a time window, and the action **Notify**, pointing at a practice manager or team lead. For escalating alerts, create several rules with different thresholds, for example 1 hour, 4 hours, and 1 business day.

You can measure these windows in business hours rather than calendar hours, so the timer only counts during your working hours and skips nights, weekends, and holidays. See [SLA and response time](/docs/advanced-features/rules/examples/sla-and-response-time.md) and the ready-made [Basic Service Level Agreement](/docs/advanced-features/rules/templates/sla-basic-templates.md) template.

To see how the team is doing, open [Analytics](/docs/advanced-features/analytics.md) from your avatar in the bottom-left corner. It shows response times, conversation volume, and workload distribution. Analytics requires the Productive or Business plan, and filtering by team or user requires Business.

## 7. Filing and labels at scale

Two approaches help you find client mail later:

* **Team inboxes** separate live client work, as set up above.
* **Labels** tag conversations for searching and grouping across accounts. Organization labels are Missive-only and can be applied to any conversation, including non-email channels. See [Understanding label types](/docs/core-features/understanding-label-types.md).

At scale, a long global label list makes it easy to file mail under the wrong client. Keep the shared label set lean, name labels clearly, and use rules to apply labels automatically rather than asking people to pick from a long list.

Labels also bridge to other tools. A rule can apply a label, and an automation platform can watch for that label to forward invoices into your accounting or bookkeeping system.

## 8. Control and compliance for legal and financial firms

Firms with regulatory or confidentiality requirements often need more control over outbound mail and access. The building blocks:

* **Restrict who sends from a shared address** by sharing the alias only with approved senders, so others can see mail but not send as the firm. See [Setting up aliases](/docs/core-features/aliases-and-signatures/setting-up-aliases.md).
* **Keep confidential mail to one person** by assigning it to a single owner and not adding others.
* **Block sends without required attachments** using an outgoing message rule, for example to make sure an engagement letter is attached before a reply goes out. See [Rules](/docs/advanced-features/rules.md).
* **Save threads and attachments for the client file** when you need a record outside Missive.

## 9. Rolling out to your team

Most firms here are switching from Outlook, Gmail, Front, Hiver, or Spark. Follow the general playbook in [Migrating to Missive](/docs/migration/migrating-to-missive.md) (pilot, sandbox week, then a single cutover), plus a few things specific to client firms:

* **Phase the client-service teams last.** Start with a pilot group such as IT, business development, and admin, then bring on the client-service teams last because they're the largest and most complex. A full rollout commonly takes around 90 days.
* **Give one person config ownership.** A single implementation lead owns all teams, rules, and automations, and onboards each new client by adding them to the right contact book.
* **Make partners observers,** so leadership can monitor without notification overload.
* **Pre-configure new hires.** Set up a new team member's sidebar before their first day so they start oriented.
* **Clean up the backlog.** For Gmail accounts, see [Mass-archive Gmail emails](/docs/support/mass-archive-gmail-emails.md).

## Client-facing service firms FAQ

### A client keeps emailing one person's address instead of our shared inbox. How do I route those in?

The catch is that **organization rules only fire on conversations already shared with the organization**, so a rule built to reroute mail from a privately connected personal account silently never runs. Two fixes. Build the routing rule as a **personal rule** on that person's account (you can build it once, click **•••** → **Export**, and have each person **Import** it), or add the address as a **shared address** (**Settings** → **Accounts** → **Add** → **Shared address**) so the mail is linked to the organization and organization rules apply. Keep internal HR, payroll, and personal mail out of any shared routing by scoping the rule or leaving those threads private.

### Should each client be its own organization, or just a team?

A **team** (or one team per client) is right when your staff collaborate across clients and clients don't need to be walled off from each other. That's the default for most firms. Use a **separate organization per client** only when clients must never see one another's mail, or when you operate as an outside provider for independent businesses. Everyone in the same organization can be given visibility into its shared conversations, so a separate organization is the only complete boundary between clients.

### Can I reuse my rules from one client to another?

Yes. Open the rule, click **•••** and choose **Export**, then create a new rule and click **Import** in the rule editor. Change the client-specific condition (the domain, contact book, or address) and you're done. One caveat: rules that reference labels won't carry the labels over, since labels are organization-specific, so recreate those.

## Next steps

* [Creating a team](/docs/core-features/team-inboxes/creating-a-team-space.md) and [Triage and assignment](/docs/core-features/triage-and-assignment.md)
* [Rules](/docs/advanced-features/rules.md) and [AI rules](/docs/advanced-features/rules/ai-rules.md) for routing
* [Sharing options](/docs/core-features/connected-accounts/sharing-options.md) and [Setting up aliases](/docs/core-features/aliases-and-signatures/setting-up-aliases.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://missiveapp.com/docs/setup-guides/client-facing-service-firms.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.