Por qué tu CRM tiene once constructores de filtros

Abre un CRM maduro y haz esta prueba. Crea un filtro en una vista de lista. Luego crea el mismo filtro como segmento de marketing. Después como condición dentro de una automatización. Y luego como filtro de un informe. Cuatro constructores, cuatro conjuntos de operadores ligeramente distintos y al menos un lugar donde falta justo lo que necesitas.

Esto es casi universal en la categoría, y no es porque los equipos que crean estos productos sean descuidados. Es el resultado previsible de tratar el filtrado como una función y no como un motor, y el costo lo pagas tú, cada semana, de una forma difícil de nombrar en una evaluación pero evidente en el uso diario.

Cómo sucede

Un CRM sale al mercado con vistas de lista. Alguien escribe un constructor de filtros para esas vistas. Dos años después la empresa suma marketing, y el equipo de marketing necesita segmentar audiencias. Podrían reutilizar el filtro de las vistas de lista, pero ese código está atado a una interfaz de tabla, asume un tamaño de página y vive en un módulo que no es del equipo de marketing. La decisión pragmática, la que tomaría cualquier gerente de ingeniería sensato con una fecha límite encima, es escribir un constructor de segmentos.

Luego llegan las automatizaciones, que necesitan condiciones. Luego los informes, que necesitan filtros con agrupación. Luego los permisos por registro, que en el fondo son un filtro aplicado de forma invisible a cada consulta. Luego la búsqueda con IA, que necesita convertir una frase en una consulta. Cada uno lo construye un equipo distinto, en un trimestre distinto, con una fecha límite distinta.

Nada está roto. Todos los constructores funcionan. Pero se van separando, y en el filtrado esa separación es especialmente dañina, porque las diferencias no se ven hasta que te muerden:

• La vista de lista trata un texto vacío y un valor nulo como lo mismo. El constructor de segmentos no.
• La vista de lista puede filtrar por un campo de un registro relacionado. El constructor de informes solo puede filtrar por el objeto que tiene delante.
• La condición de la automatización evalúa las fechas en UTC. La vista las evalúa en tu zona horaria. Ambas cosas tienen sentido; juntas son un error que te va a costar una tarde.
• Un constructor tiene “es uno de”. Otro solo tiene “es igual a”, así que terminas creando tres reglas unidas con un O.

El resultado es que la respuesta a “¿puedo filtrar por eso?” nunca es sí o no. Es “¿en qué pantalla estás?”

Lo que de verdad te cuesta

Tres cosas, de menor a mayor importancia.

Aprendes a filtrar varias veces

Cada persona nueva en tu equipo aprende cuatro constructores en lugar de uno, y los aprende descubriendo las diferencias. Eso se nota como un freno lento e imposible de atribuir en la incorporación, sobre el que nadie abre un ticket.

La lógica se vuelve a escribir en lugar de reutilizarse

Defines “cuentas enterprise sin actividad en treinta días” en una vista. Más tarde quieres una campaña para esa audiencia, así que la vuelves a crear en el constructor de segmentos. Después una automatización, así que la creas otra vez. Ahora tienes tres definiciones de una misma idea, mantenidas a mano. Cuando la definición cambia (enterprise pasa a ser 200 puestos en lugar de 100), tienes que acordarte de las tres. No lo harás.

Las capacidades llegan de forma desigual, para siempre

Esta es la que se acumula. Cuando el producto agrega un operador nuevo, aparece en el constructor que mantiene el equipo responsable. Cinco años así y la distancia entre tu filtro más capaz y el menos capaz es enorme, y cada pedido para el roadmap se convierte en “¿en cuál de los cinco lo quieres primero?”

Una vista guardada, un segmento de marketing, una condición de flujo de trabajo, un filtro de informe y una pregunta escrita a la IA deberían ser el mismo objeto pasando por el mismo compilador.

La alternativa, y lo que exige

La alternativa es convertir el filtrado en un motor que todo lo demás utiliza. Una sola representación de un filtro (una definición estructurada y serializable) y un solo compilador que la convierte en una consulta a la base de datos. Cada pantalla pasa a ser una forma distinta de construir o mostrar ese mismo objeto.

Esto no es gratis. Exige una disciplina realmente incómoda:

1. El formato del filtro tiene que diseñarse antes que las funciones que lo usan, es decir, justo cuando menos seguro estás de los requisitos.
2. Cada parte que lo usa tiene que aceptar las reglas comunes, incluidas las que resultan incómodas para su pantalla.
3. Nadie puede agregar un caso especial rápido. Un caso especial en un motor común es un caso especial en cinco productos.
4. Necesitas pruebas de conformidad, porque una diferencia sutil en el compilador ahora es una diferencia sutil en todas partes a la vez.

La recompensa es que las capacidades llegan de forma pareja. Cuando agregamos el recorrido de registros relacionados, aparece en vistas, segmentos, condiciones de automatización, informes, permisos y búsqueda con IA el mismo día, no porque cinco equipos se coordinaran, sino porque siempre hubo una sola implementación.

Lo que nos sorprendió

Esperábamos que la recompensa fuera productividad de ingeniería. La recompensa más grande va a ser la IA.

Cuando le haces una pregunta sobre tus datos a un copiloto de IA, tiene que producir algo. Si produce un texto, no lo puedes verificar. Si produce SQL directo, puede inventar una consulta que no respete tus permisos, o que esté mal de una forma sutil que no vas a notar.

Como ya tenemos exactamente un formato de filtro, la búsqueda en lenguaje sencillo que estamos creando produce ese formato. Llega pronto, y por eso va a ser confiable. De ahí salen tres consecuencias sin esfuerzo extra, y ninguna fue el motivo de la decisión:

• No puede expresar un filtro que el producto no pueda ejecutar: el formato es el límite.
• Hereda los permisos automáticamente, porque el compilador es el mismo que aplica el acceso por registro en la interfaz.
• Puedes leer lo que escribió, corregirlo y guardarlo como vista. La respuesta se puede auditar, y una respuesta auditable es una en la que con el tiempo puedes confiar para que actúe por su cuenta.

La decisión de arquitectura que parecía orden interno es lo que hará que la búsqueda con IA sea confiable y no decorativa. Así suele pasar con los cimientos: la razón por la que te alegras de haberlos construido casi nunca es la razón por la que los construiste.

Cómo comprobarlo tú mismo

No tienes que creer a ciegas una promesa de arquitectura. En la prueba de cualquier CRM, dedica diez minutos a esto:

1. Crea en una vista de lista un filtro algo complicado, que incluya un registro relacionado y un valor vacío.
2. Intenta crear el mismo filtro como audiencia de una campaña.
3. Inténtalo otra vez como condición de una automatización, y una vez más como filtro de un informe.
4. Hazle a la IA una pregunta que debería producir ese mismo filtro, y mira si puedes revisar lo que ejecutó.

Si los cinco coinciden, el producto tiene un motor. Si no, encontraste los once constructores, y ya sabes a cuál de los cinco le va a faltar el operador que necesites en el cuarto mes.