---
id: casos/analise-de-suporte
area: AI
usage: common
effort: medium
grain: 1 row per ticket or conversation with the full transcript; 1 row per message for the timeline
---

# AI support analytics

Tickets, chats and WhatsApp linked to the paying customer and classified by AI into reason, intent and sentiment, always with the excerpt that proves it.

## Executive summary

**For:** Support, CS and product teams that receive thousands of messages a month and set priorities by whatever sounds loudest.

**What it solves**

- Every ticket is linked to a paying customer, with reason, sentiment and the excerpt that proves the classification.
- Topics are ranked by affected customers, revenue and recurrence, not just by volume.
- Cancellation and downgrade requests made in support reach CS the same day.

**Why it matters:** Support is where customers say, in their own words, what is broken and why they are thinking of leaving. Without linking the ticket to the customer and without a closed list of reasons, the AI returns a word cloud and product keeps prioritizing whoever complains most. With quoted evidence, the classification is auditable and the team starts trusting the ranking.

**Business questions it answers**

- Which contact reasons grew the most this month and which customers do they affect?
- Which paying customers opened the same problem more than once in 30 days?
- Who asked to cancel or downgrade in support this week, and is it leaving or a plan adjustment?
- What is the median first response time per queue, counting from the customer's first message?
- How many conversations did the bot resolve without handing off to a person?
- Which topic has the most negative sentiment among the highest-paying customers?

**What you need**

- Support tool or WhatsApp connected to Nekt, with the conversation text
- A closed list of reasons agreed between support, CS and product
- A single customer across support, CRM and billing

**What you get**

- A per-ticket table with customer, timings, reason, sentiment and evidence
- A ranking of topics by affected customers, revenue and recurrence
- An exit-request alert for CS
- An AI agent that builds the account's support history

## Detailed

### The problem

Tickets arrive without a company, with the category empty in most cases, with the waiting time starting after the customer was already waiting, and with emails that repeat the whole conversation in every reply. Sending that straight to an AI returns generic topics, inflated sentiment and no link to revenue. The final ranking rewards the noisiest topic, not the one that most affects paying customers.

### Business rules

