GitHub在日本和韩国的营销团队将重复性的活动运营转变为GitHub内部的可执行工作流，不再需要在报名页面、链接、邮件活动和客户数据库之间手动管理每一个步骤。据Tomoko Tanaka介绍，流程从一个GitHub Issue开始，随后由GitHub Actions负责设置活动、审查报名者名单，并执行活动结束后的后续工作。
本文并非新产品发布，而是介绍Tanaka利用现有GitHub工具发展出的一种运营实践，同时借助GitHub Copilot将内部操作指南转化为自动化流程。这一实践的重要性在于，它将营销管理与软件团队熟悉的概念联系起来，例如审查、变更记录、触发器和可重复的工作流。
问题：细小步骤与连锁错误
团队的活动包括面向企业开发者的定期研讨会、东京的社区聚会，以及在首尔为高管举办的闭门会议。任何活动获批后，都会开始一系列重复工作：复制落地页，为每个渠道创建带有UTM标签的链接，准备邀请邮件，提交发送请求，将活动添加到两个项目看板，然后下载报名者名单并每天清理，直至活动日期。
活动结束后，还必须导出出席者名单，将其重新整理为适合上传到客户关系管理系统的格式，为记录添加适当标签，并准备报告。单独来看，每个步骤都不困难，但链接、活动名称或每日更新中的错误，都可能影响报告和后续运营。
构建工作流的三个组成部分
这一实践依赖于GitHub中的三个基本功能：
- Issue Forms：它们充当结构化的请求表单，而不是空白文本框，并收集活动标题、日期、地区、活动名称和目标受众等字段。研讨会和线下活动使用不同的表单，但都会进入同一套运行机制。
- Labels：它们不仅用于描述，还作为运行密钥。例如，添加event-setup这样的标签后，与之关联的工作流就会启动。
- GitHub Actions：它们执行任务，读取请求正文中的字段，然后连接外部工具，以设置活动、跟进报名者或完成后续工作。
通过这种设计，Issue成为汇集计划、讨论和状态的工作单元，并为决策提供可见的历史记录，为每次变更提供链接。对工作流的修改也可以作为代码变更处理，在合并前通过拉取请求进行审查。
GitHub Copilot在将操作转化为自动化中的作用
Tanaka并没有直接开始编写代码，而是先编写团队的操作指南并提供给GitHub Copilot，然后通过对话逐步开发自动化流程。她表示，自己过去在Linux服务器上运行数据库的经验帮助她将这些流程视为可编程的管道，尽管她也承认自己的编程技能已不如从前。
规划从描述想法的对话开始，例如在11月组织一场关于人工智能辅助开发的研讨会。随后，Copilot会读取仓库根目录中的AGENTS.md文件。这是一份Markdown格式的指南，规定了活动名称的命名规则、财务季度与日期的对应关系、时区以及邀请邮件的标准。根据这些规则和过去类似的活动，Copilot会建议活动名称，准备两个版本的邀请邮件，并提出操作指南要求回答的问题。
实际发生了哪些变化？
这种方式可以减少重复的手工工作，同时不会取消规划阶段中的人工决策。对话为针对特定活动进行定制留出了空间，而自动化则负责在获得批准后执行固定步骤。根据本文，过去手动准备一场活动大约需要两天；现在，流程从一个Issue开始，随后执行设置、对报名者名单进行每日检查，以及活动结束后的清理工作。
关键因素并不只是GitHub Actions，而是其他工具是否具备可编程性。活动管理平台提供API，而客户关系管理系统依赖官方CLI，该CLI覆盖所需任务并通过浏览器登录，因此Tanaka不需要为其设置API密钥。本文总结的规则是，只要工具具有API或CLI，就能为程序化连接打开路径，无论该工具是活动平台、CRM系统、表单生成器还是分析服务。
这一实践也说明了为什么在多市场环境中构建定制工作流更受青睐。APAC团队并不是在单一市场中运营；同一场研讨会可能以日语在东京举办，也可能以韩语在首尔举办，同时受众群体、CRM字段和优质潜在客户的定义标准也各不相同。Tanaka提到，让现成平台适应这些差异，可能需要定制和咨询预算，并等待供应商的产品路线图；而内部构建则可以通过拉取请求和审查来修改工作流。
这并不是取消现成营销平台的方案，也不能证明自动化适合每个团队。本文案例的实际价值在于先记录工作流程，然后将需要人工灵活判断的决策与可以自动执行的重复步骤分开。此外，该模式的成功依赖于外部工具是否可连接，以及操作指南是否准确；如果规则不完整或发生变化后未及时更新，错误可能会转移到自动化工作流中，而不是消失。