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

Diagrama de árvore CTQ mostrando três níveis, da necessidade do cliente aos requisitos de qualidade mensuráveis

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.

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.

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

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".

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.

Perguntas Frequentes

Qual é a diferença entre um CTQ e um KPI?

Um CTQ é uma característica mensurável definida sob a perspectiva do cliente, com uma meta específica ligada à satisfação do cliente. Um KPI é uma métrica de desempenho interna que a empresa acompanha para a gestão operacional. Os CTQs vêm do cliente; os KPIs vêm do negócio. Uma operação bem projetada tenta fazer com que seus KPIs remetam aos CTQs, mas muitos KPIs existem por razões que não têm nada a ver com o que os clientes valorizam.

Quantos CTQs um projeto Six Sigma deve ter?

Um único projeto DMAIC ou DMADV costuma focar em um a três CTQs. Se sua árvore gerar quinze CTQs sob uma única necessidade, isso é normal para a árvore em si, mas você então priorizaria os mais críticos para o escopo do projeto. Tentar fechar uma lacuna de desempenho em muitos CTQs ao mesmo tempo dilui o foco da equipe e dificulta isolar as causas raiz.

É possível usar uma árvore CTQ fora do Six Sigma?

Sim. A ferramenta funciona em qualquer lugar onde você precise traduzir requisitos qualitativos em especificações mensuráveis: desenvolvimento de produto, design de serviços, QA de software, integração de fornecedores na cadeia de suprimentos. A metodologia tem origem no Six Sigma, mas o problema que ela resolve (transformar necessidades vagas em especificações mensuráveis) é universal.

Onde a árvore CTQ se encaixa no DMAIC?

Ela pertence à fase Define, depois da pesquisa de VoC e antes de o termo de abertura do projeto ser finalizado. As saídas do CTQ se tornam as variáveis Y no termo de abertura e as métricas-alvo para a fase Measure. Se você estiver usando DMADV para projetos de design, a árvore também se encaixa na fase Define ali.

Qual é a diferença entre um driver e um CTQ?

Um driver é uma categoria de desempenho que influencia a satisfação do cliente. Ele explica por que uma necessidade é ou não atendida, mas não é mensurável por si só. Um CTQ é a característica específica e mensurável dentro de um driver, com uma meta e um limite de especificação. "Velocidade de entrega" é um driver. "Tempo porta a porta abaixo de 35 minutos para 90% dos pedidos" é um CTQ.


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

Tara Minh

Tara Minh

Senior Operations & Growth Strategist

Tara Minh is Senior Operations & Growth Strategist at Rework, helping B2B SaaS leaders scale without breaking their teams. With 8+ years in revenue operations and process optimization, Tara turns messy workflows into systems people actually follow. Readers get practical frameworks they can use to cut waste, align teams, and grow on purpose.