Os devs paravam de codar para investigar erro de pagamento. Agora usam esse tempo para evoluir o produto.

O contexto

A Tempo é um concierge por WhatsApp. O cliente pede alguma coisa, uma IA faz a triagem entre pagamento e tarefa, e se for pagamento ela tenta executar sozinha. Se for tarefa, a IA cobra as informações que faltam até conseguir abrir um cartão no kanban de uma assistente humana.

Eu era a única PM da empresa. Três squads, 12 engenheiros, 30 assistentes de operação e cerca de 400 clientes. O objetivo de negócio daquele período era simples de enunciar: aumentar o valor transacionado na plataforma.

Para acompanhar tudo, as assistentes tinham uma tela de notificações no Cockpit, o painel interno, dividida em três colunas: conversas não lidas, notificações de tarefa, e pagamentos a vencer ou vencidos nos últimos três dias.

O problema que ninguém estava medindo

Essa tela tinha sido desenhada para pagamentos com envio manual. Conforme automatizamos os envios, ela foi ficando inútil, e um pagamento já executado nem saía da lista sozinho.

Mas o buraco maior era outro. Quando um pagamento dava erro, essa informação não aparecia em lugar nenhum acessível. A assistente só descobria se o cliente reclamasse, o que às vezes levava dias. E na maioria das vezes nem era o cliente que percebia primeiro: era o beneficiário dele cobrando o pagamento que não caiu. Ou seja, o nosso cliente ficava mal na frente de um terceiro por causa da nossa plataforma.

Isso empilhava três custos ao mesmo tempo. Confiança do cliente. Dinheiro parado, porque pagamento com erro é valor que não circula. E capacidade de engenharia queimada em investigação em vez de produto.

O discovery, e o que só apareceu sentando do lado

Parte do diagnóstico eu já tinha, porque lia os chamados das assistentes todo dia. Mas o que mudou o diagnóstico de verdade foram cerca de 10 horas sentada ao lado delas, olhando o trabalho acontecer. O processo inteiro levou duas semanas, entre observação, mapeamento dos erros na documentação da instituição financeira, escrita do PRD e validação com sete das trinta assistentes.

As assistentes trabalhavam num monitor só, quase sempre pequeno. Não existia header de notificação visível em qualquer tela. Para resolver um pagamento, elas precisavam sair da Home, abrir a tela do cliente específico, resolver e voltar. Na prática isso virava um monte de aba aberta e a pessoa se perdendo no meio do caminho.

A validação com as sete assistentes mudou o desenho antes de virar código. Eu ia deixar a aba de pagamentos como padrão de abertura para todo mundo. Elas mostraram que o trabalho de cada uma tinha ritmo diferente, e o que passou a valer foi salvar o último filtro usado por pessoa.

O que eu escolhi não fazer

A solução óbvia era um header global de notificações, visível em qualquer tela da plataforma. Era também a solução certa em abstrato, e foi a primeira coisa que eu quis fazer.

Descartei. Construir aquilo do zero naquele momento custava mais tempo de engenharia do que o problema aguentava esperar, num time que já perdia 10 horas por dia com o próprio problema. Então troquei a pergunta: em vez de “qual é a solução ideal”, virou “como eu transformo a tela que já existe em algo que resolva o problema real”.

Foi um trade-off consciente, e ele tem custo. Fora dessa tela, a assistente continua sem ver notificação nenhuma. O header global segue sendo a evolução certa, só que depois, com a fila de engenharia livre e o dinheiro parado destravado.

De tela de aviso a central de operações

A decisão foi mudar o conceito da tela inteira, e não só melhorar a notificação: de um lugar onde a assistente fica sabendo para um lugar onde ela resolve.

• Duas colunas redimensionáveis

  Conversas de um lado, notificações do outro, com abas de tarefas, pagamentos e lembretes. Clicar numa conversa minimiza as notificações, clicar numa notificação minimiza a conversa. Um monitor pequeno passou a caber os dois contextos.

• Resolução sem sair da tela

  A conversa abre ali mesmo, sem ir para a tela do cliente. O pagamento traz todas as ações de resolução disponíveis na hora.

• 28 erros mapeados entre Pix, Boleto e TED

  Fui na documentação da Celcoin e mapeei todo erro possível, com a ação certa para cada um: reenviar, desexpirar, editar informação faltante. Três deles concentravam a maior parte do volume.

• Erro técnico traduzido em ação humana

  O título da notificação já explica o problema, tipo “Pagamento com informações faltando”, com valor, cliente e data visíveis, e a instrução de como resolver logo abaixo. Nenhum código de retorno de API na cara de quem opera.

• O PRD como contrato com a engenharia

  Aqui eu não construí a versão final sozinha, porque precisava da engenharia para integrar com os dados reais. Escrevi no PRD uma tabela com os 28 erros (título, explicação e ação) e repliquei todos eles num protótipo completo no Lovable, para os devs verem o comportamento exato de cada tela antes de implementar.

Fechando o loop com IA

Com a tela no ar, automatizei o que não precisava de humano nenhum. Quando faltava um dia para o envio e alguma informação estava incompleta, a IA cobrava o cliente sozinha. Sem resposta em algumas horas, cobrava de novo, e só então gerava notificação para a assistente agir com mais força.

Quando o erro acontecia, a IA avisava o cliente na hora, já com a saída: “esse pagamento não pôde ser feito porque estava fora do horário de envio de boletos, quer agendar para o próximo horário útil?”

A IA passou a resolver sozinha cerca de 80% dos erros. A fila da assistente parou de receber o que a máquina já dava conta, e sobraram por volta de 15 notificações por dia para tratamento humano, contando os erros que a IA não resolvia e as cobranças preventivas que precisavam de pressão de gente.

O que mudou

O que eu faria diferente

Eu não instrumentei a métrica certa. Adoção eu não medi de verdade, porque bloqueei a tela antiga e todo mundo passou a usar a nova por obrigação. Isso é substituição, não adoção. A métrica que eu deveria ter subido junto com a feature era tempo médio entre o erro acontecer e o erro ser resolvido, e eu não subi. O detalhe que dói: na Qulture.Rocks eu criei exatamente o processo que obriga o PM a entregar tagueamento e tela de acompanhamento junto com a feature. Não apliquei em mim.

A ordem do lançamento gerou retrabalho. Lancei a central primeiro e a automação de IA depois, porque a falta de visibilidade já estava custando dinheiro real e centralizar era urgente. Foi a decisão certa para o negócio e mesmo assim teve custo: parte das notificações que eu tinha desenhado para a assistente deixou de fazer sentido quando a IA passou a resolver aquilo sozinha.

E teve uma regressão minha. No rollout, as notificações de pagamento não aprovado pararam de aparecer para um dos grupos, e aquelas assistentes passaram alguns dias sem cobrar aprovação dos clientes. Corrigi o bug, mas o estrago maior não era o bug: era a insegurança que ficou, o “será que estou deixando de ver mais alguma coisa?”. Abri um canal direto para elas reportarem qualquer dúvida até o QA completo terminar. O rollout em quatro fases, da liderança para 5, depois 10, depois 30 assistentes, é a razão de isso ter atingido um grupo pequeno em vez da operação inteira.