Маркетинговая команда GitHub в Японии и Южной Корее превратила повторяющиеся процессы проведения мероприятий в исполняемый рабочий процесс внутри GitHub вместо того, чтобы вручную управлять каждым этапом между страницами регистрации, ссылками, почтовыми кампаниями и базами данных клиентов. По словам Томоко Танаки, процесс начинается с одной GitHub Issue, после чего GitHub Actions подготавливает мероприятие, проверяет списки зарегистрированных участников и выполняет последующие действия после его завершения.
Материал не представляет новый продукт, а описывает операционную практику, разработанную Танакой с использованием уже существующих инструментов GitHub и GitHub Copilot для преобразования внутренних руководств по процедурам в автоматизацию. Значимость этого опыта заключается в том, что он связывает управление маркетингом с привычными для команд разработчиков концепциями, такими как ревью, журнал изменений, триггеры и повторяемый рабочий процесс.
Проблема: небольшие шаги и последовательные ошибки
Мероприятия команды включают регулярные вебинары для разработчиков корпоративных решений, встречи сообщества в Токио и закрытые сессии для руководителей в Сеуле. После утверждения любого мероприятия начинается серия повторяющихся задач: копирование лендинга, создание ссылок с UTM-метками для каждого канала, подготовка приглашения, регистрация запроса на отправку, добавление мероприятия на две доски проектов, а затем ежедневная загрузка и очистка списка зарегистрированных участников до даты мероприятия.
После завершения мероприятия необходимо экспортировать список участников, преобразовать его для загрузки в систему управления взаимоотношениями с клиентами, назначить соответствующие метки записям и подготовить отчёт. По отдельности ни один шаг не кажется сложным, однако ошибка в ссылке, названии кампании или ежедневном обновлении может повлиять на отчёты и последующие процессы.
Три строительных блока рабочего процесса
В основе эксперимента лежали три ключевые функции GitHub:
- Issue Forms: они работают как структурированные формы запросов вместо пустого текстового поля и собирают такие поля, как название мероприятия, его дата, регион, название кампании и целевая аудитория. Для вебинаров и очных мероприятий существуют разные формы, но они используют один и тот же механизм выполнения.
- Labels: они используются не только как описательные метки, но и как ключи запуска. При добавлении такой метки, как event-setup, запускается связанный с ней рабочий процесс.
- GitHub Actions: они выполняют задачи, считывают поля из текста запроса, а затем подключаются к внешним инструментам для подготовки мероприятия, отслеживания зарегистрированных участников или завершения последующих действий.
При такой конструкции Issue становится рабочей единицей, объединяющей план, обсуждение и состояние, а также предоставляет видимую историю решений и ссылку на каждое изменение. Изменение рабочего процесса также можно рассматривать как изменение программного кода, которое проходит через pull request и ревью перед слиянием.
Роль GitHub Copilot в преобразовании процедур в автоматизацию
Танака не начинала с непосредственного написания кода: она подготовила руководства по рабочим процедурам команды и предоставила их GitHub Copilot, а затем развивала автоматизацию через диалог. По её словам, прежний опыт эксплуатации баз данных на серверах Linux помог ей увидеть эти процедуры как программируемый конвейер, хотя она признаёт, что её навыки программирования уже не те, что раньше.
Планирование начинается с разговора, в котором описывается идея, например проведение в ноябре вебинара о разработке с поддержкой искусственного интеллекта. Затем Copilot читает файл AGENTS.md, расположенный в корне репозитория. Это руководство в формате Markdown, определяющее правила именования кампаний, соответствия финансовых кварталов датам, часовых поясов и стандарты текста приглашения. Основываясь на этих правилах и на предыдущем похожем мероприятии, Copilot предлагает название кампании, готовит два варианта текста приглашения и задаёт вопросы, предусмотренные руководством по рабочим процедурам.
Что меняется на практике?
Такой подход позволяет сократить повторяющуюся ручную работу, не устраняя участие человека в принятии решений на этапе планирования. Диалог оставляет пространство для настройки конкретного мероприятия, а автоматизация выполняет фиксированные шаги после его утверждения. Согласно материалу, ручная подготовка мероприятия занимала примерно два дня, тогда как теперь процесс начинается с одной Issue, после чего выполняются подготовка, ежедневная проверка списков зарегистрированных участников и очистка данных после завершения мероприятия.
Решающим фактором является не только GitHub Actions, но и программируемость других инструментов. Платформа управления мероприятиями использует API, а система управления взаимоотношениями с клиентами — официальный CLI, покрывающий необходимые задачи и выполняющий вход через браузер, поэтому Танаке не потребовалось настраивать для него API-ключ. Вывод материала заключается в том, что наличие API или CLI открывает путь к программной интеграции независимо от того, идёт ли речь о платформе мероприятий, CRM-системе, конструкторе форм или аналитическом сервисе.
Этот опыт также объясняет, почему в среде с несколькими рынками предпочтительно создавать специализированный рабочий процесс. Команда APAC не работает как единый рынок: один и тот же вебинар может проходить на японском языке в Токио и на корейском в Сеуле, при этом различаются сегменты, поля CRM и критерии определения качественного потенциального клиента. Танака отмечает, что адаптация готовой платформы к этим различиям может потребовать бюджета на настройку и консалтинг, а также ожидания включения нужных функций в дорожную карту поставщика, тогда как внутреннюю разработку можно изменять через pull request и ревью.
Это не рецепт отказа от готовых маркетинговых платформ и не доказательство того, что автоматизация подходит каждой команде. Практическая ценность представленного случая заключается в том, чтобы сначала задокументировать работу, а затем отделить решения, требующие человеческой гибкости, от повторяющихся шагов, которые можно выполнять автоматически. Успех этой модели также зависит от наличия внешних инструментов, пригодных для интеграции, и точности руководств по рабочим процедурам: если правила неполны или меняются без обновления, ошибки могут перейти в автоматизированный рабочий процесс, а не исчезнуть.