Voz do cliente: como transformar o que ele diz em requisito medível

A pesquisa de satisfação volta com o comentário mais comum de todos: “o atendimento demora”. Setenta respostas dizem alguma versão disso.

A reunião seguinte define a ação: agilizar o atendimento. Três meses depois, a mesma reclamação aparece na mesma proporção — e ninguém consegue dizer se a equipe agilizou ou não, porque “agilizar” não é uma coisa que se possa verificar.

Entre o que o cliente disse e o que o processo consegue perseguir existe uma tradução, e ela tem três degraus. Pulá-los é o que faz projetos inteiros terminarem sem resposta.

Os três degraus da tradução

A voz é uma reclamação; a necessidade é uma interpretação; o requisito é um compromisso verificável. Só o terceiro pode ser perseguido por um processo, e é o único que permite dizer, no fim, se melhorou.

O erro que a maioria comete não é pular a tradução — é fazê-la de cabeça, uma vez, sem escrever. Assim “demora” vira “reduzir o tempo médio de atendimento”, que parece requisito e não é: média não é experiência de ninguém, e uma média boa convive com um quarto dos clientes esperando três vezes mais.

A árvore CTC: como fazer a tradução por escrito

A árvore CTC — crítico para o cliente — é a estrutura que organiza esse caminho e obriga cada degrau a ser explicitado.

Ela se lê da esquerda para a direita. À esquerda, a voz, no verbo do cliente. No meio, a necessidade que aquela frase revela. À direita, os requisitos medíveis que, se cumpridos, atendem à necessidade.

Uma voz costuma abrir em mais de uma necessidade, e cada necessidade em mais de um requisito — e é aí que a ferramenta paga o esforço. “O atendimento demora” pode significar demora para ser atendido, demora para o problema ser resolvido, ou demora para receber retorno depois do primeiro contato. As três geram requisitos distintos e projetos distintos, e tratar as três como uma só é a origem da ação genérica que não muda nada.

Quando os requisitos são levados até características do produto ou do processo — o nível operacional em que alguém de fato mede —, o nome usual é CTQ, crítico para a qualidade. A diferença entre CTC e CTQ é de altura na árvore, não de natureza: o primeiro está na linguagem do cliente, o segundo na do processo.

O que faz um requisito ser requisito

Três condições, e a falha de qualquer uma devolve o projeto ao ponto de partida.

Tem unidade e valor. “Resposta rápida” não é requisito; “resposta em até 1 hora” é. Sem número, o cumprimento vira opinião.

Tem critério de medição que duas pessoas apliquem igual. O tempo de resposta conta a partir da abertura do chamado ou do primeiro contato do cliente? Inclui fim de semana? Sem isso fixado, duas áreas medem coisas diferentes com o mesmo nome — e é o papel de uma definição operacional.

Tem uma declaração sobre a variação, não só sobre o centro. Este é o degrau que quase todo mundo pula. “Uma hora em média” e “uma hora em 95% dos casos” descrevem operações muito diferentes, e é a segunda que corresponde à experiência do cliente. Clientes não vivem a média — vivem o próprio caso.

Nem tudo que o cliente diz vira requisito

Há uma distinção prática que evita listas intermináveis de requisitos, todos declarados essenciais.

Alguns atributos são obrigatórios: quando presentes, ninguém elogia; quando ausentes, geram insatisfação imediata. A nota fiscal correta, o produto dentro da validade, o sistema no ar. Não há ganho em superá-los.

Outros são proporcionais: quanto melhor, mais satisfação. Prazo de entrega, tempo de resposta, preço. É onde vale investir quando se quer diferenciação percebida.

E outros são surpresa: o cliente não pede porque não imagina que exista, e a presença encanta. Com o tempo, todo atributo de surpresa vira proporcional e depois obrigatório — o que já foi diferencial hoje é o mínimo esperado.

A consequência prática: investir em superar um atributo obrigatório não gera satisfação. Nota fiscal duas vezes mais correta não existe. Reconhecer a categoria antes de definir a meta evita gastar o orçamento do projeto onde ele não é percebido.

De onde vem a voz

A pesquisa de satisfação é a fonte mais usada e a mais enviesada — responde quem está muito satisfeito ou muito insatisfeito, e as perguntas costumam ser sobre o que a empresa já decidiu medir.

As fontes que costumam render mais são as que registram comportamento em vez de opinião: reclamações formais e informais, motivos de cancelamento, o que o time comercial ouve na objeção, os chamados abertos e — a mais subestimada — as perguntas que os clientes fazem. Cliente que pergunta a mesma coisa cem vezes está apontando uma informação que o processo deveria entregar sozinho.

