O preço que só mudou no email

Numa call, você concorda com um preço menor. O cliente está feliz, você está feliz, o deal está de volta, e você segue para a próxima coisa antes mesmo de a call terminar. O número novo é real. Ele aconteceu. E então ele fica ali, verdadeiro em exatamente um lugar, aquela conversa, enquanto a proposta, a fatura, o email de onboarding e a previsão de renovação todos continuam quietamente citando o número de que você já desistiu.

Ninguém mentiu. Ninguém foi descuidado. O preço novo só nunca propagou.

Essa é a falha mais cara numa empresa, e quase ninguém a nomeia, porque ela não parece uma falha. Parece uma terça-feira normal. Este post é sobre o único mecanismo que a conserta, e por que a coisa que a maioria das empresas parafusou não consegue.

O fato que só é verdade num lugar

O formato se repete em todo lugar, então vale dizê-lo claro primeiro. Um fato sobre seu negócio muda. Ele é registrado no único lugar onde a mudança aconteceu, a call, o email, a cabeça de alguém, e toda outra cópia daquele fato continua mostrando o valor antigo até um humano notar a deriva e corrigi-la na mão.

Esse é o bug. Aqui está o refrão com que quero que você saia: o preço mudou na call; a proposta ainda cita o número antigo.

Soa pequeno. Não é. O mesmo formato é a reunião que se moveu numa thread mas nunca se moveu no invite. O cliente que disse “provavelmente terminamos” numa call mas ainda lê “ativo” no CRM, no dashboard e na previsão de renovação. O deadline que escorregou no standup mas ainda diz “sexta” no plano contra o qual o time inteiro trabalha. Cada um é um fato que é verdadeiro num lugar e falso em todos os outros, e o gap entre esses dois estados é onde deals morrem, margens vazam, e um cliente abre uma fatura por um número que vocês dois já concordaram que estava errado.

A razão pela qual isto é tão difícil de erradicar é que o momento da mudança e o momento da consequência estão longe um do outro. O preço novo parece terminado no segundo em que vocês dois acenam para ele. A dor chega semanas depois, de uma direção completamente diferente, uma disputa de billing, uma renovação modelada sobre receita que você descontou para longe, e até lá ninguém a conecta de volta a uma frase numa call.

A correção ingênua: dizer a todos para terem mais cuidado

O instinto, toda vez, é disciplina. Escrevemos o checklist. “Quando um preço mudar, atualize a proposta, o registro de billing e as notas do deal.” Adicionamos um passo ao runbook. Lembramos as pessoas no retro. Por uma semana, funciona, porque todo mundo está recém-irritado com a última falha.

Aí decai. Não porque o time é preguiçoso, porque a disciplina escala com o número de lugares onde um fato mora, e esse número só sobe. Cinco ferramentas viram doze. A cotação, a proposta, o CRM, o sistema de billing, o dashboard, o email de onboarding, o rate card voltado para parceiros. Atualizar um número corretamente agora significa lembrar, na mão, de toda cópia downstream dele, toda vez, para sempre, através de uma dúzia de superfícies que não se falam.

Isso acontece com todo time que cresce além de um punhado de ferramentas, e vale ser preciso sobre o mecanismo: você não ficou mais desleixado. Você ganhou mais superfícies. A disciplina que funcionava em cinco ferramentas é a mesma disciplina, aplicada a doze, e ela falha não no passo mas na contagem.

Pedir às pessoas para manter manualmente um fato em sync através de uma dúzia de ferramentas é pedir a elas para fazer, na mão, o único trabalho para o qual os computadores foram inventados.

Então disciplina é a camada errada. O checklist trata um problema de propagação como um problema de atenção. Ele coloca o fardo da consistência na parte mais esquecida, mais interrompida, mais esgotada do sistema, um humano malabarista de doze abas, quando o ponto inteiro do software é nunca fazer uma pessoa lembrar de algo que uma máquina poderia carregar.

A correção de verdade: uma fonte de verdade, e um sistema que propaga a partir dela

A ideia-chave é simples. Pare de armazenar o mesmo fato em doze lugares que derivam. Armazene-o uma vez, num único lugar que é autoritativo, e faça toda outra superfície ser uma view daquele único lugar, para que quando o fato mudar, toda view mude com ele, porque não há mais nada para mudar.

Engenheiros vão reconhecer isso imediatamente. É a diferença entre copiar um valor em dez planilhas e colocá-lo em uma célula que dez planilhas referenciam. A primeira garante deriva. A segunda torna deriva impossível, porque só há sempre um número. O bug nunca foi que as pessoas esqueceram de atualizar. O bug era que havia dez números quando deveria haver um.

Uma empresa roda no primeiro modelo em quase todo lugar. O preço acordado mora nas notas da call e na proposta e no sistema de billing e na memória do vendedor, quatro cópias, quatro chances de derivar. O status do cliente mora no CRM e no canal do deal e na cabeça de quem falou com ele por último. Toda duplicata é uma contradição futura esperando por uma terça lenta para aparecer.

Esta é a versão onde o refrão finalmente se quebra. O preço mudou na call; a proposta ainda cita o número antigo, mas só porque a proposta era uma cópia separada. Faça dela uma view em vez disso, e não há segunda cópia sobrando para derivar.

