---
id: saas/suporte-por-cliente
industria: SaaS e tecnologia
uso: específico
esforco: médio
grao: Chamado (fato) e cliente x mês (agregado)
---

# Suporte por cliente, com espera, resolução e motivo

Quantos chamados cada cliente pagante abriu, quanto esperou por uma pessoa e por quê, com o mesmo volume que o relatório da ferramenta de suporte mostra.

## Resumo executivo

**Para quem:** Empresas de SaaS que precisam saber quais clientes mais demandam o suporte, quanto eles esperam e o que está quebrando no produto.

**O que resolve**

- Cada chamado ligado ao cliente pagante, com o MRR dele ao lado.
- Espera medida a partir do momento em que o cliente escreveu, separada entre IA e humano.
- Motivo e módulo de cada chamado prontos para produto priorizar.

**Por que importa:** Volume de chamados por cliente é um dos sinais mais usados no health score, e quase sempre vem torto: ticket sem empresa, chat que começou antes do ticket, bot contado como atendente. Sem a ligação com o billing, o suporte prioriza quem escreve mais, não quem paga mais. E com um agente de IA atendendo boa parte da fila, a primeira resposta melhora enquanto quem precisa de uma pessoa continua esperando.

**Perguntas de negócio que responde**

- Quais clientes abriram mais chamados este mês, comparado ao mês anterior?
- Quanto tempo o cliente espera até falar com uma pessoa, na mediana e no p90?
- Quanto da fila o agente de IA resolveu sozinho e quanto foi transferido para o time?
- Quais módulos geram mais chamados de erro, e de quais clientes?
- Estamos cumprindo o SLA das contas top?
- Quantos chamados estão sem dono agora?

**O que você precisa**

- A ferramenta de suporte conectada na Nekt (conversas, tickets e mensagens)
- A chave do cliente gravada no ticket ou no contato, ligada ao billing
- Uma lista fechada de motivos e módulos, e o SLA combinado por tipo de cliente

**O que você recebe**

- Uma tabela de chamados com cliente, canal, quem atendeu, tempos e motivo
- Um agregado cliente x mês pronto para o health score
- Painel de SLA, fila sem dono e reaberturas por atendente e equipe
- Um agente de IA que responde sobre suporte já com o recorte certo

## Detalhado

### O problema

A ferramenta de suporte conta conversas que o cliente nunca abriu, chamados sem empresa e mensagem do bot como resposta. O tempo de resposta começa quando o ticket é criado, não quando o cliente escreveu, e o tempo vazio vira zero na média. O resultado é um volume por cliente que não bate com o relatório da ferramenta, um tempo de resposta bom demais e um health score que pune o cliente errado.

### Regras de negócio

