Árvore CTQ: Como Definir o Crítico para a Qualidade

O que é uma Árvore CTQ? representada como uma elegante árvore ramificada de três níveis: uma raiz em forma de balão de fala do cliente, três ramos de drivers e várias folhas em forma de medidor, com uma folha-alvo em coral.

Turn this article into takeaways for your work.

Each assistant summarizes the article only for you and suggests best practices for your work.

A árvore CTQ é uma das ferramentas mais práticas do Six Sigma. Ela parte de uma necessidade ampla do cliente, algo como "eu quero um produto confiável", e a decompõe em requisitos específicos e mensuráveis que engenheiros e equipes de processo podem realmente usar como referência. Sem essa etapa de tradução, as equipes acabam otimizando coisas que soam certas, mas que não se relacionam com o que o cliente realmente valoriza.

O nome completo é árvore critical to quality (CTQ), ou crítico para a qualidade, e costuma ser uma das primeiras ferramentas aplicadas na fase Define do DMAIC. Ela faz a ponte entre a voz bruta do cliente e as métricas-alvo de um projeto.

O Que É uma Árvore CTQ?

Uma árvore critical to quality (CTQ) é um diagrama estruturado que traduz uma necessidade do cliente em categorias de direcionadores (drivers) e, depois, em características de qualidade específicas e mensuráveis, com metas de desempenho definidas. Ela é construída da esquerda para a direita: uma necessidade, de dois a quatro drivers por necessidade, e de dois a quatro CTQs mensuráveis por driver.

O objetivo é a precisão. "Os clientes querem entrega rápida" é uma necessidade. Ela indica a direção, mas não o destino. Uma árvore CTQ obriga você a perguntar o que "rápido" realmente significa para o cliente (é o tempo entre o pedido e o envio, o tempo de trânsito porta a porta, ou a visibilidade de rastreamento em tempo real?) e, então, definir a especificação mensurável que, se atendida, satisfaz a necessidade.

As árvores CTQ nascem da pesquisa de Voz do Cliente (VoC). O VoC captura a linguagem bruta do cliente. A árvore CTQ traduz essa linguagem em termos de engenharia e operação. A partir daí, esses CTQs se tornam os Y's (variáveis dependentes) sobre os quais um projeto DMAIC ou DMADV é construído.

Principais Dados

  • Empresas que vinculam métricas de qualidade diretamente aos requisitos do cliente reduzem os custos com defeitos em 20 a 30%, em comparação com aquelas que usam apenas especificações derivadas internamente (American Society for Quality, relatório State of Quality 2023).
  • A má qualidade custa aos fabricantes dos EUA aproximadamente 5 a 30% das vendas brutas, dependendo da maturidade de seus sistemas de qualidade (ASQ Quality Cost Survey).
  • Projetos Six Sigma que começam com uma árvore CTQ validada chegam à fase Improve 40% mais rápido, em média, porque o sistema de medição já está corretamente escopado (benchmarks do setor da iSixSigma).

Os Três Níveis de uma Árvore CTQ

Toda árvore CTQ tem exatamente três níveis. Cada nível responde a uma pergunta diferente.

Os Três Níveis de uma Árvore CTQ representados como uma estrutura panorâmica ramificada da esquerda para a direita, com três níveis claramente separados rotulados NEED, DRIVER e CTQ; uma necessidade se desdobra em três drivers e cada um termina em um pequeno medidor ou régua.

Nível Nome Pergunta que Responde Exemplo
Nível 1 Necessidade O que o cliente realmente quer? Entrega rápida
Nível 2 Driver O que faz essa necessidade ser atendida ou não? Velocidade de processamento do pedido, tempo de trânsito da transportadora, transparência do rastreamento
Nível 3 CTQ (Critical to Quality) Qual característica específica e mensurável comprova que o driver foi atendido? Pedido confirmado e enviado em até 24 horas, tempo de trânsito abaixo de 3 dias para pedidos padrão, atualização de rastreamento em tempo real a cada 4 horas

O CTQ no Nível 3 sempre precisa ter uma meta e um limite de especificação. "Menos de 3 dias" é um CTQ. "Rápido" não é. Se você não consegue escrever um teste de aprovação/reprovação para ele, ainda não chegou ao Nível 3.

Árvore CTQ vs Outras Ferramentas de Qualidade

As árvores CTQ funcionam como parte de uma cadeia, não isoladamente. Entender onde elas se encaixam em relação a outras ferramentas evita confusão sobre quando usar cada uma.

Árvore CTQ vs Outras Ferramentas de Qualidade representada como uma passagem panorâmica entre três ferramentas: uma onda de voz do cliente entra em uma árvore ramificada CTQ e depois alimenta uma matriz de projeto em forma de casa; rótulos esparsos VOC, CTQ, QFD e setas direcionais claras.

