Atendimento N1 · handoff

O N1 é o primeiro atendimento da assistência 24h. Alguém liga com o carro parado e uma pessoa do outro lado da linha tem que descobrir quem é, se tem cobertura, o que aconteceu e o que vai ser acionado — enquanto o cliente espera.

Este protótipo é o desenho dessa tela. Ele é navegável e funciona: dá para buscar uma placa, montar um serviço, receber uma crítica da apólice e abrir o atendimento até o fim. Os dados são de mentira, as regras não.

O que está aqui foi construído em cinco rodadas com a operação, entre agosto e setembro. Cada versão derrubou alguma coisa da anterior. O que sobrou é o que passou por quem atende.

Até 18 de setembro este projeto se chamava Acionamentos N1. Estava errado, e o Anderson corrigiu na reunião: acionamento é outra fase. As três não são sinônimos — são três células, três filas e três times.

• Não é o N2. O acionamento eletrônico — escolher prestador, geolocalização, rating — é outro fluxo e ainda não começou.

• Não é o painel de controle do gestor. O kanban de filas críticas que o Anderson mostrou é outra tela, para outra pessoa. Está descrito na seção 13.

• Não é o faturamento. Como a assistência vira cobrança é assunto da Elaine e da Sabrina, e está em aberto.

Quase toda decisão deste projeto saiu da mesma frase, dita pelo Anderson na reunião de 11 de setembro:

O analista não decide, ele só consome. Se ele tiver que tomar alguma decisão, é porque está fora daquilo que o cliente sinalizou — e aí vai ser pendenciado para o cliente decidir.

Isso vira regra de tela: tudo que o sistema já sabe, o sistema responde. O atendente não classifica o que a base já classificou, não calcula o que dá para calcular, não escolhe para quem mandar um pedido que tem fila própria.

Quando a gente revisou o fluxo procurando o que estava errado, quatro dos cinco problemas tinham a mesma forma: uma decisão que o sistema já sabia tomar estava sendo cobrada do atendente, no meio da ligação, com o cliente esperando.

A outra frase que organiza o desenho também é do Anderson, e é sobre expectativa:

Se eu desço para preencher, eu gero uma expectativa nele.

Quem responde meia dúzia de perguntas sobre para onde quer o guincho entende que o guincho vai sair. Por isso o atendimento para no momento em que aparece um impedimento, em vez de continuar coletando dados de um serviço que talvez não aconteça.

Cada etapa responde uma pergunta. Ela só abre quando a anterior está resolvida — o atendente vê o que precisa agora, não o formulário inteiro.

Em qualquer momento a barra inferior diz o que falta e leva ao campo. Ela nomeia o primeiro item pendente com a mesma palavra que está na tela — se o formulário pergunta "o que aconteceu com o veículo", a barra cobra isso, não "tipo de pane".

É a etapa mais densa e a que mais mudou. Três coisas acontecem aqui: achar o item, ler a cobertura para o cliente, e lidar com o que a base critica.

Não existe botão de confirmar vínculo. O vínculo é derivado: existe quando há cliente, contrato, item e — nos contratos que pedem — um veículo cadastrado por inteiro. Se qualquer um cair, ele se desfaz sozinho.

Assim que o item é encontrado, o card mostra todos os serviços do contrato, com o que resta de cada um. Os que resolvem a ocorrência já marcada vêm primeiro.

Isto é a conferência: a leitura de uma vez, com o cliente na linha. É diferente da consulta, que acontece quando a pergunta volta no meio da conversa e mora atrás do botão Apólice e coberturas, presente em todas as etapas.

Quando a base devolve o item, devolve junto a situação do contrato. Se alguma coisa impede o atendimento, o sistema levanta uma crítica e o atendimento para ali.

As três são a mesma coisa do ponto de vista do fluxo. Não existe uma lista de saídas diferentes para cada uma: o sistema avisa, o operador avalia, e ele decide entre dois caminhos.

A crítica tem duas frases, diferentes de propósito. O detalhe é o motivo verdadeiro e fica na tela, para o operador decidir o caminho. O script é a única frase que pode sair pela boca.

O primeiro dos dois caminhos. A assistência é criada com número, fica pausada e entra na fila de liberação comercial. Nada mais é coletado até a resposta.

Ele não escolhe quem decide, não encaminha o pedido e não espera a resposta com o cliente na linha.

Decidido em 18/09, pelo Anderson: a fila de liberação é do gestor, não do analista. Ela não aparece no painel de quem atende.

