Atendimento

O atendente recebe um ticket e precisa saber o que aconteceu com o pedido daquele cliente: pagou, travou onde, foi estornado, está em devolução, tem loja perto para retirada. Cada uma dessas respostas mora num lugar diferente, com portal e login próprios, e quem atende atende tudo.

O que eu construí

Um painel que roda dentro da própria plataforma de atendimento, na lateral do ticket, e mostra a situação do pedido sem o atendente sair dali. Ele não conhece nenhum sistema interno: quem traduz é o middleware de atendimento, que eu comecei e não fiz sozinho.

E as integrações que trabalham sem ninguém pedir: parte delas abre o chamado sozinha, já com o contexto, para o time agir antes de o cliente reclamar.

O que o desenho resolve

Uma tela em vez de várias. Sem um lugar que concentre, responder a um único ticket é abrir um portal por pergunta e copiar número de pedido entre eles, cada um com seu jeito de responder. O painel faz essas chamadas por baixo e devolve tudo no mesmo lugar, que é onde a pessoa já está.

O chamado pode nascer do evento, não da reclamação. Quando algo muda do lado de um sistema integrado, o caso já chega aberto e com contexto, em vez de depender de o cliente perceber primeiro.

A dívida que eu deixei escrita

Parte do estado do painel é guardada num comentário do próprio ticket, porque a plataforma não oferece armazenamento por ticket para esse tipo de aplicação. Funciona, e tem um custo real que eu registrei em vez de esconder: quem edita aquele comentário quebra o painel.

Manter esse registro de dívida separando “corrigir com cuidado, tem risco de negócio” de “defeito confirmado” e de “limpeza” é prática que eu levaria para qualquer time. Dívida que não está escrita não é decisão, é esquecimento.

Stack

React · Vite · integração com plataforma de atendimento · middleware em .NET