A situação
Um negócio de lead generation que vendia nos Estados Unidos, com um produto que tinha de fazer três coisas ao mesmo tempo: captar e qualificar leads, decidir quanto valia cada um e encaminhar chamadas entre compradores e vendedores em tempo real. Quando cheguei não havia equipa de engenharia. Havia eu.
A qualidade dos leads era pontuada por uma API de terceiros cobrada à chamada. Funcionava, no sentido em que devolvia um número. Não podia ser ajustada, a latência dela era o problema de outra pessoa, o preço dela era a decisão de outra pessoa, e os casos limite ligados à legislação americana de telemarketing eram a interpretação de outra pessoa.
O modelo de scoring
Substituí-a por um modelo nosso: concebido, etiquetado, treinado, servido e avaliado internamente, juntamente com o pipeline de features que o alimentava.
As entradas foram a parte interessante - device intelligence, o tipo de linha e consultas de carrier, dados de reputação, eventos comportamentais durante o próprio preenchimento do formulário e metadados de consentimento. Se um número é móvel num carrier grande, e se a pessoa preencheu o formulário em onze segundos ou em noventa, dizem mais sobre o valor do lead do que quase tudo o que as pessoas põem nos campos demográficos.
Trazê-lo para dentro deu-nos quatro coisas que o fornecedor não podia vender: controlo sobre a latência, um custo por lead que descia com o volume em vez de subir, a nossa própria leitura dos casos limite de conformidade e - o mais importante - a possibilidade de decidir como é que a confiança deve influenciar o encaminhamento e o preço. Um score que não podes interrogar é um score sobre o qual não tens coragem de agir.
O resto do produto
Um backend Django que expunha REST e GraphQL, sobre PostgreSQL para os dados transacionais e ClickHouse para a analítica de grande volume e a telemetria de scoring - duas bases de dados porque uma única forma de consulta não serve as duas, e fingir que serve é a maneira como a analítica acaba por abrandar exatamente aquilo que traz o dinheiro.
O back office de admin tinha APIs JWT que fazem introspeção dos metadados do próprio admin do Django, por isso acrescentar um modelo expunha-o automaticamente aos clientes móveis. Isso poupava uma semana de cada vez e, mais valioso ainda, eliminava uma classe de bugs em que a aplicação móvel e o admin web não concordavam sobre o aspeto de um registo.
Infraestrutura de chamadas de ponta a ponta: várias plataformas de dialer e de carrier para outbound e inbound, serviços de encaminhamento, uma camada de distribuição entre compradores e vendedores e um backend próprio que orquestrava o fluxo em direto desde a chamada até à transferência, à gravação e à classificação do resultado. Agentes de voz no outbound. Verificação contínua face às regras do do-not-call e de consentimento para telemarketing, ligada diretamente à aceitação do lead e não colada no fim, porque uma verificação de conformidade que corre depois de já teres ligado é um registo da infração, não um controlo.
Depois as partes que ninguém conta: um CMS próprio, três aplicações Flutter para iOS e Android a cobrir B2B, B2C e admin, e a infraestrutura de produção - Ubuntu endurecido, Nginx, Docker, releases sem downtime, DNS em dois fornecedores, certificados, firewall e bloqueio de intrusões.
Como foi estar sozinha no produto todo
Sobretudo, esclarecedor. Não tens com quem negociar uma interface e um mal-entendido não tem onde se esconder. Mas põe um teto duro sobre quanto pode estar em curso ao mesmo tempo, e faz da documentação um ato de autodefesa e não uma cortesia - a pessoa que não se vai lembrar porque é que esta fila tem um atraso de dois segundos sou eu, em março.
O que faria de outra maneira
Teria construído a avaliação e a monitorização do modelo no mesmo dia que o modelo, e não depois de estar em produção. Comportou-se bem, e sabia disso pela avaliação offline - mas nas primeiras semanas não teria conseguido demonstrar depressa que continuava a comportar-se igualmente bem em produção. Essa lacuna é desconfortável e era evitável.