Key takeaways
- Intercom tickets have types and states; conversations are open or closed.
- A conversation can be converted into a ticket, which is also how a migration can create one.
- Decide before anything moves: it changes the mapping, the attributes and the reporting.
Tickets and conversations in Intercom
- Customer tickets: visible to the customer, who is kept up to date as the status changes.
- Back-office tickets: internal work raised from a conversation, owned by the team that has to do it.
- Tracker tickets: one ticket for a problem affecting many customers, with related conversations and tickets linked to it.
How old statuses map to ticket states
| Typical source status | Intercom ticket state |
|---|---|
| New | Submitted |
| Open, On hold | In progress |
| Pending | Waiting on customer |
| Solved | Resolved |
This is the mapping Intercom’s own Zendesk importer uses. In a written mapping every status is decided one by one, so yours can differ. Check in the sample run that resolved tickets arrive resolved, and that each field lands on the right object: a ticket attribute if you report on it per ticket, a contact or company attribute if per customer.
Which to choose
| Choose tickets if | Choose conversations if |
|---|---|
| Your team tracks work by status and SLA | Your team works chat-first and closes most queries quickly |
| You report by ticket type or category | You report by topic and conversation volume |
| Customers expect to follow a request’s progress | Customers rarely come back to an old request |
Either way, decide before the mapping is written. See the Freshdesk to Intercom migration guide for how every object maps on a real route.