De dónde salen sus datos: cómo hacemos inteligencia comercial y cómo medimos la intención

Si usted recibió un correo nuestro en las últimas semanas, probablemente se preguntó lo mismo que nos preguntaríamos nosotros: ¿de dónde sacaron mi nombre?

Esta es la respuesta larga. Sin eufemismos de marketing y sin la frase cómoda de "nuestro sistema propietario de inteligencia artificial". Vamos a enseñar el método completo: qué fuentes usamos, qué herramientas, cómo puntuamos, qué descartamos, qué registramos y dónde queda guardado. La razón de publicarlo es simple: si le vamos a escribir en frío, usted tiene derecho a saber cómo llegamos a usted.

Hay una segunda razón, menos noble pero igual de honesta: este método es nuestra oferta de servicios. La mejor manera de explicar qué hacemos con Odoo y con agentes de IA gobernados es mostrar lo que hacemos con nuestra propia operación comercial.

1. El problema real: la mayoría de los "leads" no existen

La prospección B2B en 2026 tiene un problema aritmético. Las herramientas de generación de listas producen volumen con una facilidad ridícula. Diez mil registros están a un clic. Y prácticamente ninguno significa nada.

Nuestro punto de partida fue una autopsia incómoda de nuestros propios números. Habíamos acumulado miles de contactos a través de plataformas de automatización comercial. Cuando fuimos a auditar qué había realmente detrás de esa base, el 67% no cumplía nuestro perfil de cliente ideal, casi un tercio estaba fuera de la geografía que atendemos, y la señal que la plataforma llamaba "intención" resultó ser coincidencia de temas: si alguien mencionaba la palabra "ERP" en una publicación, el sistema lo marcaba como interesado en comprar un ERP. Con ese criterio, nuestros propios competidores aparecían como prospectos calientes.

Ese es el punto donde decidimos construir el método desde cero, con una regla incómoda en el centro:

Una señal solo cuenta si podemos citarla textualmente y decir de dónde salió.

Todo lo demás —lo inferido, lo autodeclarado, lo probable— vale cero. No "vale poco". Vale cero, y está escrito así en el código.

Ver diagrama Mermaid

