> 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/dispatch-and-logistics.md).

# For dispatch and logistics teams

In dispatch, a message that sits too long isn't just clutter, it can mean a detention or penalty fee.

## 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 queue where mail from a shared account or address arrives and waits until someone claims, assigns, archives, or closes it. The question is what each team inbox should represent.

Most dispatch and logistics operations organize team inboxes by function:

* **Customer service**, for quotes, bookings, and tracking questions from customers.
* **Dispatch or operations**, for coordinating active loads.
* **Carrier or capacity**, for sourcing and managing carriers.
* **Billing or accounting**, for invoices, rate confirmations, and AP and AR.

Two structural choices matter most:

* **Separate customer-facing from carrier-facing mail.** Keeping the customer team and the carrier team in their own team inboxes keeps the two sides of a load from blurring together, and it sets up the conversation linking in [section 6](#link-customer-and-carrier-threads).
* **Split by lane, region, or operator team only when you need to.** Larger operations sometimes run several operator pods or regional teams. Add that layer when a single team is too big for one team to watch, not before. Over-splitting creates more places to look and more routing to maintain.

You can mix structures. A common pattern is a small set of function teams for the whole operation, plus a dedicated team inbox for one high-volume account or lane.

See [Team inboxes](/docs/core-features/team-inboxes.md) to set these up.

## 2. Connect your inboxes

Dispatch teams usually arrive on Outlook distribution lists or a shared Gmail address. Connect it correctly before you build any rules on top.

How you connect depends on what you have:

* **Google Group address.** A Google Group, for example `dispatch@acme.com`, can be added to Missive and used as a team inbox directly. See [Google Group address](/docs/core-features/connected-accounts/email-accounts/gmail-google-workspace/google-group-address.md).
* **Microsoft 365 distribution list.** A Microsoft 365 distribution list can't be connected directly, because it forwards mail to recipients' personal inboxes rather than holding it in one place. Use Missive's **shared address** feature instead: go to **Settings** → **Accounts**, click **Add**, and choose **Shared address** under the **Email** tab. The setup matches the Google Group process. See [Outlook / Office 365](/docs/core-features/connected-accounts/email-accounts/outlook-office-365.md). If you'd rather move off the distribution list entirely, convert it to a shared mailbox in Microsoft 365 first, then connect that.
* **Office 365 shared mailbox.** Add it from **Settings** → **Accounts**, choose **Office 365**, and sign in with an account that has access to the shared mailbox. See [Outlook / Office 365](/docs/core-features/connected-accounts/email-accounts/outlook-office-365.md).
* **Personal accounts.** Coordinators connect their own work accounts and share them with the organization so their mail counts in analytics and can be routed. See [Sharing options](/docs/core-features/connected-accounts/sharing-options.md).

A **shared address** ([Sharing options](/docs/core-features/connected-accounts/sharing-options.md)) is one address like `dispatch@acme.com` that several people send from and receive at, while you control who sees what. An **alias** ([Setting up aliases](/docs/core-features/aliases-and-signatures/setting-up-aliases.md)) is an extra sending identity on an account, like `loads@acme.com` or `carriers@acme.com`. Share an alias so coordinators can send as the team without exposing a personal address, and give each alias its own name and signature.

## 3. Route incoming email automatically

With the inboxes connected, route each message to the team inbox automatically. A **rule** runs when a message arrives and performs actions like moving it to a team inbox, assigning it, or labeling it. Rules require the Productive or Business plan. See [Rules](/docs/advanced-features/rules.md).

Route by address, domain, or keyword:

| Rule type | Incoming message              |
| --------- | ----------------------------- |
| Condition | To is → `dispatch@acme.com`   |
| Action    | Move to team inbox → Dispatch |

| Rule type | Incoming message                 |
| --------- | -------------------------------- |
| Condition | From ends with → `@brokerco.com` |
| Action    | Move to team inbox → Carrier     |

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

Three points decide whether routing holds up at volume:

* **Scope keyword conditions so old text doesn't re-trigger them.** The **Message content** and **Message body** conditions search the whole thread, including quoted replies, so a reference or PO number mentioned earlier in a long thread keeps matching long after it's relevant. Match on **Subject**, or on **Message body (without quote)**, when you route by reference numbers or shipment terms. See [Conditions](/docs/advanced-features/rules/conditions.md).
* **Incoming rules fire on arrival, not when someone drags a conversation.** If a coordinator manually moves a conversation to another team and you want something to happen, use a **Team changed** rule under **User actions**, not an incoming rule. See [Rule types](/docs/advanced-features/rules/rule-types.md).
* **Put every action in one rule rather than chaining them.** A user action rule only fires when a real person acts, not when another rule performs the action, so a rule that adds a label won't trip a second rule watching for that label. See [Rule types](/docs/advanced-features/rules/rule-types.md).

Rules run alphabetically by description. Prefix them with numbers to force an order, and add the **Stop processing more rules** action to a rule when nothing below it should run on the same message. See [Actions](/docs/advanced-features/rules/actions.md).

When you need to sort by what a message is actually about rather than by sender or keyword, for example to separate a real booking from an automated portal alert, use an AI prompt within a rule. Add a single **Add label(s) with AI** action and give it the list of labels to choose from. Filter with standard conditions first and apply AI only to the messages that need it, to keep cost down. See [AI rules](/docs/advanced-features/rules/ai-rules.md).

{% hint style="info" %}
When the same email is sent to two teams at once, for example a customer who copies both customer service and dispatch, Missive by default creates a separate conversation in each team inbox and adds a note linking them so you can merge them. If you'd rather have one conversation land in a single team inbox, change the setting under **Settings** → **Organization**, in the **Email sent to multiple teams** options. See [Organization settings](/docs/administration/organization-settings.md).
{% endhint %}

## 4. Decide how a team owns work

Routing gets a message to the right team inbox. The next decision is whether messages to that team get assigned a single owner or stay unassigned, in a shared queue. The two models aren't interchangeable.

* **Assign for ownership (recommended).** Assigning a conversation gives it a clear owner: it appears at the top of the assignee's Inbox and in their **Tasks view**, and assigning makes that person **watch** the conversation so they see every reply. Use this for work that needs to stay with one person, like a problem shipment or a claim. See [Triage and assignment](/docs/core-features/triage-and-assignment.md).
* **Shared queue, no individual owner.** Anyone on the team can pick up the next message, work it, and clear it with **Send & archive** (Archive removes it from the team inbox for the whole team). This can fit high-volume teams like customer service where the next available coordinator takes whatever is next. The downside is that analytics won't be as useful, since it tracks reply time from the moment of assignment.

To assign automatically as coordinators reply, so whoever answers first becomes the owner:

| Rule type | Outgoing message                       |
| --------- | -------------------------------------- |
| Condition | Email account is → `dispatch@acme.com` |
| Action    | Assign sender                          |

To spread incoming load across a team instead, use an **Assign** action set to **In turn** for round-robin or **Least busy first**, which assigns whoever has the fewest open conversations. Coordinators marked out of office are skipped automatically. See [Workload balancing](/docs/advanced-features/rules/workload-balancing.md).

Two more settings matter for a busy team:

* **Members and observers.** Each person on a team is an **active member** (notified of new messages) or an **observer** (access without notifications). We recommend making dispatch managers and owners observers on the teams they oversee, so they can watch the work and step in without being flooded. See [Team inboxes](/docs/core-features/team-inboxes.md).
* **Out of office.** When a coordinator sets **Out of Office**, replies on conversations assigned to them move back to the team inbox automatically, so a load never sits in an away person's queue. See [Status and out of office](/docs/core-features/status-and-out-of-office.md).

## 5. Bring driver and broker texting into the same inbox

Drivers and brokers often communicate by text, and texting from personal phones is invisible to the rest of the team. Missive can hold a shared phone number as a team inbox channel, so texts sit beside email and anyone on the team can see and answer them.

Connect a number through **Twilio**, **SignalWire**, or **Dialpad** and add it to the relevant team. All three let you rent a new number or port an existing one, and Dialpad carries voice and SMS together. Missive can't connect a regular carrier mobile number, so you provision a number through one of these providers. See [SMS](/docs/core-features/connected-accounts/other-channels/sms.md).

Because the number is a team inbox, the same routing, assignment, and out-of-office behavior applies to texts.

## 6. Link customer and carrier threads

The two sides of a load usually arrive as separate conversations: the customer thread and the carrier thread. Connecting them saves coordinators from searching back and forth.

* **Paste a link to one conversation into the other.** Right-click a conversation and choose **Copy link**, then paste it into a comment on the related conversation. A snippet appears, and anyone with access can jump to it in one click. This keeps the customer and carrier threads separate while cross-referencing them. See [Conversations FAQ](/docs/core-features/conversations/faq.md).
* **Merge them when they're truly one thing.** Merging combines two conversations into one, carrying over all messages, comments, labels, and assignees. Use this when a customer and carrier really belong in a single thread, not when you just want a pointer between them. See [Merging](/docs/core-features/conversations/merging.md).

## 7. Know what has been handled

Teams coming from a 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** (and from a team inbox clears it for the whole team), **close** marks assigned work done and reopens on a new reply, and only **trash** removes it for everyone, with a confirmation first. See [What's the difference between archive, close, and trash?](/docs/core-features/conversations/faq.md) for the full comparison.

For a shared queue with no individual owner, work from the team inbox and use **Send & archive**. For work you assign, use **assign then close**.

{% hint style="info" %}
Each person has their own read and unread state, so a busy team can look permanently unread. That's by design: triage by assigning, archiving, and closing, not by chasing unread counts.
{% endhint %}

## 8. Stay on top of response times

Missed messages can mean detention or penalty fees, so build a safety net.

Create an incoming message rule with the condition **Unreplied and open after** a time window and the action **Notify**, pointing at a dispatch lead. For escalating alerts, create several rules at different thresholds, for example 1 hour, 4 hours, and 1 business day. You can measure these windows in business hours so the timer skips nights and weekends. A ready-made [Basic Service Level Agreement](/docs/advanced-features/rules/templates/sla-basic-templates.md) template adds an SLA label and a breach note you can pin to the sidebar for visibility. See [SLA and response time](/docs/advanced-features/rules/examples/sla-and-response-time.md).

To see how the teams are actually doing, open [Analytics](/docs/advanced-features/analytics.md) from your avatar in the bottom-left corner. It shows first reply time, conversation volume, and workload across coordinators. Analytics requires the Productive or Business plan, and filtering by team or user requires Business.

## 9. Rolling it out

Most teams here are switching from Outlook distribution lists, a shared Gmail inbox, or Front. 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 dispatch:

* **Plan the connection method first.** If you're moving off Outlook distribution lists, sort out the connection from [section 2](#connect-your-inboxes) before anything else, since it's the step most likely to trip up a dispatch migration.
* **Set the duplicate behavior before go-live.** Decide up front whether a message sent to two teams should appear in both or land in one, so coordinators aren't merging duplicates from day one. See [section 3](#route-incoming-email-automatically).
* **Clear the backlog.** A large legacy inbox, or a history import that floods a team with old mail, is fine to bulk-archive from **Settings** → **Accounts**. Everything stays searchable in the **All mailbox**, and the flood doesn't slow normal operations.
* **Give one person config ownership,** so adding a new lane or carrier list is a one-person job and configurations don't conflict.
* **Make managers observers,** so leadership can monitor the teams without notification overload.

## Dispatch and logistics FAQ

### We're moving off an Outlook distribution list. Why can't I just connect it?

A Microsoft 365 distribution list forwards each message to recipients' personal inboxes rather than holding mail in one place, so there's nothing for Missive to connect to. Bring it over one of two ways: add the address as a **shared address** (**Settings** → **Accounts** → **Add** → **Shared address**), or convert the distribution list to a **shared mailbox** in Microsoft 365 and connect that. The address stays the same, so customers and carriers notice nothing. A Google Group address, by contrast, connects directly as a team inbox. See [From Outlook](/docs/migration/from-outlook.md) for the full migration.

### Can I bring driver and broker texts into Missive from their cell numbers?

Not from a regular carrier mobile number directly. Missive holds a shared business number as a team inbox channel through **Twilio**, **SignalWire**, or **Dialpad** (Dialpad carries voice and SMS together); you rent a new number or port an existing one through one of those. Once connected, texts sit beside email on the team and follow the same routing, assignment, and out-of-office behavior. Your drivers and brokers don't need to change anything on their end.

## Next steps

* [Team inboxes](/docs/core-features/team-inboxes.md) and [Triage and assignment](/docs/core-features/triage-and-assignment.md)
* [Rules](/docs/advanced-features/rules.md), [Conditions](/docs/advanced-features/rules/conditions.md), and [Workload balancing](/docs/advanced-features/rules/workload-balancing.md)
* [SMS](/docs/core-features/connected-accounts/other-channels/sms.md) for driver and broker texting


---

# 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/dispatch-and-logistics.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.