El filtro es el producto en un sistema de captación proactiva
Captación proactiva multiportal. Cinco fuentes públicas en una sola tabla, un clasificador de tres señales en el cuello y escalado temporal por diseño.
- arquitectura
- captación
- scraping
- clasificación
- trade-offs
Diseñé un sistema que detecta oportunidades comerciales en fuentes públicas veinticuatro horas al día y las pone en la mano del comercial correcto con contexto suficiente para llamar. Cinco fuentes de entrada, una tabla, un panel. El diseño está entregado completo y no está implementado. La decisión que sostiene todo el sistema no es ninguna de las cinco fuentes: es el filtro que va detrás.
Tres fugas simultáneas y un flujo de ruido
El problema de negocio eran tres fugas al mismo tiempo.
La primera: lo que entra fuera de horario se pierde sin registro. Noches, fines de semana, festivos. Un buzón de voz que nadie escucha es indistinguible de no tener teléfono.
La segunda: lo que un particular publica en un portal de anuncios lo contacta la competencia en cuestión de horas. El plazo útil se mide en horas, no en días, y nadie estaba mirando.
La tercera es la que menos se ve y la que más vale: las señales indirectas. Una bajada de precio. Un anuncio que lleva semanas parado. Un activo en procedimiento concursal. Nadie las vigila porque a mano no da tiempo.
Traducido a problema de sistema: hay un flujo continuo, público y ruidoso, y hace falta convertirlo en un número pequeño de acciones asignadas a una persona concreta con un plazo.
Las decisiones que sostienen el embudo
Una sola tabla de oportunidades, discriminada por tipo. Cinco fuentes muy distintas —canal de voz, scraping de portales, detección de cambios de precio, antigüedad de anuncio, fuentes públicas oficiales— escriben en la misma entidad, con un campo de tipo y columnas específicas por tipo. Trade-off aceptado: una tabla ancha con columnas que están nulas la mayor parte del tiempo y validación que depende del tipo, a cambio de que exista la única pantalla que de verdad importa: "todo lo que tengo pendiente hoy, ordenado por prioridad", sin que importe de dónde vino cada cosa.
Clasificador de origen del anuncio antes que cualquier otra cosa. Distinguir lo publicado por un particular de lo publicado por un profesional, combinando tres señales independientes: la huella del teléfono, el análisis del texto y los patrones del anunciante. Trade-off aceptado: el sistema descarta oportunidades legítimas cuando las tres señales apuntan mal, es decir, pierdo recall a cambio de precisión. Es la dirección correcta del error aquí. Sin filtro, el sistema produce cientos de señales al día que son casi todas competencia, el comercial ve que ocho de cada diez alertas no valen y deja de mirar el panel en una semana. Un sistema de detección sin filtro de calidad no es un activo: es spam interno con panel bonito.
Asignación determinista por zona, no reparto equitativo. Cada código postal tiene un responsable principal y uno de respaldo, en una tabla explícita. Trade-off aceptado: la carga de trabajo queda desequilibrada entre comerciales y hay que gestionarla a mano, a cambio de preservar el conocimiento local, que es precisamente lo que hace útil a esa persona en esa llamada.
Notificación con guion, no alerta genérica. Al responsable le llega la oportunidad con un guion de llamada adaptado al caso concreto. Trade-off aceptado: generar el guion cuesta una llamada a un modelo por oportunidad y añade latencia y coste por señal, a cambio de no trasladar el trabajo cognitivo a quien la recibe. "Nueva oportunidad detectada" obliga al comercial a reconstruir el contexto; un guion convierte la notificación en la primera línea de la conversación.
Escalado temporal automático como parte del diseño, no como añadido. Sin respuesta en veinticuatro horas, recordatorio. A las cuarenta y ocho, reasignación al respaldo. A las setenta y dos, alerta a dirección. Trade-off aceptado: el sistema genera presión medible sobre el equipo comercial y eso tiene un coste político real dentro de la organización, a cambio de que el sistema no se convierta en un cementerio de oportunidades detectadas y no trabajadas. Ese cementerio es peor que no detectar nada: cuesta dinero y además da la sensación de estar cubierto.
Definición dura de "cualificado". Una señal no se considera lista hasta que lleva superficie verificada en fuente oficial, valoración con comparables, situación de cargas y de ocupación, y horizonte temporal del propietario. Trade-off aceptado: el enriquecimiento retrasa la entrega de la señal y una parte de las señales nunca llega a completarse, a cambio de resolver antes de la primera llamada las tres cosas que matan la operación en la semana cuatro. Es la diferencia entre un listado de teléfonos y una oportunidad.
Orquestación en un motor de flujos, lógica de negocio en servicios propios. Los flujos declarativos coordinan; el scraping, la clasificación y el scoring viven en servicios con su propio código y sus propias pruebas. Trade-off aceptado: más piezas que un monolito, más superficie de despliegue y más sitios donde mirar cuando algo falla, a cambio de poder cambiar o sustituir una fuente sin tocar el resto del sistema. Con fuentes públicas que cambian sin avisar, eso no es un lujo.
Lo que hay que mirar en el diagrama es el cuello: muchas entradas, un punto de clasificación, una sola salida asignada. Si el estrechamiento no está ahí, el sistema no sirve.
Qué descarté y por qué
Una tabla por fuente. Es el descarte más importante y el menos intuitivo. Cinco fuentes con formas de dato distintas piden cinco tablas: cada una limpia, cada una validada, cada una con sus índices. Modelo de datos impecable. Y hace imposible la pantalla que justifica el sistema entero, porque "lo que tengo pendiente hoy" pasa a ser una unión de cinco consultas con esquemas distintos que hay que reescribir cada vez que se añade una fuente. La normalización estaba compitiendo contra el caso de uso principal, y en esa pelea gana el caso de uso.
El reparto round-robin de oportunidades. Descartado. Es más justo en la hoja de cálculo, se defiende mejor en una reunión y destruye el conocimiento local, que es lo único que el comercial aporta de más que un formulario.
Alertas genéricas. Descartadas. Son gratis de implementar y trasladan el coste al receptor, que es donde el coste no se mide y por tanto nunca se corrige.
El escalado como fase dos. Descartado. Era el candidato natural a recortar del alcance inicial y es justo la pieza que impide que el sistema se convierta en un archivo de oportunidades muertas.
Un monolito único. Descartado sabiendo que salía más barato de construir: el coste de la modularidad se paga una vez, el de acoplarlo todo se paga en cada cambio de fuente.
Estado real, sin adornos
Diseño completo entregado. No implementado.
Lo entregado: modelo de datos unificado, los cinco subsistemas especificados, las integraciones, el plan de despliegue, el análisis de cumplimiento de protección de datos y el desglose de costes de operación. Cero líneas de implementación.
Y aquí va el dato honesto, el más útil del artículo. Resolví este mismo problema de diseño dos veces en veinticinco días, para dos contextos distintos, empezando de cero la segunda vez. La primera versión estaba montada sobre herramientas no-code y estaba prácticamente terminada. La segunda es la arquitectura que acabo de describir. Ninguna de las dos se cerró.
Para contraste: sí tengo sistemas en producción y facturando. Copy-on-Select está publicado y a la venta, MultiInstanceClaudeDesktop también, y hay un SaaS fiscal propio en producción con clientes reales. Porque existen, no necesito contar un diseño como si fuera un despliegue.
Lecciones transferibles, y una que escuece
La lección de arquitectura tiene dos mitades. La primera: en un sistema de detección, la parte difícil nunca es detectar. Es decidir qué no enseñas, y ese filtro es el producto. La segunda: normalizar es un objetivo intermedio, no un objetivo. Cuando la forma limpia del esquema estorba a la consulta que justifica el sistema, se sacrifica y se documenta por qué.
La lección de proceso: el bucle de cierre parece un extra y es infraestructura. Un sistema que detecta y no cierra produce la sensación de control sin el control, y nadie la audita.
Y la incómoda, que no es técnica. Era un producto y lo traté como dos consultorías a medida, y por eso hice dos veces el mismo trabajo. Pero el patrón real es peor que la ineficiencia: cada vez que un proyecto se acercaba al momento de vender, yo empezaba uno nuevo. Construir no expone a nada. Cerrar expone. Diseñar dos arquitecturas era la forma sofisticada de no cerrar ninguna.
Versión corta en LinkedIn: Resolví el mismo problema dos veces en 25 días sin cerrar ninguno de los dos — linkedin.com/in/carlosdelatorre-ai
Relacionado
- Detección de señales en fuentes públicas oficiales — el subsistema de fuentes oficiales de este mismo diseño.
- Diseñé una app de autoservicio que no guarda ni un dato del cliente — el caso contrario: cuando la fuente única de verdad ya existe y no se toca.
- Fábrica de repaquetizado orquestada por agentes de IA — triaje antes de ejecutar, en un pipeline multiagente.