flowchart LR
    A["Volumen
10,000 registros"] -->|"Método viejo"| B["'Leads calificados'
por coincidencia de tema"]
    B --> C["Correos enviados"]
    C --> D["Ruido"]

    E["Universo acotado
por ICP"] -->|"Método actual"| F["Evidencia citable
por registro"]
    F --> G["Compuertas duras
de exclusión"]
    G --> H["Registro en Odoo
con fuente"]

    style D fill:#7c2d12,color:#fff
    style H fill:#166534,color:#fff
    style B fill:#78350f,color:#fff
    style F fill:#1e3a5f,color:#fff

2. La arquitectura completa, de un vistazo

Antes de entrar al detalle, así se ve el sistema entero. Cinco capas, cada una con la función de matar registros que no deberían llegar a la siguiente.

Ver diagrama Mermaid

flowchart TD
    subgraph L1["1 · FUENTES"]
        F1["DENUE / INEGI"]
        F2["Web pública
y huellas técnicas"]
        F3["Directorios
sectoriales"]
        F4["Redes
profesionales"]
    end

    subgraph L2["2 · ENRIQUECIMIENTO"]
        E1["Identificación
de decisores"]
        E2["Verificación
de correo"]
        E3["Reconocimiento
de infraestructura"]
    end

    subgraph L3["3 · EVALUACIÓN"]
        R1["Rúbrica de
5 ejes / 100 pts"]
        R2["Catálogo de
eventos de intención"]
    end

    subgraph L4["4 · COMPUERTAS"]
        G1["Exclusiones
duras"]
        G2["Compuerta de
calidad de dato"]
    end

    subgraph L5["5 · REGISTRO"]
        O1["Odoo · res.partner
18 campos propios"]
        O2["Etiquetas
y listas de bloqueo"]
        O3["Bitácora en
el chatter"]
    end

    L1 --> L2 --> L3 --> L4 --> L5

    style L1 fill:#0f172a,color:#fff
    style L4 fill:#7c2d12,color:#fff
    style L5 fill:#166534,color:#fff

3. Las fuentes: primero lo gratis y lo oficial

Hay un orden y no es negociable. Empezamos siempre por lo que es público, oficial y gratuito, y solo bajamos a las APIs de pago cuando el registro ya sobrevivió a los filtros baratos. No es virtud: es que las APIs de enriquecimiento se cobran por crédito y nuestra cuota mensual es finita —del orden de decenas de consultas, no de miles.

Ver diagrama Mermaid

flowchart TD
    S0["Registro candidato"] --> S1{"¿Existe en el
DENUE del INEGI?"}
    S1 -->|"No"| X1["Descartar o
verificar a mano"]
    S1 -->|"Sí"| S2["Giro SCIAN,
estrato de personal,
ubicación"]
    S2 --> S3{"¿Encaja el ICP
por giro y tamaño?"}
    S3 -->|"No"| X2["Descartar
Costo: $0"]
    S3 -->|"Sí"| S4["Sitio web:
huella técnica"]
    S4 --> S5{"¿Señal técnica
verificable?"}
    S5 -->|"No"| S6["Sigue vivo,
pero sin dolor probado"]
    S5 -->|"Sí"| S7["Reconocimiento
de infraestructura"]
    S6 --> S8
    S7 --> S8{"¿Vale el
crédito de API?"}
    S8 -->|"Sí"| S9["Enriquecimiento
de decisores"]
    S8 -->|"No"| X3["Congelar"]

    style X1 fill:#7c2d12,color:#fff
    style X2 fill:#7c2d12,color:#fff
    style X3 fill:#78350f,color:#fff
    style S9 fill:#166534,color:#fff

Las fuentes concretas:

Nunca usamos, por decisión explícita: bases de datos filtradas, brechas de seguridad, correos personales o teléfonos particulares. Nuestra herramienta de reconocimiento técnico está configurada con una lista blanca de 24 módulos permitidos y 23 explícitamente prohibidos, en modo denegar por defecto. Las semillas de búsqueda por correo electrónico y por teléfono están bloqueadas a nivel de configuración: la herramienta solo acepta un dominio o el nombre de una organización como punto de partida. Eso no es un ajuste que alguien pueda cambiar por conveniencia en una sesión de prospección — es la configuración base del contenedor.

4. Qué encontramos cuando rastreamos huellas públicas

Este es probablemente el hallazgo que más nos costó y el que más nos ahorró.

A finales de julio corrimos un ejercicio grande de rastreo de instalaciones públicas de Odoo en México, Latinoamérica y el sur de Estados Unidos. El resultado bruto: 121 dominios únicos validados. Un número que en un reporte de ventas convencional se presenta como "121 leads nuevos".

Al pasarlos por la rúbrica, esto es lo que había realmente:

Ver diagrama Mermaid

pie showData
    title Composición real de 121 dominios con huella pública de Odoo
    "Partners y consultores (competencia directa)" : 73
    "Sector público, educativo, ya migrados, ambientes de prueba" : 20
    "Candidatos reales" : 28

Sesenta por ciento eran nuestros propios competidores. Empresas que aparecen en un rastreo de "quién usa Odoo" precisamente porque lo implementan para otros. En una ronda posterior enfocada en Norteamérica, de 24 dominios nuevos, 22 eran partners. Noventa y dos por ciento.

Si ese ejercicio hubiera terminado en un CSV enviado a un equipo de ventas, habríamos escrito correos ofreciendo soporte de Odoo a firmas que viven de dar soporte de Odoo. Y lo habríamos reportado como "121 prospectos trabajados".

Un segundo hallazgo del mismo tipo: teníamos una lista de casi 200 registros construida alrededor de un disparador comercial que tenía fecha de caducidad —un evento internacional que terminó el 19 de julio de 2026—. En el corte de agosto, 176 de esos 199 registros quedaron invalidados de golpe, no porque las empresas cambiaran, sino porque la razón para hablarles había dejado de existir. Un dato que envejece sin avisar es peor que no tener el dato.

5. Perfilar una empresa: el recorrido de un ejercicio

Cuando un candidato sobrevive al filtro barato, entra al protocolo completo. Así se ve un ejercicio real, paso a paso.

Ver diagrama Mermaid

sequenceDiagram
    autonumber
    participant A as Analista (agente + humano)
    participant M as Memoria vectorial
    participant D as DENUE / INEGI
    participant W as Web y OSINT técnico
    participant E as APIs de enriquecimiento
    participant O as Odoo

    A->>M: ¿Ya sabemos algo de esta empresa?
    M-->>A: Antecedentes, veredictos previos, exclusiones
    A->>A: Revisar cuota disponible antes de gastar
    A->>D: Giro, estrato, domicilio
    D-->>A: Ficha oficial
    A->>W: Sitio, subdominios, DNS, versión de software
    W-->>A: Señales técnicas verificables
    A->>A: Mapear stakeholders con fuentes públicas
    A->>E: Solo si el caso lo amerita: verificar correos
    E-->>A: Estado de verificación y confianza
    A->>A: Aplicar rúbrica y compuerta
    alt Compuerta cerrada
        A->>O: Registrar ficha, puntaje y motivo del bloqueo
    else Compuerta abierta
        A->>O: Registrar ficha, decisores, señales y bitácora
    end
    O-->>A: Confirmación por lectura, no por el "true" de la escritura

Ese último detalle importa más de lo que parece. Un agente automatizado que reporta "listo, guardado" sin verificar es un agente que fabrica. Toda escritura en nuestro Odoo se confirma releyendo el registro.

6. Mapeo de stakeholders: cinco papeles, no una lista de nombres

Un contacto no es un decisor. Buscamos entender quién decide, quién sufre el problema, quién puede bloquear la compra y quién ganaría internamente si el proyecto avanza.

Ver diagrama Mermaid

mindmap
  root((Mapa de
stakeholders))
    Comprador económico
      Firma el presupuesto
      Mide en dinero y riesgo
    Usuario
      Vive el problema a diario
      Fuente del dolor real
    Evaluador técnico
      Valida factibilidad
      Puede vetar por arquitectura
    Campeón interno
      Gana si el proyecto avanza
      Traduce hacia adentro
    Bloqueador
      Defiende el statu quo
      A veces es el proveedor actual

El objetivo mínimo es dos tomadores de decisión nombrados, cada uno con correo y teléfono, marcando explícitamente cuáles están verificados y cuáles son inferidos. Un correo derivado por patrón —adivinar [email protected]— es una hipótesis, y se etiqueta como tal. Nunca se envía nada a una hipótesis.

Aquí conviene una confesión metodológica. En agosto detectamos que once de nuestras propias fichas decían "cero personas identificadas". Era falso. La búsqueda se había hecho filtrando solo por registros de tipo empresa, sin bajar a los contactos hijo. Había 36 personas ahí, incluidos tres directores generales. Once puntajes subieron al corregirlo, y uno cambió de categoría completa. El error era nuestro, en nuestra propia consulta, y estuvo dos semanas invisible porque el resultado —"no hay nadie"— confirmaba lo que ya suponíamos.

Es exactamente el fallo que la rúbrica está diseñada para atrapar, y nos lo hizo a nosotros.

7. La compuerta de calidad: cuándo NO se produce nada

Esta es la parte que distingue el método de un generador de documentos. La compuerta se evalúa antes de redactar cualquier material comercial.

Ver diagrama Mermaid

flowchart TD
    C0["Ficha de inteligencia
terminada"] --> C1{"¿2+ decisores nombrados
con correo Y teléfono?"}
    C1 -->|"No"| N1["Entregable = informe
de lo que falta"]
    C1 -->|"Sí"| C2{"¿Señal de prioridad
tecnológica concreta
y verificable?"}
    C2 -->|"No"| C2b{"¿Hay razón explícita
para proceder igual?"}
    C2b -->|"No"| N1
    C2b -->|"Sí"| C3
    C2 -->|"Sí"| C3{"¿Bandera roja
sin resolver?"}
    C3 -->|"Sí"| N2["Bloqueo + etiqueta
permanente"]
    C3 -->|"No"| Y1["Compuerta abierta"]

    N1 --> R["Recomendación de
siguiente paso"]
    N2 --> R

    style N1 fill:#78350f,color:#fff
    style N2 fill:#7c2d12,color:#fff
    style Y1 fill:#166534,color:#fff

La instrucción textual en nuestro protocolo dice: "no fuerces la generación de documentos comerciales solo por completar el ejercicio". Suena obvio. En la práctica es lo primero que se rompe cuando hay presión de números.

8. Medir la intención: el catálogo de eventos

Llegamos al núcleo del asunto. ¿Qué es una intención de compra?

La respuesta convencional de la industria es alguna combinación de aperturas de correo, clics, visitas a la web y menciones en redes. Nosotros rechazamos las cuatro. Un correo abierto puede ser un cliente de correo pre-cargando imágenes. Un clic puede ser un filtro de seguridad corporativo. Una mención de "ERP" en LinkedIn puede ser un competidor.

Nuestra taxonomía distingue diez tipos de señal, y solo algunas cuentan como intención:

Ver diagrama Mermaid

mindmap
  root((Taxonomía
de señales))
    Cuentan como intención
      Necesidad explícita
      Señal de dolor
      Señal de proyecto
      Frustración con proveedor
      Presupuesto o plazo
    Cuentan como contexto
      Oportunidad de referencia
      Oportunidad de autoridad
      Señal de alianza
    No cuentan
      Ruido
      Bloqueado por privacidad

Y este es el catálogo de eventos con su peso. Está literalmente así en el código que calcula los puntajes:

Ver diagrama Mermaid

flowchart LR
    subgraph P1["PESO ALTO · compromiso demostrado"]
        A1["Factura pagada · 20"]
        A2["Reunión realizada · 12"]
        A3["Cotización enviada · 10"]
        A4["Demo presentada · 10"]
    end
    subgraph P2["PESO MEDIO · el prospecto pidió algo"]
        B1["Pidió reunión · 9"]
        B2["Pidió cotización · 9"]
        B3["Pregunta de due diligence · 8"]
        B4["Dolor declarado · 8"]
        B5["Plática técnica · 8"]
    end
    subgraph P3["PESO BAJO · hay conversación"]
        C1["Respondió correo · 6"]
        C2["Hilo de correo · 6"]
        C3["Interés declarado · 5"]
        C4["Canal directo abierto · 5"]
        C5["Contacto telefónico propio · 4"]
        C6["Evento confirmado · 3"]
    end
    subgraph P0["PESO CERO · no es intención"]
        D1["Toque entregado · 0"]
        D2["Toque recibido · 0"]
        D3["Coincidencia de tema · 0"]
        D4["Apertura sin respuesta · 0"]
    end

    style P1 fill:#166534,color:#fff
    style P2 fill:#1e3a5f,color:#fff
    style P3 fill:#78350f,color:#fff
    style P0 fill:#7c2d12,color:#fff

Nótese qué está en la caja de peso cero: haber entregado un correo, haberlo recibido, la coincidencia temática y la apertura sin respuesta. Son las cuatro métricas sobre las que descansa la mayor parte del software de generación de demanda. Para nosotros valen cero, y esa decisión nos costó tener que reconstruir el tablero completo.

La regla de las cinco intenciones

Sobre ese catálogo se monta la definición operativa que fijamos el 17 de julio de 2026 y que hoy es un campo entero en nuestro CRM:

Un contacto no es un lead por responder. Un candidato se convierte en lead calificado solo cuando acumula cinco o más intenciones de compra observables — reuniones, cotizaciones enviadas, pláticas técnicas, demostraciones. Una respuesta, por sí sola, vale cero.

Y viene con una segunda mitad que se cita mucho menos y que económicamente importa igual:

Al llegar a cinco intenciones, se deja de prospectar a ese candidato.

La regla corta el desperdicio por los dos extremos. Impide perseguir a quien nunca dio señal, e impide seguir gastando esfuerzo de prospección en quien ya dio suficiente. Ambos errores cuestan lo mismo.

Ver diagrama Mermaid

stateDiagram-v2
    [*] --> Sospechoso: Entra al universo
    Sospechoso --> Candidato: Decisor identificado
con canal válido
    Sospechoso --> Excluir: Compuerta dura
    Candidato --> Oportunidad: 1ª intención
observable con cita
    Candidato --> Enfriamiento: 0 intenciones
tras la cadencia
    Oportunidad --> Oportunidad: 2ª, 3ª, 4ª intención
    Oportunidad --> Lead: 5ª intención
    Oportunidad --> Enfriamiento: Se apaga la señal
    Enfriamiento --> Candidato: Reingreso a los 30 días
    Lead --> [*]: Deja de prospectarse

    note right of Lead
        Aquí se detiene
        este artículo
    end note

9. La rúbrica completa: 100 puntos, 5 ejes

La intención verificada es uno de cinco ejes. Así se reparten los cien puntos:

Ver diagrama Mermaid

flowchart TD
    T["Puntaje total · 100"] --> E1["AJUSTE AL ICP · 30"]
    T --> E2["DOLOR VERIFICABLE · 20"]
    T --> E3["DECISOR · 25"]
    T --> E4["INTENCIÓN VERIFICADA · 20"]
    T --> E5["COSTO DE ACCESO · 5"]

    E1 --> E1a["Sector · 12"]
    E1 --> E1b["Geografía · 6"]
    E1 --> E1c["Tamaño · 6"]
    E1 --> E1d["Complejidad · 6"]

    E2 --> E2a["Versión legacy
confirmada · 12"]
    E2 --> E2b["Stack frágil · 5"]
    E2 --> E2c["Presión regulatoria · 3"]
    E2 --> E2d["Dolor inferido · 0"]

    E4 --> E4a["Solo eventos observables
con cita y fuente"]

    style E2d fill:#7c2d12,color:#fff
    style E4a fill:#166534,color:#fff

Existe una versión ligera de tres ejes —stakeholders, señal técnica y ajuste de escala, de 0 a 3 cada uno— que usamos para curar segmentos completos por lotes. El tier final es Alta con 7 de 9 o más, Media entre 4 y 6, Baja con 3 o menos. Con una regla que sobrescribe al puntaje: si la empresa no es el tipo de entidad que buscamos, la bandera roja anula la priorización sin importar cuántos puntos haya sumado, y obliga a quitar la etiqueta, no solo a anotar el problema en un comentario.

Esa distinción entre "anotarlo" y "quitar la etiqueta" nos costó tres incidentes. Un veredicto escrito en prosa dentro de un campo de texto no impide que el registro reaparezca en el siguiente segmento. Solo la etiqueta lo impide. Documentamos tres reapariciones de la misma empresa bloqueada antes de corregir el proceso.

Lo que pasa cuando cambias la rúbrica

Vale la pena mostrar el efecto real. Al pasar de la rúbrica de julio a la de agosto —la que exige evidencia citable—, una cuenta que teníamos en 88 sobre 100 cayó a 36. No cambió la empresa. Cambió lo que aceptábamos como prueba.

En el mismo corte, 351 registros evaluados produjeron 38 exclusiones duras. Treinta y ocho registros que hasta ese día se contaban como pipeline.

Ver diagrama Mermaid

quadrantChart
    title Esfuerzo invertido contra señal obtenida
    x-axis "Poco esfuerzo" --> "Mucho esfuerzo"
    y-axis "Sin señal" --> "Con señal citable"
    quadrant-1 "Trabajar a fondo"
    quadrant-2 "Ganancia rápida"
    quadrant-3 "Dejar en reposo"
    quadrant-4 "Detener: pozo sin fondo"
    "Cuenta con 5 intenciones": [0.72, 0.93]
    "Cuenta con 3 intenciones": [0.55, 0.68]
    "Candidato con decisor": [0.30, 0.42]
    "Multi-toque sin respuesta": [0.75, 0.08]
    "Dominio OSINT sin persona": [0.16, 0.05]

10. Las compuertas duras: a quién no le escribimos, nunca

Independientemente del puntaje, hay categorías que salen del universo por decisión, no por cálculo.

Ver diagrama Mermaid

flowchart TD
    R["Registro evaluado"] --> G1{"¿Es partner o
consultor de Odoo?"}
    G1 -->|"Sí"| X1["EXCLUIR
Competencia directa"]
    G1 -->|"No"| G2{"¿Sector público,
paraestatal o educativo?"}
    G2 -->|"Sí"| X2["EXCLUIR
Compuerta permanente"]
    G2 -->|"No"| G3{"¿Riesgo legal
o reputacional?"}
    G3 -->|"Sí"| X3["EXCLUIR
Decisión firmada,
no por omisión"]
    G3 -->|"No"| G4{"¿Versión vigente
sin dolor probado?"}
    G4 -->|"Sí"| X4["EXCLUIR
Nada que ofrecer"]
    G4 -->|"No"| G5{"¿Solicitó no
ser contactado?"}
    G5 -->|"Sí"| X5["LISTA DE BLOQUEO
Permanente"]
    G5 -->|"No"| P["Continúa al scoring"]

    style X1 fill:#7c2d12,color:#fff
    style X2 fill:#7c2d12,color:#fff
    style X3 fill:#7c2d12,color:#fff
    style X4 fill:#78350f,color:#fff
    style X5 fill:#450a0a,color:#fff
    style P fill:#166534,color:#fff

Dos notas sobre esto. La primera: la exclusión por riesgo legal o reputacional se documenta como decisión firmada, no como olvido. Si una cuenta sale del universo por eso, queda escrito quién lo decidió y por qué. La segunda: mantener dos listas de bloqueo que no se hablan entre sí es una forma silenciosa de violar la voluntad de alguien que ya pidió no ser contactado. Nos pasó, lo detectamos, y consolidamos las listas en el registro nativo de Odoo.

11. Los tres defectos que hacen que un segmento no llegue a nadie

Antes de que un segmento se considere listo, se revisan tres fallas específicas. Las tres son de datos, no de redacción, y las tres son silenciosas.

Ver diagrama Mermaid

flowchart TD
    S["Segmento con
dominio amplio"] --> D1{"Defecto 1
¿El registro padre
tiene correo?"}
    D1 -->|"No"| F1["El correo vive en el
contacto hijo.
El segmento sale vacío."]
    D1 -->|"Sí"| D2{"Defecto 2
¿El nombre es el
nombre de la empresa?"}
    D2 -->|"No"| F2["Título scrapeado del sitio.
El saludo dinámico
sale como 'Login | My Website'."]
    D2 -->|"Sí"| D3{"Defecto 3
¿Cuerpo editable y
cuerpo enviado
son idénticos?"}
    D3 -->|"No"| F3["El editor se ve bien
y sale texto viejo.
El que muerde en silencio."]
    D3 -->|"Sí"| OK["Segmento admisible"]

    style F1 fill:#7c2d12,color:#fff
    style F2 fill:#7c2d12,color:#fff
    style F3 fill:#450a0a,color:#fff
    style OK fill:#166534,color:#fff

El primero es más común de lo que uno esperaría. En nuestra propia base, el 64% de los registros de empresa no tenía correo en el registro padre — los correos vivían en los contactos hijo. Un segmento construido sobre el modelo de empresas, sin bajar a las personas, habría salido a una fracción mínima de su audiencia real y el reporte habría dicho "enviado con éxito".

Y una regla de higiene sobre qué correo es admisible. Solo tres orígenes pasan: un decisor nombrado con verificación directa, un correo de decisor publicado literalmente por la propia empresa, o un genérico corporativo publicado por la empresa. No pasa ningún correo derivado por patrón sin verificar.

12. Dónde queda todo: el aterrizaje en Odoo

Aquí termina el ejercicio de inteligencia. Todo lo anterior existe para producir un registro en nuestro Odoo que un ser humano pueda auditar sin pedirle explicaciones a nadie.

No usamos una hoja de cálculo paralela, ni una plataforma externa, ni un campo de notas libres. Creamos 18 campos propios en el modelo de contactos, con su propia vista, agrupados en cuatro bloques.

Ver diagrama Mermaid

erDiagram
    RES_PARTNER ||--o{ CONTACTO_HIJO : "tiene decisores"
    RES_PARTNER ||--o{ ETIQUETA : "clasificado por"
    RES_PARTNER ||--o{ MENSAJE_CHATTER : "bitácora de"
    RES_PARTNER ||--o| OPORTUNIDAD_CRM : "genera"
    LISTA_BLOQUEO ||--o{ RES_PARTNER : "suprime"

    RES_PARTNER {
        int x_tg_scoring_total "0-100"
        int x_tg_eje_stakeholders "0-3"
        int x_tg_eje_senal_tecnica "0-3"
        int x_tg_eje_ajuste "0-3"
        bool x_tg_bandera_roja "anula tier"
        int x_tg_intenciones_n "regla de 5"
        text x_tg_intenciones_detalle "bitacora con fuente"
        char x_tg_decisor_nombre "persona"
        char x_tg_decisor_cargo "papel"
        char x_tg_decisor_canal "via valida"
        text x_tg_dolor_verificable "cita textual"
        char x_tg_version_odoo "señal tecnica"
        text x_tg_siguiente_accion "compromiso"
        char x_tg_fuente_dato "trazabilidad"
        date x_tg_fecha_scoring "caducidad"
        selection x_tg_tier "alta media baja"
        selection x_tg_clasificacion "lead a excluir"
        selection x_tg_icp "perfil objetivo"
    }
    CONTACTO_HIJO {
        char nombre
        char cargo
        char correo_verificado
        char grado_confirmacion
    }
    ETIQUETA {
        char tier_y_scoring
        char banderas_rojas
        char compuertas_permanentes
        char origen_del_dato
    }

Los cuatro campos que hacen el trabajo pesado:

• x_tg_fuente_dato — de dónde salió este registro. Sin esto, en dos meses nadie recuerda si una empresa llegó por censo oficial, por rastreo técnico o porque alguien la escribió a mano.
• x_tg_intenciones_n y x_tg_intenciones_detalle — el contador de la regla de cinco, y la bitácora que lo sustenta. Cada intención registrada trae su cita y su fecha. Si no se puede citar, no se anota.
• x_tg_fecha_scoring — la fecha en que se puntuó. Un puntaje sin fecha es una opinión. Con fecha, es un dato que caduca.
• x_tg_bandera_roja — el interruptor que anula la priorización sin importar el puntaje.

Encima de eso, un sistema de etiquetas que materializa las decisiones —tiers de scoring, compuertas permanentes por sector, banderas de correo inviable, origen del lote— y una bitácora en el chatter de cada registro con el informe de inteligencia completo. Esa bitácora es el punto importante: la conclusión y su evidencia viven pegadas al registro, no en un documento suelto que alguien tiene que ir a buscar.

Ver diagrama Mermaid

timeline
    title Evolución del método, de la apertura de correo a la evidencia citable
    section Mayo 2026
        Primer perfil ICP y scoring de 0 a 100 : Se rechazan los pixeles de rastreo desde el diseño
        Taxonomía inicial de señales : Regla de separar lo observado de lo inferido
    section Junio 2026
        Capa de OSINT técnico con lista blanca : Diagnóstico del embudo real
        Se descubre el primer embudo vacío : Muchos toques, cero señales registradas
    section Julio 2026
        Se fija la regla de las 5 intenciones : Una respuesta, por sí sola, vale cero
        Auditoría de la base heredada : 60 por ciento del OSINT crudo era competencia
    section Agosto 2026
        Rúbrica de 100 puntos con dolor inferido en cero : Reclasificación completa del universo
        Migración a campos nativos de Odoo : La evidencia vive junto al registro

13. Las herramientas, con nombre y apellido

Ya que estamos enseñando el método, enseñamos también el taller. Todo esto opera a través de conectores estandarizados que los agentes de IA consumen bajo permisos explícitos.

Ver diagrama Mermaid

flowchart LR
    subgraph AG["AGENTES · con permisos por herramienta"]
        AG1["Protocolo de
inteligencia comercial"]
        AG2["Protocolo de
curaduría de segmentos"]
        AG3["Revisión de pipeline
e inteligencia competitiva"]
    end

    subgraph CN["CONECTORES"]
        C1["DENUE · INEGI"]
        C2["Reconocimiento
técnico propio"]
        C3["Verificación
de correo"]
        C4["Enriquecimiento
de personas"]
        C5["Navegador
controlado"]
        C6["Búsqueda y
lectura web"]
    end

    subgraph MEM["MEMORIA Y CONTROL"]
        M1["Memoria vectorial"]
        M2["Trazas y
observabilidad"]
        M3["Bitácoras de
auditoría fechadas"]
    end

    subgraph SR["SISTEMA DE REGISTRO"]
        S1["Odoo"]
    end

    AG --> CN --> SR
    AG <--> MEM
    MEM --> S1

    style SR fill:#166534,color:#fff
    style MEM fill:#1e3a5f,color:#fff

Dos decisiones de gobierno que vale la pena explicitar, porque son las que más nos preguntan:

Ninguna herramienta escribe sola en producción. Los agentes producen borradores. La escritura en Odoo pasa por revisión, y toda escritura se verifica releyendo el registro. No hay excepción por urgencia.

Dimos de baja una plataforma comercial completa. Operamos durante meses una herramienta de generación de leads con IA. Al auditar su noción de "lead caliente" descubrimos que era coincidencia temática de publicaciones en redes, con fuerza declarada arbitrariamente, e incluía a nuestros propios competidores. La dimos de baja. No falló técnicamente: hacía exactamente lo que prometía. El problema era lo que prometía.

14. Lo que hay hoy en nuestros registros

Para cerrar el círculo con transparencia real, esto es lo que existe hoy en nuestro Odoo como producto de todo lo anterior:

• Un universo de varios cientos de empresas evaluadas, cada una con puntaje, fecha de puntaje y origen del dato.
• Un conjunto de etiquetas que materializan las decisiones: tiers de prioridad, compuertas permanentes por sector, banderas de correo inviable, origen del lote de carga.
• Una lista de bloqueo consolidada, nativa del sistema, que sobrevive a cualquier cambio de herramienta de envío.
• Una bitácora por registro con el informe completo de inteligencia comercial: lo que encontramos, dónde lo encontramos y qué concluimos.
• Un contador de intenciones por cuenta, con su bitácora citada, y una clasificación que va de excluir a lead según reglas escritas, no según criterio del día.

Y una proporción que dice más que cualquier otra cifra: de todo el universo evaluado, la enorme mayoría está clasificada como sospechoso o candidato. Es decir: reconocemos explícitamente que la mayoría de nuestros registros todavía no ha demostrado interés en nada. Llamarlos "leads" sería mentirnos.

Ver diagrama Mermaid

flowchart LR
    subgraph ORI["Origen"]
        O1["Aparece en censo
o web pública"]
        O2["Sobrevive al filtro
de giro y tamaño"]
    end
    subgraph INV["Investigación"]
        I1["Se le buscan personas
y señales técnicas"]
        I2["Se verifica lo verificable,
se marca lo inferido"]
    end
    subgraph JUI["Juicio"]
        J1["Pasa por rúbrica
y compuertas"]
        J2["Se registra el motivo,
incluso si se excluye"]
    end
    subgraph REG["Registro"]
        R1["Queda en Odoo con
puntaje, fuente y fecha"]
        R2["Auditable por cualquier
humano del equipo"]
    end
    ORI --> INV --> JUI --> REG
    style ORI fill:#0f172a,color:#fff
    style REG fill:#166534,color:#fff

Si usted está en esos registros

Este artículo termina aquí a propósito. No vamos a describir qué hacemos después con un registro calificado — eso es asunto de la conversación que tengamos con usted, si es que la tenemos.

Lo que sí queremos dejar claro es lo siguiente. Si recibió un correo nuestro, no fue porque compramos una base de datos. Fue porque su empresa aparece en un censo económico oficial, o porque su infraestructura pública emite una señal técnica que sabemos leer, o porque alguien de su equipo publicó algo relevante en un perfil profesional abierto. Todo de fuentes de acceso público. Nada de brechas, nada de datos filtrados, nada de correos personales.

Y si prefiere que no lo tengamos: escríbanos y sale de nuestros registros el mismo día, permanentemente, en el sistema y no en una nota. Si prefiere ver qué tenemos sobre su empresa, pídalo y se lo enviamos completo. Es su información.

Nos parece que una empresa que le va a proponer gobernar sus datos debería empezar por enseñar cómo gobierna los propios.

Transgenia implementa y opera Odoo con agentes de IA gobernados. Escríbanos a [email protected] · Aviso de privacidad