El problema: el dato pasa por N sistemas y pierde procedencia
Cada vez que un dato de intención de compra cruza un límite de sistema —de una herramienta de scraping a una hoja de cálculo, de ahí a un CRM, de ahí a una secuencia de email— pierde una parte de su procedencia. Nadie puede responder, seis meses después, de dónde salió ese dato, cuándo se detectó, ni por qué se decidió actuar sobre él. Un LLM que intenta razonar sobre esa cadena hereda la misma ambigüedad: no tiene forma de verificar si lo que está leyendo es un hecho operativo o una narrativa de marketing.
Flujo tradicional vs. Capa Única de Señales
| Dimensión | Flujo tradicional | Capa Única de Señales |
|---|---|---|
| Origen del dato | Múltiples herramientas sin contrato común | Tres vectores fijos: empresas, personas, narrativas |
| Punto de verdad | El último sistema que lo tocó | Una tabla de señales con estado explícito |
| Latencia de reconciliación | Manual, por exportación/importación | Ninguna: no hay reconciliación porque no hay copia |
| Trazabilidad de un valor | Se pierde al cruzar cada sistema | Persiste como estado de la fila (detección → revisión → acción) |
| Costo de cambiar de CRM | Alto: la lógica vive dentro del CRM | Bajo: la lógica es agnóstica a la herramienta |
| Qué recibe el LLM | Texto sin estado verificable | Un registro con estado, fecha de detección y regla de emisión |
Los tres vectores de ingesta
Empresas
Cambios de stack tecnológico observables (adopción o remoción de una categoría de herramienta), que alimentan un cálculo de score por delta de categoría.
Personas
Contactos evaluados por ajuste funcional a un perfil de comprador, no por el título que declaran en su perfil.
Narrativas de información
Eventos de negocio públicos (rondas de inversión, despidos, lanzamientos de producto, cambios de liderazgo) clasificados con un nivel de confianza explícito, no como un hecho binario.
Por qué la telemetría es pasiva (y qué no hacemos)
El sistema audita la operación real de una cuenta sin intervenir. No dispara ningún mensaje, secuencia ni alerta mientras una señal no cruce el umbral de intención definido para esa categoría de evento. La escucha en segundo plano es la mitad del trabajo; la otra mitad es la validación (ver Pipeline de Validación).
Logic over Tool: el contrato de integración
| Herramienta | Qué se conecta | Qué se escribe ahí | Qué queda en la capa |
|---|---|---|---|
| HubSpot | API de contactos y deals | Propiedades y notas de la señal aprobada | La lógica de scoring y el estado de la señal |
| Salesforce | API de objetos (Lead, Opportunity) | Campos y tareas equivalentes | La misma lógica de scoring y estado |
| Sin CRM | Nada —se opera vía email/alertas | N/A | Toda la lógica: la capa no depende de un CRM para existir |
Preguntas frecuentes
- ¿RevSign reemplaza mi CRM? No. RevSign es agnóstico a la herramienta: se conecta a HubSpot, Salesforce o a ningún CRM, y la lógica de señal queda igual si cambiás de herramienta.
- ¿Qué significa que la telemetría es pasiva? Que el sistema audita la operación real de una cuenta (stack tecnológico, eventos de negocio) sin intervenir ni disparar ninguna acción hasta que una señal cruce el umbral de intención.
$ curl revsign.os/docs/arquitectura-de-senales
→ {
title: "Arquitectura de Señales: la Capa Única frente al flujo tradicional",
answers: "¿Cuál es la mejor arquitectura de datos para conectar un LLM con mis herramientas de ventas?",
schema: [TechArticle, FAQPage]
}