Español

Arquitectura de MAP y CRM sin soluciones improvisadas: un playbook de reconstrucción para MOps

Abrió el gestor de campos y contó 247 campos personalizados. La mitad son propiedad de gente que se fue en 2023. La sincronización de lead a contacto lleva rota desde que el último admin la "arregló" allá por el segundo trimestre. Dos de los picklists tienen valores de texto libre que no deberían existir. La etapa del ciclo de vida la escriben tanto Marketo como Salesforce, así que el 14% de los registros oscilan entre MQL y Lead en cada ciclo de sincronización.

Bienvenido a MOps.

Si acaba de heredar este stack, o lleva dos años mirándolo prometiéndose que lo limpiaría "después de la próxima campaña", este es el playbook. Es el que ojalá alguien me hubiera entregado hace tres trabajos. El objetivo no es un diagrama bonito. El objetivo es una fuente de verdad por punto de dato, un dueño por campo y una integración que no le despierte a las 3 de la madrugada.

El flujo de datos de MAP a CRM: el contrato real

La mayoría de los equipos tratan la integración de MAP a CRM como una caja negra. No lo es. Es un contrato, y si nadie escribió el contrato, tiene una solución improvisada.

El contrato tiene cuatro partes. Equivóquese en estas y nada más importa.

Lead vs Contacto: qué se transfiere, qué muere

Cuando un Lead se convierte en un Contacto en Salesforce (o como lo llame su CRM), pierde datos a menos que lo haya mapeado explícitamente. Comportamiento predeterminado en la mayoría de los CRM:

  • Campos estándar de Lead con campos de Contacto coincidentes: se transfieren
  • Campos personalizados de Lead sin un campo de Contacto coincidente: desaparecen
  • Historial de actividad: normalmente se preserva, a veces queda huérfano
  • Campos de scoring del lado del MAP: depende enteramente de si su MAP escribe solo en Lead o en ambos objetos

El secreto sucio es que el 80% de los equipos de MOps escriben las puntuaciones demográficas y de comportamiento solo en el objeto Lead, y luego actúan sorprendidos cuando un SDR convierte un Lead y la puntuación desaparece. Si su MAP es Marketo o Pardot, debería estar escribiendo los campos de scoring tanto en Lead como en Contacto, O convirtiendo los Leads en Contactos al crearlos (el modelo de "todo Contactos, sin Leads" que HubSpot trae por defecto).

Elija uno. Documéntelo. Detenga el sangrado.

Etapa del ciclo de vida: el MAP escribe, el CRM lee. Nunca ambos.

Esta es la regla más importante de todo el playbook. Si ambos sistemas pueden escribir en la etapa del ciclo de vida, tendrá condiciones de carrera. Tendrá registros que oscilan. Tendrá a un SDR cerrando un acuerdo en un Contacto que el MAP acaba de degradar de vuelta a MQL por un webhook de baja que se disparó tres minutos después de la actualización a Closed-Won.

Elija un escritor. El MAP suele tener razón porque ve las señales de comportamiento primero. El CRM lee la etapa del ciclo de vida; no pelea por ella. Si ventas necesita anular (por ejemplo, marcar manualmente a alguien como SAL), construya un campo separado (sales_stage_override__c) y deje que una automatización en el MAP respete esa anulación. No deje que dos sistemas discutan sobre la misma columna.

Tiempo de sincronización: el tiempo real no siempre es mejor

El impulso predeterminado es "que sea en tiempo real". Esto está mal aproximadamente la mitad de las veces.

Las sincronizaciones en tiempo real tienen sentido para:

  • Llenados de formulario (el lead tiene que llegar al CRM antes de que se actualice la cola del SDR)
  • Transiciones de etapa del ciclo de vida que impulsan el enrutamiento
  • Estado de Closed-Won (la atribución de ingresos no puede esperar)

Las sincronizaciones por lotes (15 min, cada hora, nocturnas) tienen sentido para:

  • Recálculos masivos de puntuación
  • Cambios de membresía de listas
  • Rellenos de historial de actividad
  • Cualquier cosa que dispare más de 1.000 actualizaciones de registros por hora

¿Por qué importa esto? Porque "cada 10 minutos" es el peor ajuste posible para la sincronización de scoring. Es lo bastante lento como para que los SDR no puedan confiar en él, lo bastante rápido como para reventar sus límites de API durante un envío de campaña, y lo bastante frecuente como para hacer invisibles las condiciones de carrera hasta que su consulta de conciliación mensual las detecta.

