A equipe de marketing do GitHub no Japão e na Coreia do Sul transformou os processos recorrentes de eventos em um fluxo de trabalho executável dentro do GitHub, em vez de gerenciar manualmente cada etapa entre páginas de inscrição, links, campanhas de e-mail e bancos de dados de clientes. De acordo com Tomoko Tanaka, o processo começa com uma única Issue do GitHub; depois, o GitHub Actions cuida da configuração do evento, da revisão das listas de inscritos e das atividades de acompanhamento após seu encerramento.
O material não apresenta de forma alguma o lançamento de um novo produto, mas mostra uma prática operacional desenvolvida por Tanaka usando ferramentas que o GitHub já oferece, com o apoio do GitHub Copilot para transformar os guias internos de procedimentos em automação. A importância da experiência está em conectar a gestão de marketing a conceitos familiares às equipes de software, como revisão, registro de alterações, gatilhos e fluxos de trabalho reproduzíveis.
O problema: pequenas etapas e erros em cadeia
Os eventos da equipe incluem webinars recorrentes para desenvolvedores corporativos, encontros da comunidade em Tóquio e sessões fechadas para executivos em Seul. Depois que qualquer evento é aprovado, começa uma série de tarefas repetitivas: copiar a página de destino, criar links com tags UTM para cada canal, preparar a mensagem de convite, registrar a solicitação de envio, adicionar o evento a dois quadros de projetos e, então, baixar a lista de inscritos e limpá-la diariamente até a data do evento.
Depois do evento, é necessário exportar a lista de participantes, reformatá-la para que possa ser carregada no sistema de gerenciamento de relacionamento com o cliente, aplicar as tags adequadas aos registros e preparar um relatório. Nenhuma etapa parece difícil isoladamente, mas um erro em um link, no nome de uma campanha ou em uma atualização diária pode afetar os relatórios e as operações posteriores.
Três componentes para criar o fluxo de trabalho
A experiência baseou-se em três funções essenciais do GitHub:
- Issue Forms: funcionam como formulários de solicitação estruturados, em vez de uma caixa de texto vazia, e reúnem campos como título do evento, data, região, nome da campanha e público-alvo. Há formulários diferentes para webinars e eventos presenciais, mas eles alimentam o mesmo mecanismo operacional.
- Labels: não são usadas apenas como tags descritivas, mas como chaves de acionamento. Quando uma tag como event-setup é adicionada, o fluxo de trabalho associado a ela é iniciado.
- GitHub Actions: executa as tarefas, lê os campos presentes no texto da solicitação e se conecta às ferramentas externas para configurar o evento, acompanhar os inscritos ou concluir as atividades posteriores.
Com esse design, a Issue se torna a unidade de trabalho que reúne o plano, a discussão e o status, além de fornecer um histórico visível das decisões e um link para cada alteração. Também é possível tratar a modificação do fluxo de trabalho como uma alteração de software, que passa por uma pull request e por revisão antes de ser incorporada.
O papel do GitHub Copilot na transformação de procedimentos em automação
Tanaka não começou escrevendo o código diretamente. Em vez disso, escreveu os guias operacionais da equipe e os forneceu ao GitHub Copilot, desenvolvendo então a automação por meio do diálogo. Ela afirma que sua experiência anterior na operação de bancos de dados em servidores Linux a ajudou a enxergar esses procedimentos como um pipeline programável, mesmo reconhecendo que suas habilidades de programação já não são as mesmas de antes.
O planejamento começa com uma conversa que descreve a ideia, como organizar em novembro um webinar sobre desenvolvimento apoiado por inteligência artificial. Em seguida, o Copilot lê o arquivo AGENTS.md localizado na raiz do repositório, um guia escrito em Markdown que define regras para nomear campanhas, relacionar trimestres fiscais às datas, determinar fusos horários e estabelecer os critérios da mensagem de convite. Com base nessas regras e em um evento anterior semelhante, o Copilot sugere o nome da campanha, prepara duas versões da mensagem de convite e faz as perguntas exigidas pelo guia operacional.
O que muda na prática?
Essa abordagem permite reduzir o trabalho manual repetitivo sem eliminar a decisão humana na etapa de planejamento. A conversa deixa espaço para personalizar um determinado evento, enquanto a automação executa as etapas fixas depois que elas são aprovadas. Segundo o material, a preparação de um evento levava manualmente cerca de dois dias; agora, o processo começa com uma única Issue e executa a configuração, a verificação diária das listas de inscritos e a limpeza após o encerramento do evento.
O elemento decisivo não é apenas o GitHub Actions, mas a programabilidade das outras ferramentas. A plataforma de gestão de eventos utiliza uma API, enquanto o sistema de gerenciamento de relacionamento com o cliente depende de uma CLI oficial que cobre as tarefas necessárias e faz login pelo navegador; por isso, Tanaka não precisou configurar uma chave de API para ele. A regra extraída do material é que a existência de uma API ou CLI basta para abrir um caminho de integração programática, seja a ferramenta uma plataforma de eventos, um sistema de CRM, um criador de formulários ou um serviço de análise.
A experiência também explica por que é preferível criar um fluxo personalizado em um ambiente com vários mercados. A equipe da APAC não trabalha como um único mercado; o mesmo webinar pode ser realizado em japonês em Tóquio e em coreano em Seul, com diferenças nos segmentos, nos campos do CRM e nos critérios para definir um lead qualificado. Tanaka afirma que adaptar uma plataforma pronta a essas diferenças pode exigir orçamentos para personalização e consultoria, além de espera pela roadmap do fornecedor, enquanto a criação interna permite alterar o fluxo por meio de uma pull request e revisão.
Isso não é uma receita para eliminar plataformas de marketing prontas, nem uma prova de que a automação seja adequada para todas as equipes. O valor prático do caso apresentado está em documentar primeiro o trabalho e, depois, separar as decisões que exigem flexibilidade humana das etapas repetitivas que podem ser executadas automaticamente. O sucesso do modelo também depende da existência de ferramentas externas que possam ser integradas e da precisão dos guias operacionais; se as regras estiverem incompletas ou forem alteradas sem atualização, os erros poderão ser transferidos para o fluxo de trabalho automatizado em vez de desaparecerem.