Back to the guides

PRACTICAL SOFTWARE GUIDE

Intercom team inbox routing: define ownership before adding rules

Use team inboxes to make ownership visible, and test every routing branch before relying on it for customer conversations.

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

Give each inbox one accountable purpose

Intercom documents team inboxes as shared spaces that can receive assigned conversations, replies to outbound messages and conversations routed by assignment rules. Start by naming the customer need each inbox owns. “Billing questions” is testable; “General” is a catch-all that can conceal unclear responsibility.

Write a routing table before creating rules

For a fictional software company, define three teams: Account, Technical support and Customer success. Create synthetic messages such as “I need a copy of invoice 104,” “the export failed” and “help us onboard a second team.” For each message, record the expected inbox, priority and fallback if the preferred team is unavailable. Do not use real customer content in the initial test.

SignalExpected ownerFallback
Invoice or payment requestAccountUnassigned account queue
Confirmed product errorTechnical supportPrimary support inbox
Onboarding requestCustomer successNamed duty owner

This is an example decision table, not a statement about Intercom's default routing.

Separate team assignment from individual ownership

Intercom allows a conversation to be assigned to a team, where members can pick it up, or to a teammate. Decide which event establishes individual accountability. A conversation can be visible in the correct team inbox and still wait because no person owns the next response.

Test specificity and fallback

  1. Send one synthetic conversation for each positive routing condition.
  2. Send a conversation that matches no specialist rule and confirm it reaches the documented fallback.
  3. Create a message that could match two rules and record which active workflow wins.
  4. Reassign a test conversation between teams and verify notes, owner and state remain understandable.
  5. Close and reopen a test conversation to observe the assignment behavior configured for the workspace and teammate.

Make the handoff visible to operators

Use a short internal note or required field to explain why a specialist team received the conversation. Avoid copying credentials or sensitive customer data into a routing note. The receiving team should be able to see the customer outcome, the last completed action and the next decision.

Review exceptions, not just averages

Sample unassigned, reassigned and reopened conversations regularly. A high assignment count does not prove correct ownership. Look for conversations that repeatedly move between teams, remain assigned to inactive teammates or enter the fallback despite a clear specialist signal. Update one rule at a time and rerun the synthetic routing table.

Sources and verification

Official documentation checked on 2026-10-29. Worked examples are hypothetical planning exercises, not measured product benchmarks.

Continue your evaluation

Practical guides for this topic

Put your tools to work.

Need help choosing or setting up your tools? Tell Koldia what you want to improve.

Discuss your project