# Retro 2N 05/08/2027 # Retro da Squad — Como a gente conversa com o cliente **Squad:** Suporte N1 — Novo Avanço **Squad Leader:** Wevert Ribeiro **Data:** agosto de 2026 **Duração:** 60 minutos **Formato:** discussão estruturada em quatro fases do atendimento por chat
---
## 1. Por que essa retro A squad vinha de várias retros com o tema Inteligência Artificial — o novo papel do suporte, a fronteira entre o que resolvemos e o que escalamos, a revisão crítica do que a IA entrega. Fez sentido voltar o olhar para algo mais elementar e mais nosso: o jeito da squad conversar com o cliente. A leitura foi honesta: quando a IA termina o rascunho, quando o dev não pega o chamado, quando o sistema retorna o que tem para retornar — ainda tem um cliente do outro lado, esperando conversar. Como a gente conduz essa conversa é o que sobra depois de todo o resto. E, para a squad de suporte N1 do Novo Avanço, esse resto é o trabalho. O objetivo da retro foi refletir sobre atendimento por chat especificamente — canal principal com nossos clientes supermercadistas — e sair com um playbook curto do jeito da squad de atender. ## 2. Como conduzimos A conversa foi estruturada em torno das quatro fases que existem em todo atendimento, mesmo quando não paramos para nomear: 1. **Receber** — abrir a conversa, criar o mínimo de rapport, mostrar que tem alguém do outro lado. 2. **Entender** — compreender o problema real, não só o sintoma descrito pelo cliente. 3. **Orientar e resolver** — traduzir a solução do mundo do sistema para o mundo do supermercadista, com passo a passo claro e gestão honesta de expectativas. 4. **Fechar e dar retorno** — confirmar que resolveu, combinar retorno se ficou pendente, encerrar com humanidade. Cada fase teve seu bloco de discussão, com boas práticas e cuidados apresentados como ponto de partida e o time reagindo a partir da experiência real do dia a dia. Antes de entrar nas fases, foi feita uma abertura curta lembrando as particularidades do canal chat — que ele não é telefone, não é presencial e não é e-mail. O tom mora no texto, o cliente está no meio do movimento da loja, tudo fica registrado, a ambiguidade é o inimigo e a distância técnica entre a squad e o supermercadista costuma ser grande. ## 3. O que foi discutido Cada bloco teve o mesmo formato: uma provocação inicial, discussão aberta com casos reais trazidos pelos analistas, e uma consolidação do que a squad considera boa prática versus o que quer evitar. O time chegou a **concordância geral em todos os quatro tópicos**, apresentando casos concretos do próprio trabalho para cada fase. Isso é importante de registrar: não é um playbook imposto de cima — é o alinhamento do que já é feito de forma consistente na squad, agora escrito e visível. ### 3.1. Fase 1 — Receber O ponto de convergência foi a rejeição ao padrão de abertura robótico. Cumprimentar o cliente pelo nome, se apresentar rapidamente, deixar espaço para o cliente contar o problema sem cortar — essas são as marcas do que o time considera abertura boa. Do lado oposto ficaram os padrões a evitar: pular a saudação e ir direto ao “qual o problema?”, usar respostas padronizadas que soam robô, presumir que o cliente já sabe quem está do outro lado, prometer solução antes mesmo de entender o cenário. ### 3.2. Fase 2 — Entender A discussão desta fase foi sobre a distância entre o sintoma que o cliente descreve e o problema que ele de fato tem. Casos apresentados reforçaram que o cliente varejista descreve o que sente, não o que a documentação técnica esperaria. Cabe ao analista chegar no problema — e o caminho é perguntar bem. O time consolidou como boas práticas: perguntar contexto específico (qual tela, qual nota, qual cliente, quando começou), pedir print ou número da nota como evidência, repetir o problema com as próprias palavras para confirmar entendimento, perguntar o que o cliente já tentou antes de propor caminho novo. Os cuidados: não assumir que o cliente descreveu com precisão técnica, não responder antes de confirmar o cenário, não jogar um balão gigante de perguntas de uma vez, não confundir sintoma com causa. ### 3.3. Fase 3 — Orientar e resolver Foi o bloco de discussão mais rica, com maior número de casos apresentados. O tema central: adaptar a linguagem do sistema para a linguagem do cliente, especialmente quando o cliente não é técnico. Alinhamentos que emergiram: passo a passo numerado, uma coisa por mensagem em vez de bloco cheio, ser franco quando o problema é do sistema (sem empurrar responsabilidade) porém não passando insegurança para o cliente sobre o sistema, dizer que vai checar quando não sabe (nunca inventar), gerenciar expectativa de tempo com honestidade. Os cuidados foram tão importantes quanto: evitar jogar cinco instruções em um único balão, evitar jargão técnico sem explicação (CST, Banco, NCM, endpoint), não prometer prazo curto para caso que exige análise mais funda, não escorregar do problema quando o erro é do sistema, não inventar caminho só para parecer que sabe. ### 3.4. Fase 4 — Fechar e dar retorno O ponto que gerou mais reflexão foi sobre o que acontece depois que o analista acha que resolveu. O time convergiu em que fechar bem é tão importante quanto orientar bem — se o cliente sai com dúvida sobre se o problema foi resolvido, provavelmente ele volta, e volta em pior humor. As boas práticas consolidadas: confirmar que funcionou antes de encerrar, combinar retorno com data e hora concretas quando o caso fica pendente, reconhecer sem se justificar demais quando a demora foi da nossa parte, deixar um resumo do que foi feito no chat como histórico útil, fechar com humanidade — agradecer e desejar bom trabalho. Cuidados que o time quer evitar: encerrar antes de confirmar entendimento, prometer “volto já” e sumir por horas, se justificar demais quando a demora foi nossa, fechar seco com “resolvido, tchau”, deixar o cliente sem saber se vai ter retorno ou não. ## 4. Playbook adotado A consolidação da retro é este playbook curto — dois princípios por fase, do jeito que a squad decidiu registrar como norma de atendimento. ### Receber • Cumprimentar humano, com o nome do cliente quando dá para saber. • Dar espaço para o cliente contar o problema sem cortar. ### Entender • Perguntar contexto antes de sair respondendo. • Repetir o problema com nossas palavras para confirmar entendimento. ### Orientar • Uma coisa por mensagem, no idioma do cliente. • Se não sabe, checa. Nunca inventa. ### Fechar • Confirmar que funcionou antes de encerrar. • Se ficar pendente, combinar retorno com data e hora concretas. ## 5. Compromisso individual Cada analista fechou a retro com um foco pessoal para as próximas duas semanas — em qual das quatro fases quer prestar mais atenção e qual o próximo passo prático que vai dar. ## 6. Sentimento geral O tom da conversa foi sereno e prático — sem defensividade e sem autocrítica excessiva. O time reconheceu que já faz muitas dessas boas práticas de forma intuitiva, e o valor da retro foi tornar visível o que era tácito, escrever o que era feeling, e alinhar o padrão da squad no ponto em que naturalmente já convergia. Uma observação que atravessou a discussão inteira: o sistema é o meio; a conversa é o trabalho. O que faz o atendimento bom não é resolver rápido — é o jeito como o cliente sai da conversa.
---
*Documentação elaborada em agosto de 2026 pelo Squad Leader Wevert Ribeiro para registro na base de conhecimento da squad de Suporte N1 — Novo Avanço.*