El equipo de marketing de GitHub en Japón y Corea del Sur convirtió las operaciones recurrentes de los eventos en un flujo de trabajo ejecutable dentro de GitHub, en lugar de gestionar manualmente cada paso entre páginas de registro, enlaces, campañas de correo y bases de datos de clientes. Según Tomoko Tanaka, el proceso comienza con una única GitHub Issue; después, GitHub Actions se encarga de preparar el evento, revisar las listas de inscritos y ejecutar las tareas de seguimiento una vez finalizado.
El artículo no presenta en absoluto un producto nuevo, sino que muestra una práctica operativa desarrollada por Tanaka utilizando herramientas de GitHub ya existentes, con ayuda de GitHub Copilot para convertir las guías internas de procedimientos en automatización. La importancia de la experiencia radica en que conecta la gestión de marketing con conceptos familiares para los equipos de software, como la revisión, el registro de cambios, los activadores y los flujos de trabajo repetibles.
El problema: pequeños pasos y errores encadenados
Los eventos del equipo incluyen seminarios periódicos para desarrolladores empresariales, encuentros comunitarios en Tokio y sesiones privadas para directivos en Seúl. Después de aprobar cualquier evento, comienza una serie de tareas repetitivas: copiar la página de destino, crear enlaces con etiquetas UTM para cada canal, preparar el mensaje de invitación, registrar la solicitud de envío, añadir el evento a dos tableros de proyectos y descargar y limpiar diariamente la lista de inscritos hasta la fecha del evento.
Una vez finalizado el evento, hay que exportar la lista de asistentes, reformatearla para cargarla en el sistema de gestión de relaciones con clientes, aplicar las etiquetas adecuadas a los registros y preparar un informe. Ningún paso parece difícil por sí solo, pero un error en un enlace, en el nombre de una campaña o en una actualización diaria puede afectar a los informes y a las operaciones posteriores.
Tres componentes para construir el flujo de trabajo
La experiencia se basó en tres funciones fundamentales de GitHub:
- Issue Forms: funcionan como formularios de solicitud estructurados en lugar de un cuadro de texto vacío, y recopilan campos como el título y la fecha del evento, la región, el nombre de la campaña y el público objetivo. Hay formularios diferentes para seminarios y eventos presenciales, pero todos alimentan el mismo mecanismo operativo.
- Labels: no se utilizan solo como etiquetas descriptivas, sino como claves de activación. Al añadir una etiqueta como event-setup, se inicia el flujo de trabajo asociado.
- GitHub Actions: ejecuta las tareas, lee los campos presentes en el texto de la solicitud y se conecta con herramientas externas para preparar el evento, hacer seguimiento de los inscritos o finalizar las tareas posteriores.
Con este diseño, la Issue se convierte en la unidad de trabajo que reúne el plan, la conversación y el estado, y proporciona un historial visible de las decisiones y un enlace para cada cambio. También es posible tratar la modificación del flujo de trabajo como un cambio de software que pasa por una solicitud de extracción y una revisión antes de fusionarse.
El papel de GitHub Copilot para convertir los procedimientos en automatización
Tanaka no empezó escribiendo código directamente, sino que redactó las guías operativas del equipo y se las proporcionó a GitHub Copilot; después desarrolló la automatización mediante el diálogo. Afirma que su experiencia previa operando bases de datos en servidores Linux la ayudó a ver estos procedimientos como un flujo programable, aunque reconoce que sus habilidades de programación ya no son las de antes.
La planificación comienza con una conversación que describe la idea, como organizar en noviembre un seminario sobre desarrollo asistido por inteligencia artificial. Después, Copilot lee el archivo AGENTS.md ubicado en la raíz del repositorio, una guía escrita en formato Markdown que define las reglas para nombrar campañas, relacionar los trimestres fiscales con las fechas, establecer las zonas horarias y aplicar los criterios del mensaje de invitación. Basándose en estas reglas y en un evento anterior similar, Copilot propone el nombre de la campaña, prepara dos versiones del mensaje de invitación y plantea las preguntas que exige la guía operativa.
¿Qué cambia en la práctica?
Este método permite reducir el trabajo manual repetitivo sin eliminar la decisión humana durante la fase de planificación. La conversación deja espacio para personalizar un evento concreto, mientras que la automatización ejecuta los pasos fijos una vez aprobados. Según el artículo, preparar un evento llevaba manualmente aproximadamente dos días, mientras que ahora el proceso comienza con una sola Issue y después ejecuta la configuración, la comprobación diaria de las listas de inscritos y la limpieza posterior al evento.
El elemento decisivo no es solo GitHub Actions, sino que las demás herramientas puedan programarse. La plataforma de gestión de eventos utiliza una API, mientras que el sistema de gestión de relaciones con clientes depende de una CLI oficial que cubre las tareas necesarias e inicia sesión mediante el navegador, por lo que Tanaka no necesitó configurar una clave de API. La regla que extrae el artículo es que disponer de una API o una CLI basta para abrir una vía de integración programática, ya se trate de una plataforma de eventos, un sistema CRM, un creador de formularios o un servicio de analítica.
La experiencia también explica por qué se prefiere construir un flujo personalizado en un entorno con múltiples mercados. El equipo de APAC no opera como un único mercado: el mismo seminario puede celebrarse en japonés en Tokio y en coreano en Seúl, con diferencias en los segmentos, los campos del CRM y los criterios para definir un cliente potencial cualificado. Tanaka señala que adaptar una plataforma lista para usar a estas diferencias puede requerir presupuestos de personalización y consultoría, además de esperar a la hoja de ruta del proveedor, mientras que la construcción interna permite modificar el flujo de trabajo mediante una solicitud de extracción y una revisión.
Esto no es una receta para eliminar las plataformas de marketing listas para usar, ni una prueba de que la automatización sea adecuada para todos los equipos. El valor práctico del caso presentado está en documentar primero el trabajo y, después, separar las decisiones que requieren flexibilidad humana de los pasos repetitivos que pueden ejecutarse automáticamente. Además, el éxito del modelo depende de que existan herramientas externas integrables y de la precisión de las guías operativas; si las reglas están incompletas o cambian sin actualizarse, los errores pueden trasladarse al flujo de trabajo automatizado en lugar de desaparecer.