Definición operativa de silo
Un silo de datos no es “tener varias herramientas” — es tener el mismo hecho de negocio guardado en más de un lugar, sin que ninguno de esos lugares sepa que el otro existe. El síntoma típico: marketing ve una empresa como lead frío, ventas la tiene como oportunidad activa, y ninguno de los dos sistemas puede reconciliar cuál versión es la verdadera sin intervención manual.
Modelo hub-and-spoke vs. capa única
| Dimensión | Hub-and-spoke tradicional | Capa Única de Señales |
|---|---|---|
| Dónde vive el dato | Duplicado: CRM, hoja de cálculo, herramienta de marketing | Una tabla, un registro por empresa |
| Quién escribe en el CRM | Múltiples integraciones, cada una con su propia lógica | RevSign no escribe en el CRM — no lo necesita para operar |
| Qué pasa si dos fuentes descubren la misma empresa | Se crean registros duplicados que hay que fusionar a mano | Un índice único por dominio hace que la segunda escritura actualice la misma fila, no cree una nueva |
| Costo de cambiar de CRM | Alto: hay que migrar o re-mapear cada integración | Cero: la capa de señales nunca dependió del CRM para existir |
Por qué no hay integración de escritura hacia HubSpot o Salesforce
RevSign no escribe señales, notas ni tareas directamente dentro de un CRM. Esto no es una limitación pendiente de resolver — es la decisión de arquitectura que evita el problema de raíz: cada integración de escritura hacia una herramienta externa es un punto más donde el dato se puede desincronizar. El sistema tuvo en versiones anteriores una sincronización directa con HubSpot; se retiró deliberadamente, y las columnas que quedaban de esa integración se archivaron y después se eliminaron del esquema.
Lo que sí existe es un mecanismo de salida genérico: un webhook disparado por evento (una señal creada, aprobada o rechazada) hacia una URL que cada cliente configura — Make.com, n8n, Slack, o un endpoint propio. Ese webhook es agnóstico a la herramienta de destino; conectarlo a un CRM específico es una automatización del lado del cliente, no una integración que RevSign tenga que mantener por cada plataforma.
Escrituras idempotentes y resolución de conflictos
Cuando dos procesos de ingesta distintos descubren la misma empresa —por ejemplo, un escaneo de stack tecnológico y un hallazgo del radar de narrativas— no se crean dos filas. Un índice único sobre el dominio de la empresa hace que la segunda escritura actualice el mismo registro. Cuando dos identificadores distintos terminan apuntando a la misma empresa real (un caso típico: un rebranding o una redirección de dominio), existe lógica de resolución de colisión: la fila que tiene más columnas completas gana, las referencias de otras tablas se re-apuntan hacia esa fila ganadora, y la fila perdedora se marca como fusionada — nunca se borra.
Qué pasa cuando cambiás de herramienta
La capa de señales no tiene ninguna columna ni lógica específica de una herramienta de CRM. Los únicos identificadores que persisten en el registro de una empresa son agnósticos: el dominio y un identificador de enriquecimiento opcional. Cambiar de HubSpot a Salesforce, o directamente no usar CRM, no requiere ningún cambio en la capa de datos — es exactamente lo que ya se validó al retirar la integración legacy sin romper nada del resto del sistema.
$ curl revsign.os/docs/cero-silos-de-datos
→ {
title: "Cero Silos de Datos: una fuente de verdad sin migrar de CRM",
answers: "¿Cómo elimino silos de datos entre marketing y ventas sin migrar de CRM?",
schema: [TechArticle]
}