Contact-driver and trend analytics

Every support organization ends the month with a pile of closed tickets. Contact-driver reporting turns that pile into a ranked list of reasons customers made contact, with volume, direction of change, and the cost attached to each one. The audience is operations and product, not the queue.

A contact driver sits above a topic tag. Tags describe one ticket. A driver groups tags and clusters into a reason a business can act on, such as refill delays or insurance rejections. Consistent labels from fine-grained tagging across the corpus are the raw material, and platforms like SentiSum cluster closed conversations into candidate drivers.

The report answers three questions. What did customers contact the company about. What changed since the last period. What is new and has no name yet. The third question is the reason to run clustering instead of counting existing categories.

Closed tickets are the only population that works here. An open ticket has no outcome and often no final label. Reporting on the live queue mixes work in progress with finished work, and the mix shifts with staffing.

None of this diagnoses a product defect. A driver that grew is a demand signal. Whether it grew because of a bug, a price change, or a marketing campaign is a separate investigation.

Comparisons break when the measurement changes underneath them. Fix the reporting period, the ticket population, and the label version before publishing anything.

Choose the denominator on purpose. Raw ticket counts move with marketing spend and seasonality. Contacts per thousand active accounts, or per thousand orders, separates a real change in customer experience from a change in company size.

Freeze the label version with a date. When a driver is renamed or split, the old series stops and a new one starts unless the corpus is reprocessed. Record which version produced each period, and re-run history whenever the definitions move.

Decide the minimum volume for a driver to appear at all. Small counts swing wildly week to week and invite stories the data cannot support. Drivers below the floor stay in an appendix list rather than the main chart.

Agree on who receives the report before designing it. A weekly operations review wants driver movement and open questions. A quarterly leadership review wants a short list with money attached. Building one artifact for both audiences usually serves neither.

State what the system should do when a period is incomplete or a channel stopped syncing. It should report the gap and withhold the comparison. A silently short week looks like an improvement.

The interesting part of the report is the residual. Tickets that fit no existing driver either belong to a driver that does not exist yet or are noise. Reading them is the job.

Run clustering over the unlabeled remainder on a fixed cadence, weekly or every two weeks. Groups that appear twice in a row and keep growing are candidates. Groups that appear once and vanish were usually one campaign or one large account.

Every candidate needs a human-written name and definition before it enters the report. Machine-generated cluster names drift, and a driver that leadership will fund needs a sentence someone can defend.

Watch first-seen dates against known events. Releases, price changes, policy updates, and regional launches explain most new drivers. A driver whose first ticket predates the release it supposedly caused needs a different explanation.

Keep a written history of every driver that was retired. A name that disappears from the report raises questions later, and the answer is easier to give with a date and a reason recorded.

Emerging is not the same as urgent. A sharp, same-day surge is an incident, and that gets caught at arrival by matching new tickets to active incident waves. Trend reporting works on a slower clock.

Names and numbers here are hypothetical. A mail-order pharmacy ships maintenance medications to patients in eleven states. It opened a twelfth state in September. Support volume rose in October, which nobody found surprising.

Contacts per thousand shipments tell a different story than raw volume. Raw contacts rose by roughly a fifth. Per shipment, the rate held steady in the original eleven states and roughly doubled in the new one.

The driver breakdown for the new state is uneven. Three drivers account for most of it: prescription transfer status, insurance not on file, and delivery window questions. The first two were already named. The third grew out of a group of 210 unlabeled tickets that the weekly run flagged twice.

Reading forty of those tickets shows a specific pattern. Patients in the new state see a shipping estimate that ignores a state rule requiring an extra pharmacist review. The estimate runs two days optimistic on every first fill.

That finding splits into three destinations. The estimate logic goes to engineering as a defect package with linked patient tickets. The transfer-status volume goes to the help center, since no published article explains transfers, and drafting an article from a solved ticket covers it. The insurance driver goes to the onboarding team.

A rising driver often means rising demand for a product, not a worse experience. Pair every driver with its denominator on the same slide. A support leader who reports counts alone will be asked to explain a spike that is only growth.

Label changes masquerade as customer behavior. Splitting one driver into three makes the parent collapse and the children appear from nothing. Annotate the chart at the date the definition changed, every time.

One account can carry a driver. Thirty tickets from a single clinic ordering for many patients is not thirty patients with a problem. Report distinct accounts beside ticket volume so the shape of the number is visible.

Resolved does not mean gone. A driver keeps producing tickets for weeks after a fix ships, because customers already in flight still write in. Mark the fix date on the chart and read the slope after it, not the total.

Seasonality gets mistaken for a trend in the first year a report exists. Without a prior year to compare, a January rise looks like a problem. Say plainly when there is no comparison period rather than implying one.

Clusters built for reporting are not the same as clusters built for debugging. Grouping tickets that share one underlying defect is a tighter job with a different bar for membership.

Someone owns every driver in the report by name. That person answers what the driver means and which tickets sit inside it. An unowned driver survives one meeting and then gets ignored.

Before a slide leaves support, the analyst opens tickets and reads them. Ten per driver is enough to catch a mislabeled group. The quotes that come out of that reading do more in the meeting than the bar chart.

Access to the underlying tickets matters more than the chart. Anyone reading the report should be able to click a driver and see the conversations. Numbers that people cannot open stop being believed.

Recommendations stay with the humans who own the work. The report says the transfer-status driver doubled. Whether the answer is a help article, a staffing change, or a product fix is a decision with cost behind it.

Say what the report cannot see. Customers who gave up without contacting support leave no ticket. Contact drivers measure the people who wrote in, and the analyst repeats that limit whenever the number is used to claim overall satisfaction.