O começo, e a decisão de não usar plataforma pronta

A Atendus não começou como produto. Começou como problema nosso.

Atendíamos clientes pelo WhatsApp, e o WhatsApp não foi feito para isso. Mensagem perdida no meio da conversa, ninguém sabendo quem já tinha respondido o quê, histórico preso no celular de uma pessoa só. Quando duas pessoas passam a atender o mesmo número, o aplicativo vira o gargalo.

O que já existia

Testamos as plataformas de mercado antes de escrever qualquer linha. Elas resolviam parte do problema e criavam outros três.

O robô era burro. As ferramentas trabalhavam com árvore de decisão: “digite 1 para vendas, 2 para suporte”. Cliente não fala em menu. Ele escreve “oi, ainda tem aquele produto azul que vi ontem?” e a árvore não tem para onde ir.

As que tinham IA não deixavam configurar nada. Ou o assistente era uma caixa preta com um campo de texto para “descreva seu negócio”, ou exigia um time técnico para cada ajuste. Não havia meio-termo entre engessado e complicado.

Nenhuma entendia o negócio do cliente. Uma imobiliária, uma clínica e um e-commerce têm perguntas, vocabulário e fluxos completamente diferentes. As plataformas tratavam todas como iguais.

Escalar canal custava caro. Adicionar Instagram, ou marketplace, era mudar de plano — quando existia a opção.

A hipótese

A ideia que deu origem ao produto foi simples de enunciar e difícil de executar:

E se o dono do negócio pudesse configurar o próprio agente, nos mínimos detalhes, sem saber programar — e esse agente pudesse atender em qualquer canal, com o conhecimento específico daquela empresa?

Cada parte dessa frase virou um módulo. E a ordem em que a gente descobriu que precisava de cada um é exatamente a ordem deste diário — não foi planejamento, foi cliente reclamando.

Por que Laravel

Escolha rápida, e por motivo pragmático: é o ecossistema em que sou mais produtivo depois de mais de quinze anos em PHP. Num produto que ainda não sabe o que vai ser, velocidade de iteração vale mais que a elegância da linguagem.

Laravel trouxe filas, agendamento, ORM, autenticação e um ecossistema maduro sem custo de construção. O tempo que economizei em infraestrutura foi gasto onde importava: descobrir o que o cliente realmente precisava.

Já vi projeto morrer por escolher a stack da moda e passar seis meses resolvendo problema que o framework maduro resolvia na primeira semana.

O que ficou decidido antes do código

Três princípios que sobreviveram a tudo que veio depois:

Modular desde o primeiro dia. Cada capacidade — canal, agente, base de conhecimento, agenda — precisa poder existir sem as outras. Não porque a gente antecipou os módulos, mas porque a gente sabia que não sabia quais viriam.

Canal é plugin, não regra de negócio. O núcleo da plataforma não pode saber que WhatsApp existe. Ele recebe mensagem normalizada e devolve resposta normalizada; traduzir isso para cada provedor é problema de outro componente.

Configuração é do cliente, não nossa. Se cada personalização exigir deploy nosso, o produto não escala além de consultoria. Tudo que diferencia um cliente do outro tem que ser dado, não código.

Esse último princípio foi o mais caro de sustentar e o que mais rendeu.