1. **Conte só o chamado válido, como o relatório da ferramenta.** No Intercom, a conversa conta quando não foi disparada por automação (source.delivered_as diferente de automated) e o cliente respondeu (first_contact_reply preenchido). Mensagens proativas, campanhas e lembretes ficam fora. Reproduza primeiro a regra do relatório nativo da ferramenta e só depois crie recortes próprios, publicando a diferença quando houver. (Evite: Contar toda conversa criada, inclusive as disparadas pelo time ou por automação.)
2. **Externo e interno sempre separados.** Pedidos internos (do financeiro para o suporte, tarefas de operação) convivem com os chamados de cliente na mesma ferramenta. Separe por um campo de tipo do chamado, não pelo nome da equipe: uma equipe pode ter os dois. Tire empresas internas e de teste. Quando a pergunta não disser qual recorte, o agente pergunta antes de responder. (Evite: Somar chamados internos da equipe no volume do cliente.)
3. **Todo chamado ligado ao cliente, em cascata.** O chamado muitas vezes chega sem empresa. Resolva por ordem: empresa do próprio chamado, empresa do contato, e-mail, telefone normalizado (DDD mais os últimos 8 dígitos). Domínio de e-mail só vale se não for de provedor gratuito. Um de-para de empresa só entra quando é unívoco. Grave como o cliente foi identificado (direto, de-para ou sem identificação) e publique a taxa de vínculo por mês. (Evite: Contar só os chamados que já vêm com empresa, ou escolher o cliente mais frequente de um id ambíguo.)
4. **O relógio começa na primeira fala do cliente.** Em chat, o cliente escreve antes de o ticket existir: numa base real, a primeira mensagem era de 07:43 e o ticket de 07:59. Espera é a primeira resposta da empresa depois da primeira mensagem do cliente, calculada pelas mensagens. Se a empresa falou primeiro (atendimento ativo), conte a partir da primeira fala do cliente, senão o tempo sai negativo. Conversa com horário inferido, como a que cruza a virada do ano sem data completa, fica fora do SLA. (Evite: Medir a resposta a partir do created_at do ticket.)
5. **IA e humano são tempos diferentes.** Com um agente de IA respondendo primeiro, a primeira resposta cai para segundos e esconde a espera por uma pessoa. Classifique cada chamado em só IA, IA com transferência, só humano, sem resposta ou sem transcrição, e meça a espera até a primeira resposta humana à parte. Contadores nativos de resposta de agente podem ignorar a mensagem da IA: guarde-os para auditoria e calcule pelas mensagens. No Intercom, resolução presumida da IA (assumed_resolution em ai_agent.resolution_state) não é resolução confirmada pelo cliente. (Evite: Uma única primeira resposta, com IA e humano misturados.)
6. **Tempo vazio não é zero, e média não resume.** Chamado sem resposta humana tem tempo vazio. Trocar vazio por zero puxa a média para baixo. Resuma tempos por mediana e p90, só sobre chamados elegíveis (chat com transcrição e horário confiável), e mostre quantos ficaram de fora. Se o SLA é em horário comercial, use o tempo em horário comercial que a ferramenta fornece (no Intercom, a primeira resposta em office hours nas estatísticas da conversa) e diga qual dos dois está mostrando. (Evite: Média com vazio trocado por zero, sobre todos os chamados.)
7. **Resolução até o primeiro fechamento; reabertura à parte.** Tempo de resolução vai da criação ao primeiro fechamento. Chamado reaberto (hs_ticket_reopened_at no HubSpot, count_reopens no Intercom) entra numa métrica própria de reabertura por atendente, sinal de fechamento mal feito. No HubSpot, time_to_close, time_to_first_agent_reply e o tempo por etapa (hs_v2_cumulative_time_in_<etapa>) vêm em milissegundos: converta uma vez, na primeira camada. (Evite: Usar o último fechamento e esconder a reabertura dentro do tempo.)
8. **Sem dono e sem categoria também são dado.** Numa base real, quase metade dos chamados não tinha dono e a categoria vinha vazia na maioria. Rotule dono nulo como Não atribuído e nunca descarte: a fila sem dono é um sinal da saúde do atendimento. Use fila, pipeline ou nível (N1, N2, N3) como quebra principal quando a categoria não é confiável, e mapeie status em mais de uma língua (Resolvido e Closed) para aberto, pendente e fechado. (Evite: Filtrar chamados sem dono ou sem categoria.)
9. **Volume do cliente comparado com ele mesmo.** Um cliente com 200 usuários abre mais chamados que um com 5. Para o health score, use o agregado cliente x mês com variação contra o mês anterior e média móvel de 3 meses, e normalize por usuários ativos ou por MRR. Separe dúvida de erro: dúvida aponta para onboarding e documentação, erro aponta para produto. O percentual de dúvidas usa só chamados fechados classificados como dúvida ou erro. (Evite: Ranquear clientes pelo volume bruto de chamados.)
10. **SLA vem do contrato, por tipo de cliente.** O alvo depende do cliente, por exemplo 24 horas para contas top e 72 horas para as demais, em dias úteis. Grave o alvo no chamado e marque violação quando foi resolvido depois do alvo ou segue aberto além dele. Chamado antigo, de antes da automação do SLA, fica sem alvo e fora do denominador, nunca como cumprido. (Evite: Um SLA único para todos, e chamado sem alvo contado como dentro do prazo.)

### Quem atendeu o chamado

Pelas mensagens da transcrição, depois da primeira fala do cliente.

- **só mensagens da IA** → Resolvido pela IA
- **IA primeiro, depois uma pessoa** → Transferido (`espera humana = 1ª resposta humana - 1ª fala do cliente`)
- **só mensagens de pessoas do time** → Humano
- **nenhuma mensagem da empresa** → Sem resposta
- **sem transcrição ou horário inferido** → Fora do SLA, conta no volume

### Definições

| Métrica | Definição |
|---|---|
| Chamado válido | conversa ou ticket aberto pelo cliente, não disparado por automação ou pelo time, com resposta do cliente, sem internos e empresas de teste; contado na data de criação |
| Tempo de espera | da primeira mensagem do cliente até a primeira resposta da empresa (IA ou humano) depois dela, por chamado, em segundos |
| Espera humana | da primeira mensagem do cliente até a primeira resposta de uma pessoa do time; vazia quando só a IA atendeu |
| Tempo de resolução | da criação até o primeiro fechamento, por chamado; reaberturas medidas à parte |
| Taxa de resolução pela IA | chamados de chat atendidos só pela IA / chamados de chat válidos, por mês |
| Taxa de reabertura | chamados fechados no mês com pelo menos uma reabertura / chamados fechados no mês, por atendente e equipe |
| Violação de SLA | chamado resolvido depois do alvo, ou aberto além do alvo na data de referência / chamados com alvo |
| Chamados por cliente | chamados válidos externos do cliente no mês, com variação contra o mês anterior e média móvel de 3 meses |
| Taxa de vínculo | chamados válidos ligados a um cliente / chamados válidos, por mês e por método de identificação |