Isso quem vai estar olhando é o gestor. Isso tem que estar na fila do gestor. É o gestor que vai ter que fazer a gestão do que trava.

Isso derrubou um card do painel do N1 — o "Aguardando liberação comercial" existia ali e saiu. Não é informação do analista: ele não vai atuar nela, e o que ele não vai atuar só ocupa espaço e produz ansiedade.

Quem monitora a fila abre o caso, lê o pedido, liga para quem decide, anexa a evidência e escreve o parecer.

A liberação pode voltar horas depois. Se o analista que pausou já saiu do turno, o atendimento vai para a fila e é atribuído a quem estiver disponível. Por isso tudo o que foi coletado até a pausa fica gravado no caso, e não na cabeça de quem atendeu: quem retoma precisa entender o atendimento sem ter participado dele.

Se não for o horário dele, ele já saiu. Vai ter que ter outro analista que vai assumir a assistência.

O segundo caminho. Negar não é sair da tela nem fechar o navegador: a assistência é cancelada, com motivo escolhido numa lista fechada e o registro do que foi dito ao cliente.

A lista é fechada pelo mesmo motivo da lista de liberação: para a operação conseguir contar. Cancelamento escrito à mão vira "cliente desistiu" em quase todos os casos, e some o dado de quantas apólices vencidas chegam por mês.

Cinco motivos, numa pergunta só: pane mecânica, pane elétrica, acidente, colisão e pane seca. Eram quinze chips em duas fileiras; a operação cortou para estes.

Seis classificações: criança, idoso, condição especial, veículo em risco, risco agravado e geral. O sistema lê o relato e sugere — se o texto diz "tem uma criança no carro", ele sugere criança.

A etapa abre com os serviços que o motivo recomenda, cruzados com as coberturas da apólice. O catálogo completo fica atrás de um link.

O sistema decide a partir da cobertura, do saldo, do limite e do modelo de cobrança, e apresenta o resultado com a explicação. O atendente lê, não escolhe.

Quando a rota passa do limite, a tela mostra a conta: os quilômetros da rota, os que a apólice cobre e a diferença.

Um campo só. O atendente cola o que o cliente mandou — endereço escrito, a coordenada do WhatsApp ou um Plus Code — e o sistema entende sozinho qual é. Pedir para ele escolher o formato antes era trabalho à toa.

Quem está com o veículo pode não ser quem ligou. A resposta é dada uma vez, na etapa 3, e todos os serviços herdam. O card mostra quem o prestador vai procurar e oferece o escape para quando, naquele serviço, for outra pessoa.

A revisão é a ordem: tudo que foi registrado, na sequência em que foi montado, em blocos numerados. O número serve para apontar — dá para dizer "olha o bloco 3" numa call sem descrever a posição na tela.

A saída Assistência não fica desabilitada por pendência externa. O atendente sempre segue o mesmo caminho; quem calcula o status é o sistema, e a tela avisa antes do clique com que status a assistência vai nascer.

Cada nó do caminho fica gravado: o que foi perguntado, o que havia como opção, o que foi respondido, quem respondeu, a que horas e o que aquilo causou. Regravar o mesmo nó não cria outro — atualiza e conta a mudança.

Isso serve para o N2 que pega o caso e para quem auditar seis meses depois. A pergunta nunca é "o que foi preenchido", é "quem decidiu isso, e o sistema tinha sugerido outra coisa?"

Vinte situações que abrem por link direto, cada uma num estado específico. É por aqui que se testa sem refazer o atendimento inteiro — e é por aqui que se discute um caso numa reunião sem descrever a tela em palavras.

Eles existem porque o trabalho vive nos casos que ninguém mapeou. A tela feliz é fácil; o que decide o desenho é o item que está em dois contratos e a frota de cinquenta veículos.

Isto não é uma lista de melhorias. São decisões que não são de design e que alguém precisa tomar antes ou durante o desenvolvimento. Cada uma tem a pergunta exata e de quem é a decisão.

A lista existe para o que não foi decidido não virar culpa de ninguém depois. Quando o desenvolvimento esbarrar num destes pontos, a resposta é "está aqui, esperando negócio decidir" — não "o design não pensou nisso".

Fica uma lista de to-do aí pra gente ir validando. Até para a gente não esquecer as coisas que precisa validar, porque depois passa para o N2, esqueceu um monte de coisa no N1 e ninguém anotou.

• Onde vive a fila de liberação. É do gestor, não do analista — o Anderson fechou na reunião. Já aplicado: o card saiu do painel do N1 e a seção 6 descreve a fila do gestor. O que continua aberto é a tela dessa fila, que virou escopo próprio (seção 13).

