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.
| Signal | Expected owner | Fallback |
|---|---|---|
| Invoice or payment request | Account | Unassigned account queue |
| Confirmed product error | Technical support | Primary support inbox |
| Onboarding request | Customer success | Named 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
- Send one synthetic conversation for each positive routing condition.
- Send a conversation that matches no specialist rule and confirm it reaches the documented fallback.
- Create a message that could match two rules and record which active workflow wins.
- Reassign a test conversation between teams and verify notes, owner and state remain understandable.
- 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.