--- title: "Voz do cliente (VoC): o que os tickets contam e o NPS não" url: "https://usekairos.cx/blog/voz-do-cliente-nos-tickets" description: "A voz do cliente (VoC) não mora só no NPS. Os tickets de suporte guardam o que o cliente trouxe sem ninguém perguntar. Veja como ler essa fonte." --- ![Ilustração: um grande balão de fala cheio de tickets, ao lado de um pequeno medidor de nota.](/_astro/voz-do-cliente-nos-tickets.B62r3qM8_ZWjWvX.webp) Quando uma empresa decide montar um programa de voz do cliente (VoC), a conversa quase sempre vai direto para pesquisa: NPS no trimestre, CSAT depois do atendimento, talvez umas entrevistas com as contas grandes. Enquanto isso, a fila de suporte acumula milhares de conversas em que o cliente explicou, com as próprias palavras, o que deu errado. A nossa aposta é que o atendimento é a fonte de VoC mais subaproveitada que existe: o cliente escreve sem ninguém ter perguntado, e quase ninguém lê depois. ## O que a voz do cliente (VoC) tenta responder Voz do cliente (VoC) é o conjunto de práticas para captar, organizar e priorizar o que os clientes dizem que precisam e o que os incomoda. O termo vem da literatura de QFD (desdobramento da função qualidade), na engenharia de produto. A referência acadêmica mais citada é o artigo de Abbie Griffin e John Hauser na _Marketing Science_, em 1993, chamado justamente [“The Voice of the Customer”](https://pubsonline.informs.org/doi/10.1287/mksc.12.1.1). Mais de trinta anos depois, a pergunta continua de pé: o que o cliente precisa e a empresa ainda não entregou. Os guias de VoC costumam pôr a pesquisa no topo da lista de canais, e o atendimento no fim, quando entra. ## Os limites do NPS e do CSAT NPS e CSAT são bons instrumentos, e ninguém precisa abrir mão deles. Servem para ver tendência e para ter um número que a diretoria entende sem explicação. Falamos desse painel em [indicadores de atendimento](/blog/indicadores-de-atendimento/). O limite está no desenho. Quem escolhe a pergunta e a hora de perguntar é a empresa, e o cliente responde dentro desse enquadramento. Uma nota 6 avisa que algo não vai bem, mas não diz o quê. O campo aberto, quando alguém preenche, costuma ter uma frase curta escrita às pressas. E existe o problema de quem responde. A amostra é de quem abriu o e-mail e ainda teve paciência para clicar. O cliente que desistiu no meio do caminho raramente está ali. ## O que aparece no ticket e não aparece na pesquisa No ticket, ninguém perguntou nada: o cliente contou do jeito dele o que o trouxe até ali. Dois exemplos inventados, mas que qualquer gestor de fila reconhece. O primeiro é o cliente que abre três tickets na mesma semana sobre a mesma cobrança duplicada. Em cada um cai com um agente diferente e explica tudo de novo. No terceiro, o tom já mudou. Se o seu helpdesk marca “financeiro” nos três, o relatório mostra três contatos financeiros resolvidos. Não mostra que foi um cliente só, com um problema só, que precisou de uma semana e três conversas para ser ouvido. O segundo é a pessoa que dá nota 8 na pesquisa depois de ter escrito no chat que só não cancelou porque a multa é alta. É o caso mais perigoso. A nota diz que está tudo razoável. A conversa diz que o cliente está de saída. Tem coisa que praticamente só aparece no atendimento. O motivo real do contato, que muitas vezes não bate com a tag marcada. O esforço do cliente, contado em quantas vezes ele voltou e repetiu o mesmo dado. E problemas que nunca viraram pergunta de pesquisa porque ninguém sabia que existiam. O ticket tem o viés dele, claro. Só aparece quem teve problema e resolveu procurar a empresa; quem se virou sozinho na central de ajuda não está ali, e quem desistiu calado também não. Parte do texto, aliás, foi escrita pelo agente ou pelo bot. Por isso não defendo trocar a pesquisa pelo ticket, e sim cruzar as duas. O cruzamento mais útil é simples: pegue quem deu nota baixa ou mediana e abra o histórico de tickets da mesma pessoa. É ali que você descobre quantos dos seus “8” já tinham falado em cancelar. E contatos repetidos pelo mesmo motivo, em poucos dias, medem esforço com mais honestidade do que perguntar ao cliente se foi fácil. ## Por que quase ninguém lê essa fonte O helpdesk foi feito para resolver um ticket de cada vez, e é ótimo nisso. Ler dez mil conversas no agregado é outra tarefa, e a ferramenta não foi pensada para ela (escrevemos sobre esse trabalho em [análise de atendimento ao cliente](/blog/analise-de-atendimento-ao-cliente/)). O que ela oferece para o agregado é o relatório de tags, que depende de cada agente marcar do mesmo jeito com a fila pegando fogo. Já explicamos [por que as tags do helpdesk não bastam](/blog/por-que-tags-do-helpdesk-nao-bastam/). Aí sobra a leitura de amostra. Só que a amostra que chega na mesa do gestor quase nunca é aleatória: são os escalados e os que alguém encaminhou com “olha isso”. Caso extremo distorce a percepção do todo. E tem a privacidade. Ticket tem CPF, número de cartão, e-mail, telefone. Ninguém fica tranquilo exportando isso para uma planilha compartilhada, e com razão. ## Como tirar voz do cliente dos tickets sem ler tudo Isso vale com ou sem ferramenta. Comece pelo atendimento finalizado: ticket aberto ainda não tem desfecho, e para entender o cliente é o desfecho que interessa. ### Separe o motivo do contato do sentimento “Por que o cliente veio” e “como ele saiu” são perguntas diferentes, e misturar as duas num mesmo rótulo estraga as duas. O motivo precisa de uma classificação com critério estável no tempo, senão o número de março não se compara com o de julho. Detalhamos isso em [motivos de contato](/blog/motivos-de-contato/). ### Nota e conversa em colunas separadas Se o cliente marcou 2 de 5 no CSAT, isso é dado declarado. Se você lê a conversa e conclui que ele saiu irritado, isso é inferência. As duas coisas são úteis, mas juntar tudo num índice só apaga justamente a diferença que interessa: os casos em que a nota e a conversa discordam. Mais sobre isso em [análise de sentimento no atendimento](/blog/analise-de-sentimento-no-atendimento/). ### Mostre a conversa junto do número Produto e diretoria só mudam prioridade quando leem o cliente falando. Pelo que a gente vê em operação, gráfico de “cobrança” subindo gera um aceno na reunião; três trechos de cliente explicando a cobrança duplicada geram um dono para o problema. Todo número de VoC tirado do atendimento deveria vir com os tickets que o sustentam. Depois da leitura, cada tema precisa de um dono em produto ou operações e de uma data fixa de revisão. E avise o time de atendimento quando o problema for corrigido: agente que nunca fica sabendo que a reclamação virou correção para de reportar. ## Onde o Echo entra O [Módulo Echo](/echo/), da plataforma Kairos, foi desenhado para esse trabalho. Ele se conecta ao helpdesk, lê os atendimentos finalizados e organiza o histórico em tópicos descobertos no próprio conteúdo das conversas. Cada tópico chega como proposta, com volume e tickets de exemplo, e só passa a valer depois que alguém do time aprova. ![Proposta de tópico no Echo chamada Pix por QR Code, com 50 tickets, descrição editável, termos que distinguem o grupo, três tickets representativos com o início da conversa do cliente, categoria Financeiro e as ações de fazer um tópico com estes, rejeitar ou aprovar.](/_astro/proposta-topico.B7T1J1PB_HPQn1.webp) Tela real do Echo · dados de demonstração A satisfação que o Echo infere da conversa fica separada do CSAT que o cliente de fato respondeu, e as duas medidas nunca são somadas. Na Leitura do Echo, os destaques de CSAT só aparecem com uma quantidade mínima de respostas e vêm com os tickets que servem de evidência. Uma associação ali não prova causa. A privacidade é tratada na entrada. Antes da análise, identificadores como CPF, CNPJ, e-mail, telefone e número de cartão são trocados por marcadores; se a anonimização falha, o ticket não segue. Nomes de pessoas, empresas e locais continuam no texto como contexto. [Veja os detalhes de privacidade do Echo](/echo/#privacidade). O que o Echo não faz: ele não envia pesquisa e não analisa ticket aberto em tempo real. Também não se conecta direto ao WhatsApp nem a uma caixa de e-mail; lê o que já passou pelo helpdesk, seja qual for o canal de origem. Não substitui o seu NPS. ## Um teste para fazer nesta semana Para medir o tamanho do buraco antes de mexer em processo, separe o último relatório de NPS ou CSAT e anote os temas que ele aponta. Depois pegue os tickets finalizados de um período, ordene pelo número e leia um a cada N até chegar a uns cinquenta. Anote do que os clientes estavam falando. Cinquenta tickets servem para ver se os temas batem, não para medir proporção. Se as listas baterem, ótimo, sua pesquisa está perguntando as coisas certas. Se não baterem, leve a diferença para a próxima reunião com produto. Módulo Echo · acesso antecipado ## Transforme o histórico do seu helpdesk em tópicos para decidir. O Echo lê os atendimentos já resolvidos, descobre os tópicos do seu negócio e deixa a aprovação com o seu time. Estamos abrindo para um grupo pequeno de times de CX. [Pedir demonstração do Echo](/echo/#early-access) ## Continue lendo 1. Artigo 7 de outubro de 2026 ### [Como reduzir o volume de tickets a partir dos motivos de contato](/blog/reduzir-volume-de-tickets/) Reduzir o volume de tickets começa por saber por que o cliente procura o atendimento. Veja como separar o evitável, priorizar e medir a queda. 2. Artigo 28 de setembro de 2026 ### [Pesquisa de satisfação: quando usar NPS, CSAT e CES](/blog/pesquisa-de-satisfacao-nps-csat-ces/) NPS, CSAT e CES respondem a perguntas diferentes. Veja quando usar cada pesquisa de satisfação e como evitar que a nota vire só mais um slide. 3. Artigo 24 de setembro de 2026 ### [Análise de atendimento ao cliente: ache o motivo do contato](/blog/analise-de-atendimento-ao-cliente/) Análise de atendimento ao cliente além do TMA e do CSAT: um método para achar nos tickets por que o cliente procura o suporte e quem resolve.