Intercom adds assignment-level reporting for ticket handoffs
Assignment-level reporting makes ticket journeys visible. Availability, counting rules and history limits matter when interpreting a support bottleneck.
What changed
Assignment-level reporting makes ticket journeys visible. Availability, counting rules and history limits matter when interpreting a support bottleneck.
Sources: Intercom official release · Intercom tickets lifecycle report
A ticket can retain its assignment journey
Intercom's 8 September announcement introduces a Ticket assignments dataset, a Tickets lifecycle report and a Sankey view of ticket movement. Instead of reporting only against the current assignment, the new view lets teams examine the visits a ticket made through the organization.
The operating opportunity is to investigate where work waits or repeatedly returns. A ticket ending with Billing may have accumulated delays in several places before arriving there. Seeing that path can improve a process review, but it does not by itself establish which team caused the delay or whether any particular transfer was unnecessary.
Availability and history have boundaries
The help documentation restricts the report to VBP plans and to tickets, not ordinary conversations without a ticket type. It says data starts when the workspace is enabled, so previously closed tickets do not acquire a complete historical journey. Confirm that start date before comparing periods or treating an empty report as evidence of no activity.
Make the observation window part of every internal readout. A newly enabled dataset may describe a partial period and a changing mix of open and completed work. Label it as such. Do not compare a short onboarding period with a mature historical report and describe the difference as a process improvement. Missing history is a measurement boundary, not a result.
Count visits, moves and tickets separately
Intercom distinguishes assignment visits from individual tickets, and its handoff count includes a change of teammate within the same team. A ticket can contribute several rows and several moves while still representing one customer issue. Choose the measure that answers the business question instead of using whichever total is most prominent.
A queue review may need to know how many distinct cases experienced any transfer. A routing review may need the total number of moves or repeated returns. A capacity review may need time held during particular visits. Present these measures separately. Combining them into one score can make a team with complex cases look worse simply because it handles more legitimate specialist work.
Read the diagram as a view, not the entire record
The Sankey displays up to eight reassignments and groups smaller teams outside the top six into an Other teams node. It is absent from snapshots, scheduled reports, external shares and exports, although other chart types remain available. Reviewers need those limits when sharing findings outside the interactive report.
For a consequential decision, select relevant cases and inspect their underlying records. A visually narrow path can still contain a difficult customer issue. A grouped node can conceal several different operating situations. Retain report filters and individual case references so a colleague can reproduce the review without relying on a screenshot or a visually memorable flow alone.
Investigate the reason for the transfer
Classify a sample of transfers before changing routing. Useful review categories include required expertise, missing intake information, incorrect initial ownership, approval dependency and a return for further customer evidence. Those categories are a proposed investigation method, not labels guaranteed by the new dataset.
Ask both the sending and receiving team what was available at the time. A reassignment may be the fastest responsible route to resolution when a specialist needs to act. Conversely, a ticket that never moves may be stuck with an owner who cannot resolve it. Neither fewer moves nor a shorter assignment duration is automatically a better customer outcome.
Pair timing with a customer outcome
Choose one process outcome for the review, such as a completed billing correction or a resolved implementation blocker. Define what evidence demonstrates completion and when the observation window closes. Keep waiting time, active handling time and customer response time distinct wherever the underlying records allow that distinction.
If a team changes its intake form or routing rule, retain a comparable pre-change cohort and document differences in case mix. A post-change decline in transfers may be useful evidence, but it is not causal proof on its own. The release provides no universal target for handoffs, resolution time or customer retention, and teams should not manufacture one from a convenient chart.
A practical first review
Start with one repeatable ticket type and two teams that exchange it. Review a manageable sample together, identify the information or authority missing at the handoff, and change one part of the intake or acceptance process. Revisit the same defined measure after a normal operating cycle, including unresolved cases and exceptions.
Intercom has made the assignment path more visible. The highest-value use is a focused operational investigation with traceable cases and a testable change. Avoid turning the first report into a league table of teams. The work is to explain the journey and improve it, not to assign blame to whichever team happens to hold the final row.
Original source
This DailyRevOps article is written in our own words from the source signal and adds RevOps context, workflow analysis, and operator interpretation.
- Original source: Intercom
- Original publication date:
- Source link: Read the original article