GitHub’s marketing team in Japan and South Korea turned recurring event operations into an executable workflow within GitHub, instead of managing each step manually across registration pages, links, email campaigns, and customer databases. According to Tomoko Tanaka, the process begins with a single GitHub Issue, after which GitHub Actions sets up the event, reviews registrant lists, and carries out follow-up work after it ends.
The article does not announce a new product; rather, it presents an operational practice Tanaka developed using GitHub’s existing tools, with the help of GitHub Copilot to turn internal procedure guides into automation. The experiment is significant because it connects marketing management with concepts familiar to software teams, such as review, change history, triggers, and repeatable workflows.
The Problem: Small Steps and Cascading Errors
The team’s events include recurring webinars for enterprise developers, community meetups in Tokyo, and closed-door sessions for executives in Seoul. After any event is approved, a series of repetitive tasks begins: copying the landing page, creating links with UTM tags for each channel, preparing the invitation message, submitting the send request, adding the event to two project boards, then downloading and cleaning the registrant list daily until the event date.
After the event ends, the attendance list must be exported, reshaped for upload to the customer relationship management system, tagged appropriately, and used to prepare a report. No individual step seems difficult, but an error in a link, campaign name, or daily update can affect reporting and subsequent operations.
Three Building Blocks for the Workflow
The experiment relied on three core GitHub functions:
- Issue Forms: They act as structured request forms instead of an empty text box, collecting fields such as the event title, date, region, campaign name, and target audience. Different forms exist for webinars and in-person events, but they feed the same operating mechanism.
- Labels: They are used not only as descriptive tags, but also as operating keys. When a label such as event-setup is added, the workflow associated with it starts.
- GitHub Actions: They execute tasks, read the fields contained in the request text, and connect to external tools to set up the event, monitor registrants, or complete follow-up work.
With this design, the Issue becomes the unit of work that brings together the plan, discussion, and status, while providing a visible history of decisions and a link to every change. Changes to the workflow can also be treated as code changes that go through a pull request and review before being merged.
GitHub Copilot’s Role in Turning Procedures into Automation
Tanaka did not begin by writing code directly. Instead, she wrote the team’s operating guides and provided them to GitHub Copilot, then developed the automation through dialogue. She says that her previous experience operating databases on Linux servers helped her see these procedures as a programmable pipeline, even as she acknowledges that her programming skills are no longer what they once were.
Planning begins with a conversation describing the idea, such as organizing a webinar about AI-assisted development in November. Copilot then reads the AGENTS.md file located in the repository root, a Markdown-formatted guide that defines campaign-naming rules, mappings between fiscal quarters and dates, time zones, and invitation-message standards. Based on these rules and a similar previous event, Copilot suggests a campaign name, prepares two versions of the invitation message, and asks the questions required by the operating guide.
What Changes in Practice?
This approach reduces repetitive manual work without eliminating human judgment during the planning stage. The conversation leaves room to customize a specific event, while automation handles the fixed steps after approval. According to the article, setting up an event used to take approximately two days manually, whereas the process now starts with a single Issue and then performs setup, daily registrant-list checks, and cleanup after the event ends.
The decisive factor is not GitHub Actions alone, but the programmability of the other tools. The event-management platform provides an API, while the customer relationship management system relies on an official CLI that covers the required tasks and signs in through the browser, so Tanaka did not need to configure an API key for it. The principle drawn from the article is that having an API or CLI is enough to open a path to programmatic integration, whether the tool is an event platform, CRM system, form builder, or analytics service.
The experiment also illustrates why building a custom workflow can be preferable in a multi-market environment. The APAC team does not operate as a single market; the same webinar may be held in Japanese in Tokyo and Korean in Seoul, with differences in segments, CRM fields, and criteria for defining a good lead. Tanaka notes that adapting an off-the-shelf platform to these differences may require customization and consulting budgets, as well as waiting for the vendor’s roadmap, whereas in-house development allows the workflow to be changed through a pull request and review.
This is not a recipe for eliminating ready-made marketing platforms, nor evidence that automation is suitable for every team. The practical value of the case presented lies in documenting the work first, then separating decisions that require human flexibility from repetitive steps that can be executed automatically. The model’s success also depends on the availability of integrable external tools and the accuracy of the operating guides; if the rules are incomplete or change without being updated, errors may move into the automated workflow instead of disappearing.