Por que seu CRM tem onze construtores de filtros

Abra um CRM maduro e faça este teste. Crie um filtro em uma visualização de lista. Depois crie o mesmo filtro como segmento de marketing. Depois como condição dentro de uma automação. E depois como filtro de relatório. Quatro construtores, quatro conjuntos de operadores um pouco diferentes e pelo menos um lugar onde falta justamente o que você precisa.

Isso é quase universal na categoria, e não é porque as equipes que fazem esses produtos sejam descuidadas. É o resultado previsível de tratar a filtragem como um recurso, e não como um motor, e quem paga é você, toda semana, de um jeito difícil de apontar numa avaliação, mas óbvio no uso diário.

Como isso acontece

Um CRM é lançado com visualizações de lista. Alguém escreve um construtor de filtros para elas. Dois anos depois a empresa adiciona marketing, e a equipe de marketing precisa segmentar públicos. Ela poderia reaproveitar o filtro das listas, mas esse código está preso a uma interface de tabela, pressupõe um tamanho de página e fica em um módulo que não é da equipe de marketing. A decisão pragmática, a que qualquer gerente de engenharia sensato toma com um prazo apertado, é escrever um construtor de segmentos.

Aí chegam as automações, que precisam de condições. Depois os relatórios, que precisam de filtros com agrupamento. Depois as permissões por registro, que no fundo são um filtro aplicado de forma invisível a cada consulta. Depois a busca com IA, que precisa transformar uma frase em uma consulta. Cada um é feito por uma equipe diferente, em um trimestre diferente, com um prazo diferente.

Nada está quebrado. Todos os construtores funcionam. Mas eles vão se distanciando, e na filtragem essa diferença é especialmente traiçoeira, porque ninguém vê nada até o problema aparecer:

• A visualização de lista trata um texto vazio e um valor nulo como a mesma coisa. O construtor de segmentos não.
• A visualização de lista consegue filtrar por um campo de um registro relacionado. O construtor de relatórios só filtra pelo objeto que está na frente dele.
• A condição da automação avalia datas em UTC. A visualização avalia no seu fuso horário. As duas escolhas fazem sentido; juntas, viram um bug que vai custar uma tarde sua.
• Um construtor tem “é um de”. Outro só tem “é igual a”, então você monta três regras ligadas por um OU.

O resultado é que a resposta para “dá para filtrar por isso?” nunca é sim ou não. É “em qual tela você está?”

Quanto isso custa de verdade

Três coisas, em ordem crescente de importância.

Você aprende a filtrar várias vezes

Cada pessoa nova na equipe aprende quatro construtores em vez de um, e aprende descobrindo as diferenças. Isso aparece como um atraso lento e difícil de atribuir no onboarding, sobre o qual ninguém abre um chamado.

A lógica é redigitada em vez de reaproveitada

Você define “contas enterprise sem atividade há trinta dias” em uma visualização. Mais tarde quer uma campanha para esse público, então recria tudo no construtor de segmentos. Depois uma automação, então recria de novo. Agora você tem três definições da mesma ideia, mantidas à mão. Quando a definição muda (enterprise passa a ser 200 licenças em vez de 100), você precisa lembrar das três. Não vai lembrar.

Os recursos chegam de forma desigual, para sempre

Essa é a que se acumula. Quando o produto ganha um operador novo, ele entra no construtor que a equipe responsável mantém. Cinco anos assim e a distância entre o seu filtro mais capaz e o menos capaz é enorme, e todo pedido no roadmap vira “em qual dos cinco você quer primeiro?”

Uma visualização salva, um segmento de marketing, uma condição de fluxo de trabalho, um filtro de relatório e uma pergunta digitada para a IA deveriam ser o mesmo objeto passando pelo mesmo compilador.

A alternativa, e o que ela exige

A alternativa é transformar a filtragem em um motor que todo o resto usa. Uma única representação de filtro (uma definição estruturada e serializável) e um único compilador que a transforma em uma consulta ao banco de dados. Cada tela vira uma forma diferente de montar ou exibir esse mesmo objeto.

Isso não sai de graça. Exige uma disciplina bem desconfortável:

1. O formato do filtro precisa ser projetado antes dos recursos que o usam, ou seja, justamente quando você tem menos certeza sobre os requisitos.
2. Cada parte que o usa precisa aceitar as regras comuns, inclusive as que atrapalham a sua tela.
3. Ninguém pode adicionar um caso especial rápido. Um caso especial em um motor compartilhado é um caso especial em cinco produtos.
4. Você precisa de testes de conformidade, porque uma diferença sutil no compilador agora é uma diferença sutil em todo lugar ao mesmo tempo.

A recompensa é que os recursos chegam por igual. Quando adicionamos a navegação por registros relacionados, ela aparece em visualizações, segmentos, condições de automação, relatórios, permissões e busca com IA no mesmo dia, não porque cinco equipes se coordenaram, mas porque sempre houve uma só implementação.

O que nos surpreendeu

Esperávamos que a recompensa fosse produtividade de engenharia. A maior recompensa vai ser a IA.

Quando você faz uma pergunta sobre seus dados a um copiloto de IA, ele precisa produzir alguma coisa. Se produz um texto, você não consegue conferir. Se produz SQL puro, pode inventar uma consulta que não respeita suas permissões, ou que está errada de um jeito sutil que você não vai perceber.

Como já temos exatamente um formato de filtro, a busca em linguagem simples que estamos construindo gera esse formato. Ela chega em breve, e é por isso que vai ser confiável. Três consequências vêm de brinde, e nenhuma delas foi o motivo da decisão:

• Ela não consegue expressar um filtro que o produto não consiga executar: o formato é o limite.
• Ela herda as permissões automaticamente, porque o compilador é o mesmo que aplica o acesso por registro na interface.
• Você pode ler o que ela escreveu, corrigir e salvar como visualização. A resposta pode ser auditada, e uma resposta auditável é uma em que, com o tempo, você pode confiar para agir sozinha.

A decisão de arquitetura que parecia arrumação interna é o que vai fazer a busca com IA ser confiável, e não decorativa. Costuma ser assim com fundações: o motivo pelo qual você fica feliz de ter construído uma raramente é o motivo pelo qual construiu.

Como conferir isso você mesmo

Você não precisa acreditar numa promessa de arquitetura. No teste de qualquer CRM, dedique dez minutos a isto:

1. Crie em uma visualização de lista um filtro um pouco complicado, que envolva um registro relacionado e um valor vazio.
2. Tente criar exatamente o mesmo filtro como público de uma campanha.
3. Tente de novo como condição de uma automação, e mais uma vez como filtro de relatório.
4. Faça à IA uma pergunta que deveria gerar esse mesmo filtro, e veja se consegue examinar o que ela executou.

Se os cinco concordarem, o produto tem um motor. Se não, você encontrou os onze construtores, e já sabe em qual dos cinco vai faltar o operador de que você vai precisar no quarto mês.