Service Design: como impedir que um pedido incompleto entre no fluxo
O time de treinamento de CX recebia solicitações por um formulário no Jira Service Management. Na teoria, o formulário coletava o briefing. Na prática, ele não exigia quase nada. O resultado recaía inteiro sobre quem recebia. O time de treinamento fazia a descoberta que deveria ter vindo do solicitante, coletava material durante a execução e dependia de conversa informal para saber o que estava construindo.
Problema
O problema era invisível para quem o causava
Para quem abria o pedido, enviar o formulário era o fim do trabalho. Para o time de treinamento, era o começo de um projeto sem informação.
Foi observado que o solicitante do treinamento com material incompleto não agia de má-fé: tinha uma demanda legítima e zero visibilidade do custo de retrabalho que gerava.
O treinamento de antecipação salarial
- 01
O público-alvo não foi especificado no briefing inicial;
- 02
A dor real não foi descrita, apenas o tema;
- 03
Os materiais foram coletados durante a execução;
- 04
Informações operacionais chegaram verbalmente, sem rastro.
Um único ponto de entrada, com blocos que aparecem conforme o tipo de pedido (Reciclagens, Novos Produtos), em vez de formulários paralelos que ninguém sabia qual usar
Saí do campo genérico de descrição e passei a perguntar qual comportamento deveria mudar depois do treinamento. Quem não sabe responder isso ainda não tem um briefing
Nível de conhecimento do público e contexto da demanda deixaram de ser opcionais
O prazo passa a contar a partir da entrega completa, não da abertura do chamado. É a decisão que devolve o custo para quem o gera
Campo explícito de conteúdo validado ou não validado, com condição e justificativa.
Solução
Especificação, não só proposta
Entreguei o redesenho pronto para implementar: label final de cada campo, tipo de campo, regra condicional e ordem de exibição.
Duas restrições que assumi de propósito. Manter o layout do portal, alterando apenas textos e lógica, para que a mudança não dependesse de rebuild. E preservar o que já funcionava, como anexos, "abrir em nome de" e date picker, porque a operação já tinha hábito formado neles.
Trocar Rich Text por campo estruturado onde a formatação não agregava foi o que mais reduziu fricção: resposta estruturada é mais rápida de dar e infinitamente mais fácil de ler depois.
Prazo previsto (5 dias) + (ciclos de retrabalho × custo de cada ciclo) = Prazo real
O custo do problema, em números.
- 01
4 analistas, 5 dias úteis de prazo por projeto, até 5 projetos por mês.
- 02
Cada projeto passava por 3 a 6 rodadas de retrabalho de conteúdo, de cerca de 1 dia cada
- 03
Somando: 5 dias previstos + 3 a 6 dias de refação = 8 a 11 dias reais por projeto
- 04
No mês, 15 a 30 dias-pessoa gastos refazendo material que deveria ter chegado pronto
- 05
O custo não parava na agenda. O desgaste dos ciclos fazia erros passarem: a maioria dos treinamentos chegava ao aluno com report de problema de conteúdo
do tempo de cada projeto era refazer conteúdo que deveria ter chegado pronto pelo solicitante
o prazo previsto. Projetos com SLA de 5 dias levavam o dobro para sair
rodadas de retrabalho, no pior caso, até o material ficar utilizável
Cada decisão do formulário mira uma etapa dessa cadeia:
- 01
Prazo a partir da entrega completa dos materiais. Ataca a raiz: o solicitante deixa de ganhar tempo abrindo o pedido incompleto, porque o relógio não começa a correr
- 02
Checklist com link obrigatório. Elimina o "mando depois" que virava coleta durante a execução
- 03
Público-alvo e contexto obrigatórios. Removem os dois campos cuja ausência mais gerava refação
- 04
Governança de conteúdo validado. Impede que material sem aprovação entre no fluxo e precise ser refeito depois
O que aprendi
O design mais eficiente às vezes não é uma tela melhor, é uma trava. E que quando um processo falha de forma repetida, quase sempre há alguém sendo racional dentro de um sistema mal desenhado. Achar essa pessoa e entender o incentivo dela rende mais que qualquer redesenho visual.