Documentación de marketing ops: qué registrar y dónde entra el registro de cambios

¿Qué es la documentación de operaciones de marketing?

La documentación de operaciones de marketing es todo lo que alguien nuevo en el equipo necesitaría para llevar el marketing sin preguntarte: cómo están conectadas las herramientas, cómo se hace el trabajo recurrente, qué reglas aplican y qué cambió y cuándo. Menos manuales eternos y más páginas cortas, fáciles de encontrar y al día.

Casi todos los equipos ya tienen partes de esto repartidas entre una wiki, una carpeta compartida, la configuración de las plataformas y la memoria de la gente. El problema aparece en tres momentos: cuando alguien se incorpora, cuando una cuenta cambia de manos y cuando un cliente o tu jefe pregunta por qué cambiaron los resultados. Forrester lo dice sin rodeos sobre el primero: lo último que debería hacer una persona recién incorporada es ir haciendo clic por la plataforma de automatización para entender cómo funciona.

Piensa en cuatro capas: referencia (qué existe), procedimiento (cómo se hace el trabajo recurrente), reglas (qué cumple todo el mundo) e historial (qué cambió). La mayoría de los equipos escribe las tres primeras y olvida la cuarta, que es justo la que necesitas cuando una métrica cae.

¿Qué debe documentar un equipo de marketing ops?

Documenta lo que cuesta reconstruir de memoria y lo que rompe resultados cuando dos personas lo hacen de forma distinta. La tabla siguiente es un punto de partida práctico; cada fila necesita un responsable con nombre y un motivo claro para actualizarla.

La lista de Forrester va en la misma línea: menciona los programas de scoring, nurturing y asignación de leads, los procesos de reporting y los roles como lo que conviene tener por escrito fuera de las plataformas. Las convenciones de nombres merecen página propia, porque un cambio de nombre silencioso parte un informe en dos; mira nuestro artículo sobre convenciones de nombres UTM para una plantilla.

¿Cómo escribir un runbook de marketing que el equipo use de verdad?

Escribe un runbook por tarea recurrente, en el orden en que alguien la haría, con las comprobaciones que demuestran que ha salido bien. Si un paso depende del criterio de alguien, di quién decide. Si puedes, que quepa en una pantalla.

1. Nombra la tarea y el responsable
2. Enumera los pasos en orden
3. Añade la comprobación de cada paso
4. Indica qué registrar al terminar

Un buen runbook para subir un presupuesto, por ejemplo, dice dónde cambiar el importe, la subida máxima que ha acordado el equipo, qué revisar a la mañana siguiente y que el cambio se anota en el registro con el motivo. Ese último paso es el que convierte un procedimiento en historial que puedes leer después.

El manual de incidentes de Atlassian describe playbooks que agrupan runbooks, checklists y plantillas para que el equipo responda siempre igual. La idea funciona igual en marketing: una carpeta por proceso, páginas cortas y un enlace a donde queda registrado el resultado. Los runbooks también aceleran un cambio de agencia; nuestro checklist de traspaso de agencia recoge qué entregar.

¿Dónde encaja el registro de cambios en la documentación?

El registro de cambios es la capa de historial: recoge lo que pasó de verdad, mientras que los runbooks y las reglas describen lo que debería pasar. Sin él, la documentación enseña a lanzar una campaña, pero no explica por qué cayeron las conversiones en marzo.

Cada plataforma guarda una parte de ese historial. El Historial de cambios de Google Ads muestra los cambios de los últimos 2 años, con el correo de quien editó desde la interfaz y entradas como "Google Ads system" para los automáticos. Google Tag Manager guarda un historial de publicaciones con quién publicó cada versión y permite poner nombre y descripción a la versión. GA4 deja que quien tenga el rol de Analista o superior cree anotaciones (título de 60 caracteres, descripción de 150, hasta 1000 por propiedad). Ninguna ve a las demás, ni los cambios en la landing, el CRM o los precios.

Por eso el registro se sitúa por encima de todas: una entrada por cambio, con fecha, plataforma, responsable, motivo y efecto esperado. Nuestra guía del registro de cambios de marketing explica el formato y la plantilla de registro de cambios te da las columnas para empezar.

Ejemplo: el miércoles, un cliente pregunta por qué bajaron los leads el martes. Los runbooks muestran que los lanzamientos siguieron el checklist, así que el equipo abre el registro. Ahí aparecen una bajada del CPA objetivo en Google Ads el viernes, un formulario nuevo en la landing el sábado y una versión de GTM publicada el lunes. El formulario había perdido la redirección a la página de gracias y el evento de lead dejó de dispararse. En el CRM los leads seguían igual; solo cayó el recuento medido.

¿Cómo aislar qué cambio causó la caída con tu documentación?

Usa la documentación en un orden fijo: confirma la medición con el plan de medición, lista todos los cambios de los días previos a la caída y prueba una hipótesis cada vez. El mapa de herramientas te dice dónde mirar; el registro te dice qué cambió.

1. Descarta primero la medición. Compara la cifra de la plataforma con la fuente de verdad que fija tu plan de medición (CRM, pedidos, formularios enviados). Si solo cayó un lado, es un problema de medición.
2. Saca todos los cambios del periodo. Toma del registro los 7 a 14 días previos al cambio y completa los huecos con el Historial de cambios de Google Ads y la lista de versiones de GTM.
3. Compara con los runbooks. Un cambio hecho fuera del procedimiento (sin revisión al día siguiente, sin motivo anotado) es el primer sospechoso.
4. Prueba una hipótesis cada vez. Revierte o segmenta por el cambio más sospechoso y vigila la métrica, en lugar de deshacerlo todo a la vez.

Con todos los cambios en una sola línea temporal, el ejemplo anterior se resuelve en minutos: la versión de GTM aparece un día antes de la caída, justo después del cambio de formulario, y ahí es donde miras primero. Changeline mantiene esa línea temporal por proyecto de cliente: los cambios de Google Ads se pueden importar automáticamente mediante una conexión de solo lectura, y el equipo registra el resto (web, medición, CRM, precios) con responsable y motivo. Para el método completo, consulta la guía sobre cómo explicar una caída de conversiones a un cliente.

¿Cómo mantener al día la documentación de marketing ops?

Vincula cada documento al hecho que lo deja obsoleto y haz que actualizarlo forme parte de terminar la tarea. La documentación se queda vieja cuando vive aparte del trabajo; se mantiene al día cuando el último paso de cada tarea es actualizarla.

Tres hábitos resuelven casi todo. Primero, un responsable con nombre para cada página, para que "alguien debería actualizar esto" tenga respuesta. Segundo, una revisión breve con ritmo fijo: mensual para el registro y el plan de medición, trimestral para runbooks y roles. Tercero, la regla de que ningún cambio sale sin su entrada: quien cambia el presupuesto, la etiqueta o el formulario escribe una línea con el motivo.

Si ya tienes un proceso de revisión, nuestro artículo sobre gestión de cambios en marketing explica cómo añadir aprobaciones sin frenar lanzamientos, y el de post mortem de campañas muestra cómo convertir una mala semana en mejores runbooks.