HubSpot Support and Service Integrations
A support integration is bought so that whoever is speaking to a customer can see what that customer is currently unhappy about. That is a low bar and most estates do not clear it, because the ticket system and the CRM hold different identifiers for the same person.
The harder half is deciding what a ticket should cause. A support system that can only record is a filing cabinet; the value is in what happens when a ticket crosses a threshold.
8 systems in this category, 1 of them documented in a published case study.
What a ticket is allowed to trigger
Every alert has to name a consequence. An alert that fires into a channel nobody owns is noise, and noise trains the team to ignore the channel that also carries the alerts that matter.
The discipline is to route by consequence rather than by severity label. A ticket that puts a renewal at risk goes to whoever owns the renewal. A ticket that indicates a defect goes to whoever can fix it. Severity alone routes both to the same place.
Retirement is the part that is always missing. An alert nobody has acted on for a quarter is an alert that should be removed, and without a scheduled review the alert estate only ever grows.
Routing by what an alert should cause rather than by how it was labelled
The parts an alert needs before it can be acted on without a follow-up question
Systems in this category
Enterprise workflow kept where it belongs, with the commercial record joined to it rather than duplicated into it.
Ticket state visible on the account without two support queues.
Conversation history joined to the contact, with identity resolved first.
Service history read against the renewal it will influence.
Mailbox threads attached to the record they concern.
Agreements and tickets reconciled with the commercial record.
Contracts and time joined to the account they bill.
Incident history surfaced where the relationship is managed.
Documented engagements
Each of these is a published study of one build, with the object model, the decisions taken and what the approach does not establish.
Common Questions
Frequently Asked Questions
Wherever the people resolving them already work. Moving a support team into a CRM to satisfy a reporting preference reliably produces worse support and worse data. What the CRM needs is the state of the relationship, which is a count, a status and a link, not the ticket body.
On an identifier written by whichever system creates the record first, then carried by the other. Matching on email address alone fails on shared inboxes, role addresses and anyone who changes employer, and those are exactly the accounts worth getting right.
Something with a commercial consequence: a ticket open past an agreed threshold, a second ticket on the same issue, or any ticket on an account inside a renewal window. Volume alone is a poor trigger because it varies with how the customer uses the product.
Further reading
Long-form already published on the argument this category turns on.
Related categories
A system in this category that is not listed
The directory shows range rather than limits. A scoped build is quoted from the object model on each side and the fields that have to cross between them.