### Armadilhas

- **Um id de empresa para mais de mil clientes.** O de-para escolhia o cliente mais frequente de cada id de empresa da ferramenta. Um desses ids era do agente interno que abria chamados em nome dos clientes, e milhares de chamados caíram num cliente só, que apareceu como o maior usuário do suporte. Como evitar: Aceite só de-para unívoco; o resto fica como sem identificação.
- **Chamado contado duas vezes pelo domínio.** Juntar uma tabela de empresa x domínio com a de chamados duplicou linhas, porque uma empresa tinha vários e-mails de acesso. O contador mostrou cerca de 13% mais chamados do que existiam e alimentou o health score assim. Como evitar: Resolva o cliente por chamado e conte pelo id do chamado.
- **Carga de histórico em dobro.** A carga de anos de chamados gravou em modo de acréscimo, e reprocessar um arquivo repetiu chamados idênticos. Todos os contadores saíram inflados sem nenhum erro. Como evitar: Deduplique pelo id do chamado na entrada da camada de métricas.
- **Vazio virou zero na média.** O cálculo trocava tempo de resposta vazio por zero antes de tirar a média, e a primeira resposta do time parecia muito melhor do que era. Como evitar: Tire os vazios da média, use mediana e p90 e mostre a contagem.
- **A IA melhorou a média, o cliente esperou igual.** Com o agente de IA na frente, a primeira resposta caiu para segundos. A espera por uma pessoa nos chamados transferidos não mudou, e ninguém via porque só havia uma coluna de tempo. Como evitar: Publique a espera humana ao lado da primeira resposta.
- **Status em duas línguas.** Resolvido e Closed conviviam no mesmo campo, e uma parte dos chamados fechados era contada como aberta. Como evitar: Mapeie todos os status para aberto, pendente e fechado numa tabela.

Validado em dados reais: Na conta de Intercom da própria Nekt, cerca de 85% das conversas tiveram participação do agente de IA e mais de 6 em cada 10 não tiveram nenhuma resposta humana. Trocar o tempo vazio por zero derruba a média de primeira resposta humana para pouco mais de um terço do valor real, e mesmo sem os vazios a média fica dezenas de vezes acima da mediana, por causa da cauda longa. Nenhuma conversa traz a empresa preenchida no próprio registro, e a maioria das resoluções da IA é presumida, não confirmada pelo cliente.

### Teste de aceitação

- [ ] O número de chamados válidos por mês bate com o relatório nativo da ferramenta (diferença abaixo de 2%).
- [ ] Nenhum chamado tem tempo de espera negativo, e nenhum tempo vazio entra como zero.
- [ ] A taxa de vínculo ao cliente é publicada por mês, e chamado sem cliente aparece como sem identificação, não some.
- [ ] Só IA + transferido + humano + sem resposta + fora do SLA = total de chamados válidos.
- [ ] Cada chamado aparece uma vez (id único), mesmo depois de reprocessar a carga.

### Context document

```text
Suporte por cliente
- Chamado válido = aberto pelo cliente, não disparado por automação nem pelo time, com resposta do cliente. No Intercom: source.delivered_as diferente de automated e first_contact_reply preenchido.
- Separe sempre chamados de cliente (externos) de chamados internos da equipe, pelo tipo do chamado. Se a pergunta não disser qual recorte, pergunte.
- Empresas internas e de teste ficam fora. Chamado sem cliente identificado conta no volume como sem identificação.
- Tempo de espera começa na primeira mensagem do cliente, não na criação do ticket. Espera humana é medida à parte; vazia quando só a IA atendeu.
- Tipo de atendimento: só IA, transferido, humano, sem resposta, fora do SLA.
- Tempos são resumidos por mediana e p90 sobre chamados elegíveis. Nunca troque tempo vazio por zero.
- Resolução = criação até o primeiro fechamento. Reabertura é métrica própria.
- Dono nulo = Não atribuído. Nunca descarte.
- Tempos do HubSpot vêm em milissegundos.
- SLA: alvo por tipo de cliente gravado no chamado. Chamado sem alvo fica fora do cálculo de SLA.
Exceções por cliente:
- <cliente>: SLA de <horas> horas úteis por contrato.
- <cliente>: chamados abertos pelo canal <canal> ficam fora do tempo de experiência.
```

### Variações

- **Suporte por WhatsApp:** O chamado é o grupo ou o número: ligue ao cliente pelo nome do grupo normalizado ou pelos últimos 8 dígitos do telefone, e anonimize telefone, e-mail e documento antes de exportar o texto.
- **Sustentação com SLA contratual:** O backlog vira uma foto mensal dos chamados abertos, sem corte pela data de abertura, com envelhecimento e transbordo entre N1, N2 e N3.
- **Chamados por módulo para produto:** Um campo de módulo impactado no chamado liga cada erro à parte do produto e ao cliente, e produto prioriza por clientes e MRR afetados.