Voz do Cliente (VoC) captura o que os clientes dizem com as próprias palavras, por meio de pesquisas, entrevistas, tickets de suporte e comentários de NPS. É qualitativa e, muitas vezes, vaga. Um exercício de VoC pode revelar "gostaria que o processo de pedido fosse menos confuso", que é uma necessidade, mas não uma especificação mensurável.

A árvore CTQ fica logo depois do VoC. Ela pega essa linguagem bruta do cliente e a estrutura na hierarquia de três níveis. O resultado da árvore é uma lista de CTQs mensuráveis com metas definidas. Esses CTQs alimentam, então, o plano de medição.

KPIs são métricas operacionais que a empresa acompanha continuamente. Eles podem ou não corresponder aos CTQs do cliente. A árvore é como você confirma esse mapeamento. Se um KPI não remete a um driver e a uma necessidade na árvore CTQ, ele está acompanhando algo interno que talvez não importe para o cliente.

Quality Function Deployment (QFD) (a Casa da Qualidade) pega os CTQs e os mapeia para parâmetros de design ou de processo. A árvore CTQ vem primeiro; o QFD é o que você faz com o resultado dela.

Em um projeto DMAIC, a árvore se encaixa na fase Define, o VoC alimenta a árvore, e a árvore alimenta o sistema de medição na fase Measure.

Erros Comuns

Parar no Nível 2. As equipes costumam definir drivers e chamá-los de CTQs. "Velocidade de processamento do pedido" é um driver, não um CTQ. É preciso avançar mais um nível e atribuir uma meta numérica.

Criar CTQs que não podem ser medidos. Se sua equipe não tem um sistema capaz de capturar dados sobre um CTQ, ele ainda não é um CTQ funcional. Corrija a lacuna de medição ou revise a especificação.

Confundir metas de processo internas com CTQs do cliente. "Reduzir o tempo de separação no armazém em 15%" é uma meta operacional interna. Ela pode apoiar um driver, mas não é um CTQ, a menos que o cliente se importe especificamente com o tempo de separação. Os CTQs vivem no referencial do cliente, não no do dono do processo.

CTQs em excesso. Uma única necessidade pode ser sustentada, de forma realista, por seis a dez CTQs. Equipes que geram trinta CTQs por necessidade geralmente estão misturando necessidades diferentes, e o escopo do projeto se expande demais. Mantenha a árvore enxuta. Um CTQ bem definido vale mais do que cinco sobrepostos.

Pular a validação. Uma árvore CTQ construída em uma sala de reunião, sem checagem com dados reais de clientes, é apenas uma hipótese. Sempre verifique os drivers e CTQs com dados reais de VoC antes de fechá-los.

Como Construir uma Árvore CTQ

Reúna evidências dos clientes, declare uma necessidade de resultado, identifique os drivers, defina CTQs mensuráveis e valide cada meta.

Como Construir uma Árvore CTQ representado como uma linha de montagem panorâmica de cinco etapas que transforma cartões de citações de clientes em um token de necessidade, ramos de drivers, medidores e um check coral de validação; números de etapa esparsos de 1 a 5.

Etapa 1: Reúna Dados de Voz do Cliente

Antes de desenhar qualquer coisa, colete informações reais dos clientes. Entrevistas, pesquisas, registros de reclamações, comentários de NPS, gravações de chamadas de vendas. Você precisa de pelo menos 20 a 30 declarações distintas de clientes para identificar padrões. Agrupe declarações semelhantes em temas.

Etapa 2: Identifique a Necessidade do Cliente

A partir dos seus temas de VoC, escreva uma declaração de necessidade na linguagem simples do cliente. Mantenha-a no nível de resultado. "Receber meu pedido rápido e intacto" é uma boa declaração de necessidade. "Ter uma taxa de entrega no prazo de 98%" já começa a prescrever a solução.

Uma árvore CTQ por necessidade. Se você tiver três necessidades distintas, construa três árvores. Não as combine.

Etapa 3: Faça um Brainstorm dos Drivers

Pergunte: quais fatores, se tiverem bom desempenho, atenderiam a essa necessidade? Os drivers são categorias de desempenho, ainda não medições. Para "receber meu pedido rápido e intacto", os drivers podem ser: velocidade de processamento do pedido, desempenho da transportadora, integridade da embalagem e visibilidade do rastreamento.

Busque de dois a cinco drivers por necessidade. Menos que isso provavelmente significa que algo está faltando. Mais de cinco pode indicar que alguns dos seus drivers são, na verdade, CTQs disfarçados.

Etapa 4: Defina CTQs Mensuráveis com Metas

Para cada driver, defina de dois a quatro CTQs. Cada CTQ precisa ter:

  • Uma característica clara e mensurável (por exemplo, "tempo de trânsito em dias úteis")
  • Um valor-alvo (por exemplo, "3 dias")
  • Um limite de especificação (por exemplo, "no máximo 5 dias para 99% dos pedidos")