• Quanto disso acontece. Cerca de 1,5% dos casos precisam de aprovação. Não muda a regra, muda a prioridade: o caminho crítico precisa existir e não precisa ser otimizado.

A reunião de 18/09 abriu duas telas novas e um mecanismo. Nenhum dos três está desenhado — estão aqui para ficarem registrados enquanto ainda são fáceis de mudar, e para ninguém confundir com o que já está de pé.

O painel de quem atende, vinculado ao login. Não é a fila de entrada que já existe: é o que o analista precisa saber sobre o próprio dia enquanto trabalha.

• O dia dele. Quantos atendimentos abriu hoje, se está dentro ou fora da meta diária, e o que a monitoria já apontou.

• Só o que é dele. O que ele não vai atuar não entra — foi por isso que a liberação comercial saiu daqui.

• O que ele não conseguiu fechar sai da mão dele. Vai para a fila de quem faz gestão: o sênior da célula ou a coordenação.

Eu estou fazendo um cockpit do analista. Ele está trabalhando e tendo uma informação dele, vinculada ao login dele, com os dados que ele precisa olhar. Tudo o que ele não conseguiu fazer vai para uma outra fila que alguém vai fazer gestão.

Aberto aqui: a Lais lembrou que ele precisa consultar assistências que não são dele para atender uma ligação de retorno. Isso está na lista da seção 12, porque decide o que é painel e o que é busca.

O kanban que o Anderson mostrou não é a tela do N2 — foi a primeira coisa que ele corrigiu. É um painel de controle que consolida as filas críticas das três células e mostra onde a operação está travando.

Quem olha: o sênior de cada célula vê as pendências da célula dele; a coordenação vê tudo e remaneja gente entre células quando uma fila sobe. A operação tem cerca de 20 pessoas em 3 células, com um sênior na ponta de cada uma.

• A cor é o prazo. Verde dentro do SLA, laranja para estourar, vermelho estourou ou é crítico. A cor do card inteiro, para ler de longe.

• O ícone é o motivo. Aguardando foto, aguardando liberação comercial, aguardando prestador. Motivo e urgência são duas perguntas diferentes e não podem dividir o mesmo canal.

Essa separação não é preciosismo: o painel vai para as TVs da operação. Se cor e motivo estiverem misturados, de longe não se lê nem um nem outro.

A ideia é pegar isso e colocar nas TVs aqui na operação. Bato o olho na TV, sei que tem cards vencendo, e a gente consegue atuar mais rápido.

Hoje o analista do N2 escolhe a assistência que vai pegar. O Anderson quer o contrário: o que o N1 abre cai num balde e um distribuidor entrega para quem está logado na célula.

Ele não vai poder ir lá e buscar igual a gente faz hoje, pega um, pega outro, não. Vai ter que ter um distribuidor que vai jogando conforme vai entrando.

• Status de disponibilidade. Para distribuir é preciso saber quem está livre: em atendimento e disponível precisam ser visíveis, no analista e para quem atribui.

• Quem volta não é quem saiu. Atendimento que foi e voltou não retorna para o mesmo analista — vale para a liberação comercial e vale aqui.

O motor é do desenvolvimento. O que é meu: a tela precisa deixar claro que a assistência chegou para o analista, e não que ele a escolheu. São duas sensações diferentes de trabalho e o desenho muda.

• Teste de usabilidade do N1, com a Lais reservando operadores e eu observando sem conduzir — para ver onde clicam primeiro.

• Listagem de scripts, o que o atendente diz em cada situação.

• Layout do N2, aproveitando o padrão de cards que já existe no sistema.

O protótipo é um arquivo HTML só, sem servidor. Abre no navegador e funciona offline — os ícones caem para um desenho local quando não há internet.

Cada regra deste documento tem um teste que clica a tela de verdade — não chama a função por dentro. Um teste que chama a função direto passa mesmo depois que o botão sumiu da tela.

Nada aqui é biblioteca nova. A tipografia é a Ubuntu da marca, os ícones são os do arquivo de iconografia do sistema, e as cores saem dos tokens que já existiam.

O documento de regra de negócio é o lugar. Ele está em Word de propósito: dá para comentar no parágrafo e devolver. O que eu preciso é o formato que o Anderson propôs na reunião — "se chegar nesse cenário, o que a operação vai fazer" — caso a caso.

Se a dúvida for de tela e não de regra, o protótipo é melhor: abra o cenário e me diga o que está errado nele.