Contatos deveriam se montar sozinhos

Pense na última vez em que você precisou falar com alguém com quem tinha conversado meses antes. Você provavelmente não abriu a sua agenda de contatos. Buscou o nome na caixa, achou uma corrente, e respondeu ali, porque a corrente era o único lugar em que o endereço com certeza estava atual.

É uma coisa estranha de se admitir sobre um software que todo sistema operacional entrega há quarenta anos. A agenda de contatos não falhou porque a ideia era errada. Falhou porque mantê-la em dia era serviço seu, e um registro velho é idêntico a um bom até você usá-lo. Você descobre que o endereço morreu quando a mensagem volta, o que é tarde o bastante para você parar de confiar na lista e voltar a buscar na caixa.

Uma pessoa, quatro identificadores

Há um segundo problema empilhado sobre o primeiro. A sua agenda foi desenhada para um mundo em que uma pessoa tinha um endereço. Agora a pessoa que você quer alcançar tem um e-mail no trabalho, outro que usa para faturas, um usuário no Slack num canal compartilhado, um telefone que você pegou num evento, e uma conta no Teams no cliente para quem vocês dois trabalham. Nenhum deles sabe dos outros.

Então o registro se fragmenta. O Google Contatos tem uma versão, colhida do Gmail. O Slack tem outra que na verdade é só uma pessoa no espaço de trabalho. O seu celular tem uma terceira com o número e nada mais. Cada uma está parcialmente certa, e conciliá-las é exatamente o tipo de trabalho tedioso que ninguém nunca faz.

O que construímos

Existe agora uma seção de Contatos no this+that, e o que vale dizer sobre ela é o que você não faz: você não a preenche.

Ela se monta a partir dos canais que você já conectou. Google Contatos, Outlook, Slack, Google Chat, Teams, e os colegas na sua conta do this+that alimentam tudo. Quando a mesma pessoa aparece de dois lugares, resolvemos num registro só com as duas origens anexadas, então o usuário do Slack e o e-mail de trabalho caem na mesma pessoa, em vez de virarem duas meias-pessoas. O que a sincronização errar, você junta à mão.

A parte em que tivemos mais cuidado é o que acontece quando você edita algo. Corrija um cargo que está dois postos atrasado e a próxima sincronização não sobrescreve. Apague um e-mail que a pessoa parou de usar e ele não reaparece uma hora depois. Toda agenda apoiada em sincronização que já usamos erra isso, e errar isso é o que ensina as pessoas a parar de editar.

O histórico é o ponto

Abra uma pessoa e você vê a sua correspondência com ela: os e-mails e as mensagens, entre canais, em ordem, com quem escreveu para quem.

Você não arquivou nada disso. Conforme e-mails e mensagens chegam, eles se anexam às pessoas envolvidas. Então o registro não é um cartão com um telefone. É a resposta a “qual é o meu histórico com esta pessoa”, que é a pergunta que você de fato tinha quando foi procurá-la.

Essa resposta esteve nas suas contas o tempo todo, espalhada por quatro aplicativos que guardam um pedaço cada e nenhum dos quais te mostra o todo. Juntar não é esperto. É só trabalho que ninguém tinha feito.

Você pode compartilhar uma pessoa com o seu time, que é onde isso ganha de uma agenda pessoal. Quando alguém sai de férias ou passa uma conta adiante, quem pega recebe o registro: cada endereço que a pessoa de fato usa, o telefone que funciona, o cargo atual, e as notas que o colega guardou.

O que essa pessoa não recebe é a sua caixa. A atividade de um contato compartilhado é lida do e-mail de quem está olhando, então o colega vê o histórico dele com aquela pessoa e nunca o seu. O seu lado da correspondência fica privado mesmo com o contato compartilhado, que é a fronteira que você quer no instante em que pensa no que tem nas suas mensagens diretas.

O que isto não é

Não estamos construindo um Salesforce. Não há negócios aqui, nem estágios de funil, nem previsão, nem datas de fechamento. Os seus sistemas de registro mantêm o serviço deles, e os campos estruturados ficam neles.