Verifique o diagrama SIPOC do seu processo neste momento. Ele ajuda a confirmar quais saídas do processo realmente correspondem a cada CTQ, para que você saiba onde coletar os dados.

Etapa 5: Valide com os Clientes

Leve seus CTQs preliminares de volta a uma amostra de clientes. Pergunte: se atingirmos essa meta de forma consistente, isso atenderia à sua necessidade? Se eles derem de ombros, o CTQ está errado. Se disserem que sim, mas com uma ressalva, você tem um novo driver ou uma especificação mais rígida.

Essa etapa evita a falha mais comum em projetos: equipes passam semanas otimizando uma métrica com a qual os clientes, na verdade, não se importam.

Etapa 6: Priorize e Delimite o Escopo do Projeto

Nem todo CTQ vira o foco de um projeto. Classifique os CTQs pelo impacto na satisfação do cliente e pela diferença atual entre desempenho e meta. Os CTQs com a maior lacuna e o maior impacto no cliente são o ponto de partida. Use os cálculos de DPMO e nível sigma para quantificar a taxa de defeitos atual em relação a cada especificação de CTQ.

Exemplo de Árvore CTQ

Este exemplo acompanha uma empresa de entrega de comida online respondendo ao feedback de clientes de que "a entrega parece imprevisível e lenta".

Exemplo de Árvore CTQ representado como um pacote de entrega compacto que se ramifica em um timer de cozinha, um relógio de rota do entregador, um checklist de precisão e um sinal de rastreamento, cada um terminando em um pequeno mostrador de medição; um pino coral de pontualidade.

Nível Item Meta / Especificação
Necessidade Entrega previsível e rápida
Driver 1 Velocidade de preparo do pedido
CTQ 1.1 Tempo entre a confirmação do pedido e o pedido pronto para retirada no restaurante Menos de 15 minutos para 95% dos pedidos
CTQ 1.2 Taxa de precisão do pedido na retirada (itens corretos) 99,5% ou mais
Driver 2 Desempenho de trânsito do entregador
CTQ 2.1 Tempo de entrega porta a porta para pedidos padrão Menos de 35 minutos para 90% dos pedidos
CTQ 2.2 Taxa de entrega no prazo em relação ao ETA informado Dentro de 5 minutos do ETA para 85% dos pedidos
Driver 3 Visibilidade do rastreamento
CTQ 3.1 Frequência de atualização de status durante a entrega ativa Pelo menos a cada 3 minutos
CTQ 3.2 Notificação enviada quando o entregador está a 2 minutos de distância 100% dos pedidos

Uma equipe de projeto avaliaria, então, o desempenho atual em relação a cada especificação de CTQ para determinar quais estão falhando, em que grau e em quais partes do processo. Isso alimenta diretamente a fase Measure do DMAIC, onde a capacidade do processo (Cpk) de cada CTQ é calculada.

Melhores Práticas

Mantenha a declaração de necessidade na voz do cliente. Resista à tentação de "limpá-la" para uma linguagem corporativa. "Entrega rápida e previsível" permanece mais próxima do cliente do que "minimizar o tempo de ciclo do pedido até a porta".

Date suas árvores. As expectativas dos clientes mudam. Uma árvore CTQ construída para um contexto de e-commerce de 2022 pode ter metas frouxas demais para os padrões de 2026. Revise os CTQs anualmente ou sempre que os dados de VoC mostrarem uma mudança nos direcionadores de satisfação.

Vincule cada CTQ a uma saída do processo. Se você não consegue nomear a etapa do processo que produz a saída do CTQ, não consegue medi-lo. Usar um diagrama SIPOC como documento complementar torna essa etapa rápida.

Não pule o plano de medição. Um CTQ sem um plano de coleta de dados é apenas um desejo. Antes de finalizar a árvore, confirme se a fonte de dados, a frequência de medição e o responsável já estão definidos.

Envolva a equipe de processo na Etapa 3. Drivers levantados apenas por líderes de projeto tendem a ignorar as realidades operacionais que a equipe de linha de frente conhece. Sessões mistas produzem conjuntos de drivers melhores.


Traduzir necessidades do cliente em especificações mensuráveis é a base de todo projeto de melhoria de qualidade. Sem essa tradução, as equipes melhoram as coisas erradas. Com uma árvore CTQ em vigor, cada métrica do projeto se conecta a algo que um cliente real disse importar, e isso é o que diferencia o trabalho de processo que realmente move os índices de satisfação do trabalho de processo que só move números.

Leituras relacionadas

About the author

Linh Ngo

Linh Ngo

Customer Success Operations Manager

Linh Ngo is Customer Success Operations Manager at Rework, focused on AI-led process automation for operations teams, especially order fulfillment and finance workflows. Linh writes about process management and the AI productivity tools that take manual steps out of daily operations, so teams can see where work stalls and fix the process before adding headcount.