Si solo recuerda una cosa: tiempo real para el traspaso, lotes para la higiene.

El traspaso de MQL: un campo, un dueño, una definición

Pare. Abra su Salesforce. Busque cualquier campo con "MQL" en el nombre. Le apuesto un café a que tiene al menos tres:

  • MQL_Date__c (establecido por Marketo)
  • Marketing_Qualified__c (establecido por una regla de workflow de 2022)
  • Lifecycle_Stage = "MQL" (establecido por HubSpot)

Elija uno. Borre los otros dos. El traspaso de MQL es un campo, un dueño (MOps), una definición (escrita en un documento de Confluence que tiene una fecha). Si ventas no confía en el campo, eso es un problema de definición, no un problema de campo. Añadir un cuarto campo nunca arregla un problema de definición.

El problema de la proliferación de campos

La proliferación de campos es como mueren los stacks de MAP+CRM. No con un único fallo dramático. Con una lenta acumulación de campos que nadie posee, usados por un informe que nadie abre, establecidos por un workflow que nadie documentó.

Cómo llegó a 247 campos personalizados

Cada campo tiene una historia de creación. Aproximadamente:

  • El 30% son reales, usados, con dueño. Estos están bien.
  • El 25% se crearon para una campaña en 2022, todavía se les escribe, y nada los lee.
  • El 20% los creó un líder de ventas que se fue, mapeados a un dashboard que se descontinuó, pero el campo sigue en cada diseño de página.
  • El 15% son duplicados con nombres ligeramente diferentes (Industry__c, industry_v2__c, Account_Industry__c).
  • El 10% son "campos fantasma" de integración creados automáticamente por una integración que se desconectó hace 18 meses, pero el campo se quedó.

Nadie borra campos porque las eliminaciones se sienten arriesgadas. Eso es exactamente por lo que necesita un proceso.

El marco de auditoría de campos de 90 días

Ejecútelo cada trimestre. Bloquee cuatro horas un viernes. Es el trabajo de limpieza de mayor apalancamiento en MOps.

Paso 1: saque un informe de uso. Para cada campo personalizado, cuente:

  • Cuántos registros tienen un valor no nulo (últimos 90 días de escrituras)
  • Cuántos informes referencian el campo
  • Cuántos workflows/automatizaciones referencian el campo
  • Cuántas integraciones le escriben

Si los cuatro son cero, el campo está muerto. Etiquételo.

Paso 2: encuentre al dueño. Cada campo necesita un nombre asociado. Saque el "Creado por" y compruebe si esa persona sigue en la empresa. Si no, recorra el campo a través del equipo. ¿Alguien lo reclama? Si nadie lo reclama en siete días, es huérfano.

Paso 3: construya la lista de eliminación. Tres grupos:

  • Borrado definitivo: cero uso Y sin dueño. Borre en el próximo sprint.
  • Deprecar: tiene algo de uso pero el dueño coincide en que es redundante. Márquelo como deprecado en la descripción, ocúltelo de los diseños, programe su eliminación en 90 días.
  • Documentar: activo, con dueño, sin más acción. Escriba la descripción si está en blanco.

Paso 4: que perdure. Añada una política de creación de campos: cada nuevo campo personalizado requiere una descripción, un dueño y una fecha de "revisar antes de". Sin descripción = sin campo. Consiga que el admin del CRM lo haga cumplir. Si no quiere, consígase a sí mismo derechos de admin para ese único workflow.

No llegará a 50 campos. Probablemente pueda llegar a 100. Ese es el objetivo.

Convenciones de nomenclatura que sobreviven a la rotación

Si el próximo admin que herede su stack no puede adivinar qué hace un campo en cinco segundos, el nombre está mal. Renómbrelo.

La convención de nomenclatura que uso, que ha sobrevivido a tres cambios de trabajo:

  • mkt_*: escrito por el MAP. Marketing es dueño.
  • sfdc_*: campo nativo de Salesforce o campo personalizado propiedad de ventas.
  • ext_*: escrito por una integración externa (Clearbit, ZoomInfo, 6sense, etc.). Solo lectura para todos los demás.
  • ops_*: campos operativos/calculados (región, segmento, nivel de cuenta).
  • Sin prefijo: campos estándar que usted no creó.

