Um processo de decisão
The Kanso Filter.
Seis perguntas antes de uma mudança ser entregue.
Aplicamos isso antes de recomendar qualquer mudança em uma equipe de atendimento. A maioria das mudanças que falham não falha na construção. São entregues sem uma resposta clara a uma dessas seis perguntas. O filtro força essas respostas antes do início do trabalho, enquanto ainda é barato agir sobre elas. Use-o em suas próprias decisões, em propostas de fornecedores e nas nossas.
Por que isso existe
Começou como um registro de trabalho que não foi a lugar nenhum.
Continuávamos vendo mudanças sendo entregues que adicionavam um fluxo de trabalho, uma integração, uma tela, e seis meses depois, os números pelos quais a equipe era avaliada não haviam se movido. O esforço era real. O resultado, não. Então escrevemos as perguntas que, em retrospecto, teriam interrompido cada uma dessas mudanças antes de alguém construí-las. Essa lista é o filtro. É deliberadamente direto: se uma mudança não consegue responder a essas perguntas, a atitude honesta é não a fazer.
Cada uma antecipa um modo de falha antes da entrega.
01
Elimina uma etapa?
Etapas são cliques, campos de formulário, consultas, transferências, decisões que a equipe precisa tomar.
02
Move uma métrica que você controla?
Tempo de atendimento, esforço do cliente, CSAT, resolução no primeiro contato, valor do ciclo de vida. Escolha aquela pela qual a equipe é avaliada, não a mais fácil de contar.
03
Melhora precisão ou qualidade?
Mensurável. Nomeie a métrica antes da implantação.
04
Minimiza a carga de manutenção?
Pese a manutenção contínua, os pontos únicos de falha e a dívida técnica que a equipe carrega depois, não apenas o tempo que economiza.
05
O nativo supera o customizado?
Os roadmaps das plataformas evoluem mais rápido do que o código customizado.
06
Você consegue nomear a métrica que deve mover e como vai medi-la?
Nomeie a medida e a janela antes de começar, para que possa dizer depois se funcionou.
O que fazer a seguir
Decida com base em melhoria material, não em custo economizado.
Uma mudança justifica seu lugar quando move uma métrica que você controla o suficiente para ser percebida. Custo economizado é uma entrada, não o teste. Se você não consegue nomear a métrica, a meta e a janela antes de começar, não consegue dizer depois se a mudança funcionou, e é assim que uma mudança falha silenciosamente: ninguém definiu a medida que teria mostrado isso. Então falhe rápido. Elimine a ideia fraca na etapa das perguntas, onde custa uma tarde, não depois da construção, onde custa um trimestre. O ponto do filtro é gastar essa tarde.
Execute agora
Avalie sua mudança.
Responda cada pergunta para a mudança que está avaliando. O veredicto é atualizado conforme você avança. Nada que você digitar sai do seu navegador.
01
Elimina uma etapa?
02
Move uma métrica que você controla?
03
Melhora precisão ou qualidade?
04
Minimiza a carga de manutenção?
05
O nativo supera o customizado?
06
Você consegue nomear a métrica que deve mover e como vai medi-la?
Veredicto atual
0 de 6 respondidas com sim
Isso funciona inteiramente no seu navegador. Não vemos suas respostas nem as armazenamos.
Como usar
Percorra as seis perguntas em ordem. Depois decida.
- Todas as seis positivasEntregue.
- Quatro ou cincoEntregue com notas explícitas sobre as lacunas.
- Menos de quatroNão entregue. O escopo não está certo, ou a mudança não retornará o suficiente para justificar a manutenção.
Por que as mudanças falham
Uma mudança raramente falha porque foi mal construída.
Ela falha porque ninguém nomeou a métrica que deveria mover, então ninguém conseguiu verificar depois se isso aconteceu. Ou porque o custo de manutenção cresceu silenciosamente além do valor. Ou porque a plataforma entregou a mesma coisa nativamente três meses depois e o código customizado virou um passivo.
A solução não é mais disciplina no momento de construção. É decidir bem antes de construir. Escolha a métrica que você controla, concorde a meta e a janela, e verifique se o nativo cobre a maior parte do caminho primeiro. Se uma mudança não consegue mostrar uma melhoria material, a decisão certa geralmente é não fazê-la.
Exemplo prático
Implantando IA de auto-etiquetagem no Zendesk.
O filtro aplicado, linha por linha, a uma decisão real.
| # | Pergunta | Veredicto | Observações |
|---|---|---|---|
| 01 | Elimina uma etapa? | Sim | Elimina a etiquetagem manual em 80% dos tickets. |
| 02 | Move uma métrica que você controla? | Sim | Roteamento mais rápido reduz o tempo para a primeira resposta; ~45 seg × 30.000 tickets/mês = 375 horas devolvidas à fila. |
| 03 | Melhora a precisão? | Talvez | Requer comparação com baseline antes do go-live. |
| 04 | Minimiza a carga de manutenção? | Talvez | Retreinamento trimestral do modelo (pequeno), sem novo ponto único de falha, mas precisa justificar seu lugar. |
| 05 | O nativo supera o customizado? | Talvez | Verificar primeiro a auto-etiquetagem nativa do Zendesk. |
| 06 | Você consegue nomear a métrica que deve mover e como vai medi-la? | Sim | Precisão de etiquetagem e roteamento nomeada de antemão, acompanhada semanalmente contra um baseline. |
| Resultado do filtro | Entregue se o nativo não cobrir a taxonomia. Caso contrário, use o nativo. | ||
Tem uma mudança que está avaliando?
Financiamos um número limitado de avaliações de Maturity Mapping para equipes com um problema de atendimento real. Candidate-se com a métrica que deseja mover, e se não for adequado, diremos.