Mova-se para o segundo modelo e a proposta para de ser uma cópia separada do preço. Ela vira uma janela para o único fato “o preço deste cliente é o número novo”. Mude esse fato uma vez, e a proposta, a fatura, o email de onboarding, a previsão de renovação todos mostram o número novo, não porque alguém atualizou quatro coisas, mas porque só havia uma coisa, e quatro janelas olhando para ela.

Parafuse um chatbot numa empresa com doze cópias derivantes de cada fato e ele não conserta a deriva, ele adiciona uma décima terceira superfície que pode estar confiantemente errada, porque está lendo qualquer cópia velha para a qual calhou de ser apontado. Uma resposta mais esperta tirada da fonte errada ainda é a resposta errada, entregue mais rápido.

A parte difícil: saber que o fato mudou afinal

Aqui é onde uma fonte de verdade para de ser uma palestra de banco de dados e vira o produto de fato. Apontar toda superfície para um único fato é a metade fácil. A metade difícil é notar que o fato mudou, porque em empresas reais, fatos não mudam através de um formulário com um botão “salvar”. Eles mudam numa frase, numa thread, numa call que ninguém transcreveu.

Ninguém abriu o sistema de billing e editou a taxa. Alguém disse “okay, vamos fechar no número menor, mande a papelada atualizada”. Essa frase é o momento em que o fato mudou. Se seu sistema só escuta o campo de edição do registro de billing, ele nunca vai ouvi-la, e a fonte de verdade, por mais elegante que seja, fica congelada no preço antigo enquanto a decisão real navega por ela em linguagem clara.

Então o sistema que de fato conserta isto precisa de duas propriedades de uma vez. Ele tem que segurar uma cópia autoritativa de cada fato, e tem que estar sempre escutando, através das superfícies humanas bagunçadas onde os fatos de fato mudam, para que consiga reconhecer “vamos fechar no número menor” como um evento de atualização e não só conversa. Uma sem a outra é meia correção. Uma fonte de verdade que ninguém atualiza é só um lugar mais bonito de estar errado.

Esse é o loop que fecha o gap: escute através das superfícies onde as decisões são de fato faladas, reconheça a mudança, atualize o único fato autoritativo, e deixe toda view seguir. O preço muda na call, e desta vez a proposta muda com ele, porque a call e a proposta nunca foram dois fatos. Eram um fato e duas janelas, e o sistema estava observando a janela onde os humanos de fato vivem.

Por que isto não pode ser uma feature que você parafusa

É tentador tratar sync como um problema de plumbing, ligue o CRM ao sistema de billing, o sistema de billing à proposta, pronto. Times tentam isso, integração por integração, e funciona até a segunda ferramenta, então desmorona sob sua própria aritmética. Conecte uma dúzia de ferramentas par a par e você não tem doze conexões para manter. Você tem mais perto de setenta, cada uma um lugar onde o fato pode vazar, cada uma quebrando no dia em que uma ferramenta lança uma API nova.

É por isso que a correção tem que ser uma camada, não um fio. Um lugar que segura os fatos, do qual tudo o mais lê e para o qual tudo o mais escreve, para que adicionar a décima terceira ferramenta signifique apontá-la para o centro, não costurá-la às outras doze. O problema de deriva não é resolvido por mais conexões. É resolvido removendo as duplicatas que as conexões estavam tentando reconciliar.

O que é a mesma constatação, um nível acima: isto não é uma feature. É um sistema operacional para os fatos da empresa. As features, o briefing, o lembrete, o alerta quando duas superfícies discordam sobre o que um cliente paga, são o que você ganha de graça uma vez que os fatos moram num só lugar e algo está sempre escutando quando eles mudam. Construa a camada e as features caem. Construa as features primeiro e você só adicionou mais lugares para derivar.

A virada

Você já sabe quem paga pela deriva. É a pessoa no seu time que se tornou a fonte de verdade humana, aquela para quem todo mundo manda mensagem perguntando “espera, fechamos no preço novo ou no antigo?” porque ela é a única cópia que está confiavelmente atual. Ela segura o estado real da empresa na cabeça, e está exausta, porque ser uma memória estrutural é um trabalho de tempo integral que ninguém colocou na descrição da vaga.

Essa pessoa não é valiosa porque lembra qual desconto passou. Ela é valiosa por tudo que não consegue fazer enquanto está ocupada sendo um banco de dados, o julgamento, o relacionamento, a chamada que só ela consegue fazer sobre para onde a empresa deveria ir em seguida. Todo minuto que ela gasta reconciliando cópias velhas é um minuto roubado da única coisa que nenhum sistema pode fazer por ela. Não a contratamos para ser um motor de sync. Deixamos ela virar um porque nada mais o faria.

O ponto de uma fonte de verdade nunca foi arrumação. É devolver àquela pessoa a parte de si mesma que uma máquina nunca deveria ter sido autorizada a consumir.

---

Estamos construindo isto na Apollo Space, não um chatbot mais esperto lendo qualquer cópia velha em que calhou de pousar, mas uma camada que segura os fatos da sua empresa uma vez e mantém toda superfície honesta a eles. Se seu colega mais confiável quietamente virou o lugar onde todo mundo confere porque nada mais pode ser confiável, isso não é lealdade da qual você deveria se orgulhar. É um problema de sync usando o rosto de uma pessoa, e ele finalmente tem um lugar melhor para morar.