Configurador de IA

Time

1 Product Designer (eu), 1 PM, 15 devs

O coração do produto não estava pronto pro que vinha. E eu já desconfiava disso.

O AmigoFlow é um CRM de atendimento para clínicas, com um agente de IA no centro. O agente conversa com o paciente pelo WhatsApp, resolve o que consegue sozinho e, quando não consegue, escala pra um atendente humano. Estive no projeto desde o início, produto grande, investimento pesado, time de 15 desenvolvedores.

A primeira versão funcionava. Mas ainda durante os primeiros lançamentos, com o negócio começando a falar em omnichannel e clientes grandes, eu levantei uma suspeita: essa base não ia durar. E, em paralelo ao desenho do MVP, comecei a rascunhar como seria a solução se, quando, a suspeita se confirmasse.

Um agente, um canal, um grupo. Ponto.

Na primeira versão, a entidade central era o agente de IA. Pra cada agente criado, configurava-se dentro dele um único número de WhatsApp e um grupo fixo de atendentes. Uma relação fechada: 1 agente → 1 canal → 1 grupo.

Funcionava bem, enquanto o produto atendia clínicas pequenas, com cenário simples.

O problema que eu previa apareceu. Com nome e sobrenome.

A confirmação veio de fora: um grande cliente levantou uma necessidade que o configurador simplesmente não atendia. Clínicas grandes não seguem a lógica de "um atendente pra um canal", um atendente cobre vários canais, uma clínica tem um número pro médico e outro pra recepção, um canal é só marketing e outro é agendamento.

E no modelo antigo, cada canal era um mundo isolado: o atendente só via as mensagens de um canal por vez, trocando de aba o tempo todo. Não existia visão unificada. A estrutura não suportava multicanal, e era exatamente isso que a nova estratégia exigia.

A diferença entre pânico e plano é o timing.

Aqui está o que eu mais me orgulho nesse projeto. Quando o problema estourou, ele podia ter virado crise, um "e agora?" com o time correndo atrás do prejuízo.

Mas não virou. Porque grande parte dos problemas já tinha sido mapeada por mim e pela PM, e eu já vinha desenhando a solução em paralelo. Então, no momento emblemático em que a urgência apareceu, a gente não estava começando do zero: estava tirando da gaveta algo já pensado.

A virada de chave não foi rápida nem automática, convencer que valia refazer uma base que "já funcionava" exige argumento e evidência. O que destravou foi a combinação de duas coisas: a dor agora era visível (um cliente real, uma necessidade concreta) e a resposta já existia. Conseguimos tranquilizar o time de que aquilo tinha sido antecipado e era possível resolver.

A decisão de arquitetura foi minha, construída puxando o time pra perto.

A solução: inverter a hierarquia. Em vez do agente ser a entidade central, o canal passa a ser.

Cheguei nisso a partir das conversas com a PM e dos feedbacks que ela recebia de usuários de um produto interno que usávamos como referência, semelhante ao nosso, mas com usuários reais em operação. A decisão de qual seria a nova arquitetura partiu de mim, mas nunca sozinha no escuro: eu puxava o time o tempo todo pra questionar minha lógica, especialmente a PM, e realizei múltiplas reuniões com os devs durante o desenho pra entender o que era viável em tempo hábil. Todos alinhados de que o problema existia, a discussão era sobre o como, não sobre o se.

No novo modelo, anexo múltiplos canais, WhatsApp, Instagram, o que for, e dentro de cada canal configuro um agente com habilidades e base de conhecimento próprias. A diferença é sutil e muda tudo: em vez de "esse agente atende esses canais", passa a ser "esse canal tem esse agente, que age assim aqui dentro". Isso permite personalizar por canal:

• Um canal só pra marketing, com agente treinado pra campanhas.
• Um canal pra atendimentos gerais, agendamentos, cobranças, dúvidas.
• Um canal exclusivo pro principal cirurgião, com instruções direcionadas.
• Um canal por unidade de atendimento, cada um com suas regras.

E os atendentes? Ganharam liberdade.

Separado do configurador de canais, criei um configurador de setores. Agora um atendente atende múltiplos canais, todas as mensagens desaguam num lugar só, sem trocar de aba. É o omnichannel de verdade.

Dentro de cada canal, defino um setor padrão: quando o agente não sabe pra onde transferir, vai pra lá. E o mesmo setor padrão pode existir em vários canais, o atendente recebe tudo unificado, não importa onde a conversa começou.

Como validamos (sem teste de usuário, e por que)

Sendo honesta sobre o processo: não testamos o novo configurador com usuários finais, porque a implantação do sistema era feita por um time interno nosso, não pelos clientes sozinhos. A validação veio por outro caminho, e bem concreta: dezenas de tarefas que a arquitetura antiga impedia foram destravadas, e fluxos inteiros, antes impossíveis, passaram a existir sem as limitações do modelo 1:1:1.

O teste real foi de capacidade: coisas que simplesmente não davam pra fazer antes, agora davam.

A base de tudo que veio depois

O novo modelo não resolveu só o problema imediato, destravou a estratégia seguinte: a virada pra omnichannel. Como a base ficou desenhada certa desde cedo, cada funcionalidade lançada depois pôde ser construída em cima dela, sem esbarrar de novo na mesma parede. Se a reestruturação tivesse demorado, o custo de recuperar o atraso, e desfazer tudo construído sobre a estrutura antiga, teria sido bem maior.

O que eu levo desse projeto

• Antecipar vale mais que reagir. Enxergar que a base ia quebrar antes de ela quebrar, e desenhar a resposta em paralelo, foi o que transformou uma possível crise numa transição controlada.
• Ter razão não basta, timing importa. Eu tinha a solução meses antes de ela ser aceita. O que destravou não foi só o argumento; foi esperar a dor ficar visível pra todos.
• Decisão técnica pode partir do design, desde que você traga o time junto. Puxei a arquitetura, mas questionando minha própria lógica com a PM e os devs a cada passo. Autoria não é decidir sozinha; é liderar a decisão.

Vamos conversar?

Aberta a novos projetos, parcerias e conversas sobre produto e design.