luiza cabralINK Helpdesk
O atendimento próprio da INK, com uma IA que conhece a INK. Construído numa madrugada, depois de um dia inteiro de PRD.
de construção, da primeira linha à V0 praticamente pronta
commits num único dia
do primeiro commit ao ar
commits em duas semanas, quase todos meus
- Rails 8.1
- Hotwire
- Action Cable
- Sidekiq
- pgvector
- MCP
- Linear
Integrei ao ticket o Sherlock, agente criado pelo Eriko. A minha parte foi a API que liga ele ao Helpdesk.
O problema
Em 2020, o meu trabalho era atender usuário no suporte da INK. Seis anos depois, coube a mim construir o sistema que atende eles.
A IA do atendimento terceirizado travava a abertura de ticket e não conhecia a INK. O usuário não via o que já tinha aberto, repetia a história e abria ticket duplicado. Do lado de dentro, o suporte se dividia entre o chat terceirizado, o canal de investigação no Discord e o INK Hub, e a ferramenta antiga acumulava 374 etiquetas e 42 regras de automação.
A construção
A maior parte do tempo foi ideação, antes de qualquer código. A construção em si foi rápida porque não foi linear: o maestro, uma skill que eu criei, quebrou o Helpdesk em fases, e cada fase rodou com subagentes em paralelo.
E tudo coube no meu plano do Claude Code, sem gastar todos os tokens dele.
- 1dia 1Ouvir quem sente a dor
Quem vive o problema lista o que precisa. A lista vem antes de qualquer tela.
A stakeholder do atendimento listou tudo que o Helpdesk precisava ter.
- 2dia 2PRD e telas
Escrevo o PRD e desenho as telas no Claude Design. É onde eu passo mais tempo.
Um dia inteiro de PRD e telas, sem uma linha de código.
- 3antes do 1º commitO maestro pergunta
Ele mapeia todos os fluxos e, quando o PRD tem um furo, aponta e pergunta, em vez de interpretar do jeito dele.
4 fases, 76 tarefas e 19 documentos escritos pros agentes.
- 4madrugadaSubagentes em paralelo
Cada fase roda com vários subagentes ao mesmo tempo, não uma tarefa depois da outra.
Primeiro commit às 23h15. Às 8h, estava praticamente pronto.
- 5dez dias depoisTravas e deploy
CI com checagem de segurança e testes de isolamento por loja. Só sobe com tudo verde.
Helpdesk no ar, atendendo usuário.
Dentro de uma fase
O maestro quebrou o Helpdesk em 4 fases e 76 tarefas. Em cada fase, as tarefas rodam ao mesmo tempo, cada subagente na própria worktree, e o merge junta tudo numa versão só. Por isso a construção não foi linear.
A madrugada, hora a hora
Commits por hora entre 23h de 5 de outubro e 8h de 6 de outubro. Os picos são subagentes trabalhando ao mesmo tempo, então o gráfico mostra quando houve commit, não horas trabalhadas.
Por baixo
- A IA não pode dizer o que não aconteceu. Antes de virar mensagem, a resposta da Silvia passa por conferências em código. Ela só diz "a troca foi feita" se existe uma troca concluída daquele pedido.
- Ações fechadas. A IA só pode responder, resolver, passar pra equipe ou iniciar um fluxo, e o servidor valida cada resposta.
- Nenhum dado pessoal sai. Antes de ir pro Sherlock e pro Linear, e-mail, CPF, telefone, endereço e nomes são mascarados. Se sobra algo, o envio é bloqueado.
- Um usuário nunca vê o ticket de outro. O isolamento por loja e por área é provado por suítes de teste próprias.
- De 14 segundos pra menos de 0,3. A caixa e o ticket ficaram rápidos com 5 mil tickets depois de achar uma consulta repetida no cálculo de prazo.
O resultado
O usuário pede ajuda sem sair do painel da INK, e o atendimento já sabe quem ele é e de qual pedido ele está falando. A Silvia, a IA, atende primeiro com a base de conhecimento da INK. O que ela não resolve chega pra equipe já resumido, com loja, pedido e entrega ao lado da conversa.
Quando é bug, a dúvida técnica saiu do Discord e foi pra dentro do ticket: o Sherlock investiga no código, a issue nasce no Linear e, quando ela fecha, o usuário é avisado sozinho.
A usuária que pede ajuda
A Mariana, da Estampa Viva, tem um problema com um cupom e abre um atendimento pelo painel da INK.
A especialista que resolve
A Camila pega o ticket da Mariana, descobre que é bug e fecha o ciclo com o Linear.
Telas de um ambiente local, com lojas, pessoas e tickets fictícios.
Os fluxos
O caminho do atendimento é montado em fluxos, e quem monta é o próprio suporte, arrastando etapas num canvas: mensagem, botões, número do pedido, consulta à API da INK, ir pra outro fluxo. Cada fluxo tem um gatilho: o Boas-vindas roda quando o usuário abre o chat, e os outros, como pedido atrasado ou troca, são chamados por ele ou por um botão. A lista mostra o que está publicado, o que ainda é rascunho e quantas etapas cada um tem.
A base de conhecimento
A Silvia responde com o que está na base. Pra mudar, a pessoa escreve o que quer ou cola um link ou PDF, uma instrução por vez, e salva uma versão nova da base. Do lado, dá pra testar o agente escrevendo como um usuário escreveria, sem criar ticket. E a base aprende com o atendimento: quando a equipe corrige uma resposta da Silvia, a correção vira sugestão, e a Silvia também propõe as dela. Nada muda até alguém aprovar.
O gargalo mudou de lugar. A madrugada só rendeu porque o dia anterior foi de PRD e tela. Hoje, a parte cara do software é ter clareza do que construir.