Os métodos de captura, com o desenho de cada um, estão em como ouvir a voz do cliente. Quando o objetivo é acompanhar a disposição de recomendar ao longo do tempo, o indicador está em NPS.

Uma advertência sobre o cliente interno: em processos que atendem outras áreas, a voz do cliente é a da área seguinte — e ela raramente é ouvida com o mesmo cuidado, porque não cancela contrato. É onde mais se encontram requisitos que ninguém pediu sendo cumpridos há anos.

Onde a árvore entra no projeto

A tradução pertence ao começo — antes de medir qualquer coisa, porque é ela que define o que medir. É a fase de definição do DMAIC, e o que sai dela é o indicador que o projeto vai perseguir.

Feita a tradução, três coisas seguem naturalmente. O requisito vira o alvo declarado no contrato do projeto. O critério de medição vira a base do plano de coleta de dados. E a comparação entre a faixa em que o processo opera e o requisito responde à pergunta que decide o escopo: o processo é capaz de entregar isso, ou o problema é de patamar e não de oscilação? Distinguir as duas coisas está em variabilidade natural do processo.

Conduzir essa sequência — traduzir, medir, investigar, testar, verificar — é o que uma formação como o Green Belt desenvolve, e a primeira etapa é a que mais separa projeto que responde de projeto que descreve.

A árvore que fica na parede

Há um destino comum para esse trabalho que vale antecipar: a árvore é construída num workshop, fica bonita no slide e nunca mais é consultada. O projeto segue com o objetivo que a equipe já tinha antes do workshop.

O sinal de que isso aconteceu é simples de detectar: o indicador que o projeto acompanha não é nenhum dos requisitos da árvore. Quando isso acontece, a tradução foi um exercício, não uma decisão — e o projeto voltou a perseguir o que era fácil de medir em vez do que o cliente valoriza.

Conferir isso leva trinta segundos e costuma ser desconfortável.

Conteúdo revisado pelo Master Black Belt Marcelo Petenate, estatístico, formado pela Unicamp, mestre pela USP e especialista em Lean Six Sigma e melhoria contínua. Nesta revisão, o foco foi a exigência de declarar variação e não só o valor central no requisito, e a distinção entre atributos obrigatórios e proporcionais.

O White Belt gratuito da EDTI apresenta a primeira das três questões fundamentais — o que estamos tentando realizar — que é onde essa tradução vive.

Perguntas frequentes

O que é VOC, a voz do cliente?

É o conjunto do que os clientes expressam sobre o produto ou serviço, nas palavras deles — reclamações, pedidos, elogios, perguntas e motivos de cancelamento. A voz sozinha não orienta ação: ela precisa ser traduzida em necessidade e depois em requisito com número e critério de medição.

O que é a árvore CTC?

É a estrutura que organiza a tradução da voz do cliente em requisitos medíveis, em três níveis: a voz como foi dita, a necessidade que ela revela e os requisitos que atendem a essa necessidade. Uma voz costuma abrir em várias necessidades, e cada uma em vários requisitos — e é essa abertura que evita a ação genérica.

Qual a diferença entre CTC e CTQ?

É de altura na árvore, não de natureza. O CTC está na linguagem do cliente; o CTQ desce ao nível da característica do processo ou do produto que alguém de fato mede. Um requisito de “resposta em até uma hora” é CTC; o CTQ correspondente é o tempo medido entre dois eventos definidos do sistema.

Como transformar uma reclamação em requisito?

Perguntando o que aquela frase revela como necessidade e, depois, que característica com número e tolerância atenderia essa necessidade. O requisito precisa de unidade e valor, critério de medição que duas pessoas apliquem igual, e uma declaração sobre a variação — não apenas sobre a média.

Por que média não serve como requisito?

Porque o cliente não vive a média, vive o próprio caso. Um tempo médio de uma hora convive com uma parcela relevante de clientes esperando três vezes mais, e essa parcela é a que reclama. Requisitos que descrevem a experiência real são declarados em proporção — como “em até uma hora em 95% dos casos”.

Todo requisito do cliente deve virar meta do projeto?

Não. Atributos obrigatórios não geram satisfação quando superados — só insatisfação quando faltam. Investir em superar um deles gasta orçamento onde o cliente não percebe. A diferenciação vem dos atributos proporcionais, em que mais é sempre melhor.

E quando o cliente é interno?

A lógica é a mesma e o cuidado costuma ser menor, porque cliente interno não cancela contrato. É justamente nesses processos que mais se encontram requisitos que ninguém pediu sendo cumpridos há anos — e etapas inteiras que existem por inércia.