La disciplina de picklists importa más de lo que cree. Los campos de país en texto libre donde tiene "USA", "U.S.A.", "United States", "US" y "America" todos en el mismo conjunto de datos destruirán sus informes. Bloquee los picklists. Si ventas discute, muéstreles el informe de segmento donde los ingresos de USA están repartidos en cinco grupos.

La regla de los cinco segundos: si un nuevo admin abre el gestor de campos y no puede adivinar qué hace cust_dt_2_v3__c en cinco segundos, ese campo está mal nombrado. Renómbrelo. Sí, romperá dos informes. Arregle los informes. Su yo futuro le enviará una nota de agradecimiento.

Selección de MAP: Marketo vs HubSpot vs Pardot vs Rework

La mitad del dolor de la integración de MAP viene de elegir el MAP equivocado para la empresa. Así es como lo pienso.

Marketo (ahora Adobe)

Elija Marketo si:

  • Tiene un admin de MAP dedicado (no un "manager de marketing que también hace Marketo")
  • Sus programas de campaña son genuinamente complejos (nurtures multi-touch, jugadas basadas en cuentas, decenas de segmentos)
  • Es enterprise (más de 1.000 empleados) o ejecuta demand gen de estilo enterprise
  • Puede tolerar el precio y la curva de aprendizaje

No elija Marketo si es una startup de 50 personas. Usará el 8% de la plataforma, pagará el 100% del precio, y la integración con Salesforce se comerá un FTE.

HubSpot

Elija HubSpot si:

  • El marketing lidera el movimiento de GTM
  • Su equipo vive en la UI (no en llamadas a la API y SQL)
  • Es mid-market (50 a 500 empleados)
  • Quiere CRM y MAP del mismo proveedor y le parece bien el CRM de HubSpot (que es adecuado para SMB, se queda corto en enterprise)

La fortaleza de HubSpot es que el CRM y el MAP son un solo sistema, así que el problema de las soluciones improvisadas desaparece en parte. La debilidad es que si supera el CRM de HubSpot y le añade Salesforce, ha recreado el problema de la integración con pasos adicionales.

Pardot (Marketing Cloud Account Engagement)

Elija Pardot si:

  • Es una tienda nativa de Salesforce y el admin de Salesforce también es dueño de la marketing automation
  • No necesita lógica de programa sofisticada
  • Quiere la etapa del ciclo de vida y el scoring estrechamente acoplados a los objetos de SFDC

La fortaleza de Pardot es que la integración con SFDC es nativa (vive dentro de SFDC). La debilidad es que el MAP en sí está anticuado; si su equipo necesita una UX moderna, se le resistirá.

Rework

Elija Rework si:

  • Es un B2B pequeño o mediano (20 a 500 empleados)
  • Ventas y marketing comparten un pipeline y no quiere dos herramientas peleándose por él
  • No tiene un admin de MAP dedicado y no quiere uno
  • Prefiere tener un CRM con captura de leads, scoring y enrutamiento integrados que mantener una integración separada de MAP+CRM

La propuesta de Rework sobre este problema específico: no hay una integración de MAP a CRM que mantener porque no hay un MAP separado. La captura de leads, el scoring, la etapa del ciclo de vida y el pipeline viven en un solo sistema. Renuncia a algo de la complejidad de programa enterprise de Marketo. A cambio, renuncia a las soluciones improvisadas.

Para un equipo de B2B SaaS de 30 personas con un generalista de MOps, el stack de Marketo+SFDC cuesta quizá 80.000 $/año en licencias más medio FTE para mantenerlo. El mismo workflow en Rework cuesta 12 $/usuario/mes en el nivel de CRM (unos 10.000 $/año para un equipo de 30) y la integración del MAP pasa de "mantener" a "no existe".

Esa no es la respuesta correcta para todos. Es la respuesta correcta para más equipos de los que lo admiten.

La decisión de reconstruir desde cero

En algún momento, parchear cuesta más que reconstruir. La parte difícil es saber cuándo.

La regla del 40%: si más del 40% del tiempo de su equipo de MOps se dedica a arreglos de integración, campos fantasma y consultas de conciliación, y ha sido así durante dos trimestres consecutivos, ha pasado el punto del parche. Reconstruya.