Pense nisto como o que o Google Contatos seria se ele se mantivesse em dia e lembrasse das suas conversas. É essa a ambição inteira. É um diretório das pessoas com quem você de fato fala, o que soa modesto até você notar que não tem um.

Um contato novo pode começar algo

Um diretório que você precisa lembrar de abrir vale menos que um que age. Então uma pessoa chegando é um gatilho: um fluxo pode rodar no momento em que alguém é criado, tenha você digitado ou uma sincronização trazido.

O que ele faz dali em diante é escolha sua. Ele pode escrever uma página no Brain para aquela pessoa ou a conta dela, o que transforma um nome novo num lugar onde o seu time guarda o que sabe. Pode empurrar o registro para o Salesforce ou o HubSpot por um servidor MCP conectado, então o sistema de registro recebe o contato sem ninguém redigitar. Pode compartilhar a pessoa com um time, ou acrescentar uma nota com data. Os fluxos também buscam nas suas pessoas durante a rodada, e um passo de agente faz o mesmo trabalho com registro do que alterou.

Esse último importa mais do que parece. Significa que a lista de contatos e a camada de conhecimento não são produtos separados que você tem que conciliar. Uma pessoa aparece no seu e-mail, cai em Contatos, e um fluxo a põe onde o seu time de fato vai procurá-la.

Por que esta fatia primeiro

O Brain se apoia na mesma aposta que Contatos: conhecimento que precisa de uma pessoa para se manter não fica em dia, então a manutenção tem que sair da comunicação que um time já produz. Contatos é a menor versão disso, rodando em produção sobre a fatia mais fácil do problema.

Também passa por cima daquilo que toda camada de conhecimento enfrenta no primeiro dia, quando está vazia e alguém precisa preencher antes de valer a pena abrir. Contatos vem povoado no instante em que você conecta uma conta, porque as pessoas já estavam lá. Partir de algo real e deixá-lo se corrigir é uma proposta diferente de partir do zero e prometer manter alimentado, e preferimos aprender isso em registros de contato do que em tudo que uma empresa sabe.

Contatos se paga no dia em que você conecta uma conta, antes de automatizar qualquer coisa. A lista está certa, o histórico está lá, e uma passagem de mão não começa mais do zero. Os fluxos são onde isso acumula, e essa é a parte que estamos construindo agora.

Mais adiante está um Brain que fica em dia sem ser avisado, em que a página de uma conta está certa porque o seu time falou com o cliente e não porque alguém montou uma automação para isso. A camada de pessoas já funciona assim. O resto está em andamento.

Principais conclusões

• Agendas de contatos envelhecem porque dependem de manutenção, então as pessoas as abandonam e buscam na caixa. A solução é um registro de contato que se monta sozinho.
• A mesma pessoa chega como e-mail, usuário do Slack e telefone que não se conciliam. O this+that resolve isso num registro só com todas as origens anexadas, e você junta o resto à mão.
• As suas edições sobrevivem à sincronização. Um cargo que você corrigiu não é sobrescrito, e um e-mail que você apagou não volta.
• Cada pessoa carrega a sua correspondência com ela, montada sozinha a partir de e-mails e mensagens entre canais, então o registro responde “qual é o meu histórico aqui” e não só “qual é o número dela”.
• Contatos pode ser compartilhado com um time, o que significa que uma passagem de mão começa do histórico de verdade, e não de um nome.
• Isto não é um sistema de registro e não vai virar um. Sem negócios, sem funil, sem previsão.
• Um contato novo é um gatilho de fluxo. Dali, um fluxo pode escrever uma página no Brain para a pessoa, empurrá-la ao Salesforce ou ao HubSpot por MCP, compartilhá-la com um time, ou acrescentar uma nota com data, e passos de agente fazem o mesmo com registro de auditoria.
• Contatos é uma prova pequena da aposta em que o Brain se apoia: a manutenção tem que vir da comunicação que um time já produz, e uma camada de conhecimento que chega povoada ganha de uma que começa vazia e pede para ser alimentada. Um Brain que se mantém sozinho em tudo que uma empresa sabe é a meta maior.