1. **Every ticket linked to a customer, or marked as no customer.** Resolve the company in a cascade: the ticket's own association, then the contact's, then email, then normalized phone (country and area code plus the last 8 digits). An email domain only counts if it is not a free email provider. Anonymous widget visitors, who can be half of the tickets, stay out of the per-customer analysis but count in volume. Publish the link rate. (Avoid: Analyzing loose tickets without knowing which customer they belong to.)
2. **External, human and bot in separate columns.** Remove the team's internal tickets, test companies and messages from the team's own numbers. Flag the tool's AI bot replies and automations. Agent productivity counts only messages from an identified human operator; system events and internal notes are not conversation. (Avoid: Adding bot, automation and agent into the same volume.)
3. **The clock starts at the customer's first message.** In chat, the customer writes before the ticket is created: in a real base, the first message was at 07:43 and the ticket at 07:59. Measure waiting and resolution from the customer's first message in the transcript. A technical close of the conversation is not resolution. Timings are summarized by median and percentiles, never by sum or average of averages. (Avoid: Response time from the ticket's created_at.)
4. **The AI reads the whole conversation, new text only.** Rebuild the full thread (customer, agent and bot) before classifying. In email, cut the quoted history from each reply ("On ... wrote:", "Em ... escreveu:", "De: ... Enviada em:", lines starting with ">"). Call transcripts have very short utterances: join them into 60-second windows with a timestamp. Never use the call tool's ready-made summary as a source: it is a third-party interpretation that loses context. (Avoid: Sending each email's raw body or the call's automatic summary.)
5. **Closed list of reasons, one primary and all those cited.** The AI picks one primary reason from a closed, versioned list, and separately lists every reason that appears with evidence. For a cancellation or downgrade request, classify its nature: leaving or rightsizing. Without enough evidence, the safe default for retention is to treat it as leaving. When the list changes, store the version on each row and map the old reason to the new one. (Avoid: Letting the AI invent free-form topics every run.)
6. **Every classification carries the excerpt that proves it.** Each reason, sentiment and risk signal comes with the literal quote from the new text. Normalize the keys of the AI's response (accents and lowercase) before consolidating. Track the class distribution every run: a model that returns everything as neutral is almost always a call error, not a happy customer. (Avoid: Storing only the label, with no idea where it came from.)
7. **Cost and reprocessing controlled per ticket.** Classify only what is new: a ticket enters the run if it was never classified or if it received a message newer than the last one read. The watermark is per ticket; a single watermark for the table gives each ticket one chance and loses messages that arrive later. Use a fixed window and a cap on calls per run, and limit how many types go to the AI in frequency analyses. (Avoid: Reprocessing everything every run, or using a global watermark.)
8. **Recurrence weighs more than volume.** Rank topics by affected customers and their revenue, not by raw message count. Recurrence is the same customer opening the same reason (or the same tag combination) more than once in 30 days: it signals a problem not solved at the root, not a customer who uses support a lot. Counting distinct weeks with a ticket separates recurrence from an isolated spike. (Avoid: Prioritizing the topic with the most messages.)
9. **Empty category and unassigned tickets are data too.** In real bases, the category was empty in about 60% of tickets and almost half had no owner. Use queue or pipeline as the main split, treat a null owner as unassigned and never discard it: a queue without an owner is itself a support health signal. Priority, origin and stage are dimensions, not quality measures. (Avoid: Filtering out tickets without a category or owner.)
10. **Anonymize before the text leaves Nekt.** Before sending conversations to an external model or a voice-of-the-customer tool, replace email with the user id, phone with a placeholder, and mask CPF and CNPJ (individual and company tax IDs). In a source shared by several clients (for example, one account that gathers reviews for several brands), the per-client filter is mandatory: a forgotten filter does not throw an error, it leaks silently. (Avoid: Sending the raw transcript to the API.)

### What the AI extracts from each conversation

Fixed fields, a closed list of values and always an evidence excerpt.

- **Primary reason** → Just one, from the closed, versioned list
- **Evidenced reasons** → Every one that appears in the text, as a list (`intent_multiple`)
- **Nature of the reduction** → Leaving or rightsizing; when in doubt, leaving (`leaving, rightsizing`)
- **Sentiment** → Positive, neutral or negative, with the excerpt
- **Risk signal** → Talk of cancelling, switching vendor or price
- **Product request** → Bug, improvement or integration, with the affected module
- **Evidence** → Literal quote from the customer's new text

### Definitions

| Metric | Definition |
|---|---|
| Valid ticket | a conversation started by an external customer that follows the same rule as the tool's native report, without tests, internal tickets or spam |
| Link rate | valid tickets linked to a paying customer / valid tickets with an identity (email, phone or company) |
| First response time | from the customer's first message to the first reply from a human agent, as median and p90 per period and queue |
| Resolution without handoff | tickets resolved without passing to a human or to the next tier / tickets resolved in the period |
| Recurrence | customers with more than one ticket for the same reason in 30 days / customers with a ticket in the period |
| Topic share | tickets with the primary reason / tickets classified in the period, always shown with affected customers |
| Topic negativity | topic tickets with negative sentiment / topic tickets classified |
| CSAT | answers of 4 and 5 / answers to the support survey, by type of service; no answer is not a score |
| NPS | % of 9 and 10 scores minus % of 0 to 6 scores, by answer date; it never replaces CSAT |

### Pitfalls

- **Quoted email multiplied the signals.** More than 80% of email text was repeated history. The AI found the same sentence again in every reply and churn signals came out almost three times higher than reality. How to avoid: Cut the quote before the AI and only accept evidence found in the new text.
- **A ready-made summary as the source.** The call tool's automatic summary looked like a shortcut to answer questions and to pick which calls to read. It is a lossy third-party interpretation, and it left out what the customer actually asked for. How to avoid: Use only the full transcript, with quotes, and never the third-party summary.
- **Everything came out neutral.** Because of a call failure, the model started returning neutral for every comment. The report looked stable, and only a diagnosis of the call found the cause. How to avoid: Track the class distribution every run and alert when one class goes over a threshold.
- **A ticket read only once.** With a single watermark for the table, tickets that received messages after others had been classified never went back to the AI. How to avoid: A per-ticket watermark, comparing the last message read with the newest one.
- **Waiting time shorter than reality.** Waiting time was measured from ticket creation, which happens minutes after the customer starts typing in the chat. How to avoid: Time zero at the customer's first message in the transcript.
- **Transcript in the wrong field.** The internal meeting notes field in the CRM was always empty; the team pasted the transcript into the meeting body, and the analysis read the empty field. How to avoid: Check on a sample where the text really lives before building the AI's base.

### Acceptance test

- [ ] The number of valid tickets per month matches the tool's native report, within 1%.
- [ ] The link rate to paying customers is published, and every unlinked ticket appears as no customer, none is discarded.
- [ ] Every classified ticket has a primary reason from the current list and an evidence excerpt that exists in the ticket's new text.
- [ ] On a sample of 50 tickets reviewed by a person, the AI's primary reason matches in at least 80%.
- [ ] No text sent to the model contains an email, phone, CPF or CNPJ in the clear.

### Context document

```text
AI support analytics
- A valid ticket follows the same rule as the tool's native report. Internal tickets, tests and messages from the team itself stay out.
- Every ticket is linked to a customer by the cascade: ticket, contact, email, phone. With no link, the value is no customer; never discard it.
- Timings count from the customer's first message. Report median and p90, never an average of averages. A technical close is not resolution.
- The reason comes from the current closed list (version <vN>). Use the primary reason to count and the list of evidenced reasons for detail.
- Every statement about what the customer said needs the literal quote from the new text. Do not use third-party automatic summaries.
- For a cancellation or downgrade request, say whether it is leaving or rightsizing.
- Prioritize topics by affected customers, revenue and recurrence, not by message count.
- A null owner is unassigned. An empty category is no category.
- NPS and CSAT are different surveys. A missing one is never replaced by the other.
Client exceptions:
- <client>: queue <name> is internal and stays out of the analysis.
- <client>: reason <old reason> was renamed <new reason> on <date>.
```

### Variations

- **Knowledge base:** One row per resolved ticket with text ready for embedding, so an assistant can answer from the history.
- **WhatsApp questions:** Messages from customer groups, without the team's numbers, grouped into the 10 most frequent questions of the period.
- **Brand monitor:** Public comments and reviews classified by sentiment, with a 24 and 72 hour index against the previous period.