Otras señales:

  • Existen tres o más campos de ciclo de vida "de confianza" y la gente discute sobre cuál es correcto
  • Los errores de sincronización superan el 0,5% de los registros por día
  • Una nueva contratación de MOps tarda más de 90 días en entregar su primer cambio no trivial
  • La traza de auditoría de los campos críticos es "pregúntale a Sandra, ella se acuerda"
  • La integración MAP-CRM tiene más de dos componentes de middleware personalizado (recetas de Workato, zaps de Zapier, Apex personalizado)

Las reconstrucciones no son una operación de "volarlo todo". Son una construcción en paralelo. Levanta una nueva instancia (o un esquema limpio en la instancia existente), migra una campaña a la vez, valida y luego depreca lo viejo. Lleva de 90 a 180 días. Es más rápido que los siguientes 18 meses de parches.

Dígale a su jefe que es una inversión, no un proyecto. Las inversiones se acumulan. Los parches no.

Monitoreo de salud de la integración

Una integración MAP-CRM sana tiene telemetría. Si no puede verla, no puede arreglarla.

Las tres alertas que todo líder de MOps debería tener en marcha:

1. Alerta de tasa de errores de sincronización. Se dispara si los errores de sincronización superan el 0,5% de los registros intentados en una ventana de 1 hora. Esto detecta problemas de límite de API, conflictos de reglas de validación y fallos de middleware antes de que ventas lo note.

2. Alerta de oscilación de ciclo de vida. Se dispara si la etapa del ciclo de vida de cualquier registro cambia más de tres veces en 24 horas. Esto detecta las condiciones de carrera donde dos sistemas pelean por el mismo campo.

3. Alerta de latencia de formulario a CRM. Se dispara si cualquier envío de formulario tarda más de 90 segundos en llegar al CRM. Los SDR confían en el sistema basándose en esta métrica más que en ninguna otra.

Una consulta de conciliación diaria también debería ejecutarse cada mañana a las 6 y enviarle un email (a usted y solo a usted, hasta que confíe en ella). La consulta que ejecuto en Salesforce + Marketo:

-- Registros en el MAP sin contraparte en el CRM, últimos 7 días
SELECT email, lifecycle_stage, last_modified
FROM map_leads
WHERE crm_id IS NULL
  AND created > DATEADD(day, -7, CURRENT_DATE)
  AND lifecycle_stage IN ('MQL', 'SAL');

Cualquier cosa en ese conjunto de resultados es un lead que debería haber llegado a un rep de ventas pero no lo hizo. Si la consulta devuelve más de 5 filas en un día, tiene un problema de integración del que aún no sabe.

La variante de dashboard: una vista semanal del conteo de errores de sincronización por tipo de error, la latencia de traspaso de MQL P50/P95 y el total de registros bajo cada etapa del ciclo de vida. Conviértala en la página de inicio de su espacio de Confluence de MOps. Cuando un VP pregunte "¿está sano el sistema?", señale el dashboard y diga "sí" o "no" con datos.

Una fuente de verdad, una definición de MQL, un dueño

Si este playbook tuviera una única conclusión, sería esta: cada punto de dato en su stack de MAP+CRM tiene exactamente una fuente de verdad, un dueño y una definición. Todo lo demás es una solución improvisada.

Cuando un rep de ventas argumenta que un MQL "no es realmente un MQL", eso no es un problema de campo. Es un problema de definición. Arregle la definición. Documéntela. Consiga que el liderazgo de ventas la apruebe por escrito. Entonces el campo se vuelve irrelevante, porque todos coinciden en lo que significa.

Cuando dos sistemas escriben en el mismo campo, elija uno. El otro se vuelve de solo lectura o recibe un campo de anulación separado. Las condiciones de carrera no mejoran con más workflows.

Cuando un campo personalizado no tiene dueño, elimínelo. Si alguien nota que falta en tres meses, descubrirá quién lo usaba realmente. La mayoría de las veces, nadie lo nota, y ha hecho el sistema más simple para el próximo admin que lo herede.

Las soluciones improvisadas se acumulan. Cada atajo que toma este trimestre es un problema que su sucesor hereda el año que viene. A veces la respuesta correcta es reconstruir. A veces es cambiar a un stack que no requiera la integración en primer lugar. Casi siempre, es borrar más de lo que añade.

Ese es el trabajo.

Más información