Marketing Ops as Code: เปลี่ยนการจัดอีเวนต์ให้เป็นอัตโนมัติด้วย GitHub และ AI

ผมดูแลด้านการตลาดสำหรับ GitHub ในประเทศญี่ปุ่นและเกาหลี ซึ่งอีเวนต์ถือเป็นหัวใจสำคัญของงาน ไม่ว่าจะเป็นเวบินาร์สำหรับนักพัฒนาองค์กร งานมีตติ้งชุมชนในโตเกียว ไปจนถึงเซสชันผู้บริหารในโซล โจทย์สำคัญคือการทำความเข้าใจว่านักพัฒนาต้องการอะไร หัวข้อไหนคุ้มค่ากับเวลา และใครควรจะอยู่ในห้องนั้น ซึ่งผมยินดีที่จะใช้เวลาทั้งวันขบคิดกับคำถามเหล่านี้

แต่ปัญหาที่ตามมาหลังจากตัดสินใจคือ "งานแอดมิน" ที่มีลำดับขั้นตอนตายตัวและกินเวลามาก เมื่ออีเวนต์ได้รับอนุมัติ ลำดับงานที่น่าเบื่อหน่ายจะเริ่มขึ้นทันที:

• ทำสำเนาแลนดิ้งเพจบนแพลตฟอร์มอีเวนต์
• สร้างลิงก์ติดแท็ก UTM แยกตามช่องทางให้ถูกต้องแม่นยำ
• ร่างอีเมลเชิญและส่งคำร้องไปยังทีมที่เกี่ยวข้อง
• เพิ่มอีเวนต์ลงในบอร์ดโปรเจกต์ต่างๆ
• ดาวน์โหลดและทำความสะอาดรายชื่อผู้ลงทะเบียนทุกเช้าจนถึงวันงาน
• หลังจบงานต้องส่งออกรายชื่อ ปรับฟอร์แมตเพื่อเข้า CRM แท็กข้อมูล และเขียนรายงาน

แม้ว่างานเหล่านี้จะไม่ยาก แต่ก็เป็นจุดที่เกิดข้อผิดพลาดได้ง่าย เช่น ใส่ลิงก์ผิดหรือสะกดชื่อแคมเปญไม่ตรง ซึ่งจะส่งผลเสียต่อรายงานข้อมูลในภาพรวมอีกหลายฉบับ

ประเด็นคือ ผมเคยเป็นวิศวกรดูแลฐานข้อมูลมาก่อน แม้ทักษะการเขียนโค้ดจะเริ่มสนิมเกาะ แต่ผมยังมองเห็น Pipeline ที่ควรถูกทำให้เป็นอัตโนมัติ นี่คือจุดที่ผมนำ GitHub Copilot มาใช้งาน และคุณเองก็ทำได้เช่นกันในงานของคุณ

แทนที่จะเขียนโค้ดเอง ผมเปลี่ยนมาเขียน Runbook หรือคู่มือการทำงาน แล้วส่งต่อให้ GitHub Copilot พัฒนาระบบอัตโนมัติผ่านการแชทโต้ตอบ ทุกวันนี้อีเวนต์ที่เคยต้องเตรียมงานหลายวัน สามารถตั้งค่าตัวเองได้ผ่าน GitHub Issue เพียงอันเดียว ทั้งคัดกรองผู้ลงทะเบียนและจัดการข้อมูลหลังจบงานได้เองทั้งหมด

บทความนี้จะพาไปดูว่าระบบนี้ทำงานอย่างไร และทำไมผมถึงเชื่อว่าใครก็ตามที่ทำงานซ้ำซ้อนผ่านเครื่องมือที่มี API หรือ CLI ก็สามารถสร้างระบบอัตโนมัติแบบนี้ได้

อีเวนต์คือ Issue

แนวคิดพื้นฐานนี้เริ่มจากการที่ทีมการตลาดของ GitHub มักเปิด GitHub Issue หนึ่งอันต่อหนึ่งโปรเจกต์เพื่อใช้สื่อสารและติดตามสถานะอยู่แล้ว ผมจึงทำให้ Issue นั้นเป็นตัวลงมือทำงานจริง โดยใช้ฟีเจอร์หลัก 3 อย่างของ GitHub:

• Issue forms คือใบสมัคร: แทนที่จะเป็นช่องว่างให้พิมพ์ issue form จะกำหนดฟิลด์ข้อมูลให้ชัดเจน เช่น ชื่ออีเวนต์ วันที่ และกลุ่มเป้าหมาย เพื่อให้ระบบนำข้อมูลไปใช้งานต่อได้ทันที
• Labels คือสวิตช์: เลเบลอย่าง event-setup ไม่ได้มีไว้แค่คัดแยกประเภท แต่มันคือตัวจุดชนวน (Trigger) ให้เวิร์กโฟลว์เริ่มทำงาน
• Actions คือเครื่องจักร: GitHub Actions จะทำงานทันทีที่มีการติดเลเบล โดยจะดึงข้อมูลจาก Issue ไปดำเนินการในระบบต่างๆ

ข้อดีคือทุกสิ่งที่นักพัฒนาได้จาก Repository ผมก็ได้มาฟรีๆ ทั้งประวัติการแก้ไข ความโปร่งใส และการตรวจสอบย้อนหลังได้ทุกการตัดสินใจ

หัวใจสำคัญที่ทำให้สิ่งนี้เป็นจริงได้คือ เครื่องมือที่ใช้ต้องมีช่องทางให้เขียนสคริปต์สั่งการได้ (Programmable) ไม่ว่าจะเป็น API หรือ CLI หากงานซ้ำๆ ของคุณรันผ่านแพลตฟอร์มที่มีสิ่งเหล่านี้ ไม่ว่าจะเป็น CRM หรือเครื่องมือวิเคราะห์ข้อมูล คุณก็สามารถประยุกต์ใช้รูปแบบนี้ได้ทันที

หลายคนอาจสงสัยว่าทำไมไม่ใช้เครื่องมือ Marketing Automation สำเร็จรูป? คำตอบคือความหลากหลายของตลาด APAC ที่มีความต้องการต่างกันในแต่ละประเทศ การสร้างระบบขึ้นมาเองช่วยให้เราปรับเปลี่ยนเวิร์กโฟลว์ได้รวดเร็วผ่าน Pull Request เหมือนการพัฒนาซอฟต์แวร์ โดยไม่ต้องรอ Roadmap จากผู้ให้บริการภายนอก

การวางแผนอีเวนต์คือการสนทนา

กระบวนการเริ่มต้นจากการที่ผมบอก GitHub Copilot ว่าต้องการรันเวบินาร์ในหัวข้อใดและช่วงเวลาไหน จากนั้น Copilot จะไปอ่านไฟล์ AGENTS.md ซึ่งเป็น Runbook ของทีมที่ระบุระเบียบการตั้งชื่อและมาตรฐานการทำงาน

GitHub Copilot จะวิเคราะห์ข้อมูลจากอีเวนต์ในอดีต เสนอชื่อแคมเปญที่ถูกต้องตามกฎ และร่างอีเมลเชิญให้ตรวจสอบ การใช้การสนทนา (Conversational AI) มาคั่นกลางช่วยให้ระบบมีความยืดหยุ่น โดยที่มนุษย์ยังคงมีอำนาจในการตัดสินใจและปรับแต่งรายละเอียดได้ก่อนที่ระบบอัตโนมัติจะเริ่มทำงานจริง

ในตอนแรกผมใช้ GitHub Copilot CLI ผ่าน Terminal แต่ปัจจุบันใช้ GitHub Copilot app ทำให้ใช้งานง่ายขึ้นมากสำหรับทุกคน การแบ่งงานจึงชัดเจนคือ GitHub Copilot ร่าง ผมเป็นคนตัดสินใจ เมื่อทุกอย่างลงตัว Copilot จะสร้าง Issue พร้อมเลเบลที่ถูกต้องเพื่อให้เครื่องจักรรับช่วงต่อ

หนึ่งเลเบล เตรียมการครบถ้วน

ทันทีที่ติดเลเบล event-setup ระบบ GitHub Actions จะจัดการงานที่เคยใช้เวลาทั้งวันให้เสร็จในไม่กี่นาที:

• สร้างหน้าแลนดิ้งเพจใหม่โดยเลียนแบบจากอีเวนต์ในอดีต
• สร้างชุด URL ติดแท็ก UTM ให้ครบทุกช่องทาง
• สร้างอีเมลเชิญในรูปแบบไฟล์ Word และอัปโหลดเข้า Repository
• เปิด Issue ส่งคำร้องไปยังทีมที่เกี่ยวข้องโดยอัตโนมัติ
• สรุปสถานะการทำงานกลับมาที่ Issue เดิมเพื่อให้ทุกคนเห็นข้อมูลตรงกัน

นอกจากนี้ยังมีระบบคัดกรองรายชื่อผู้ลงทะเบียนที่ทำงานตามเวลา (Cron job) ทุกเช้า เพื่อแยกแยะกลุ่มเป้าหมายที่แท้จริงออกจากคู่แข่งหรือข้อมูลที่ผิดพลาด

สิ่งที่ผมภูมิใจที่สุดคือการสร้างสวิตช์ DRY_RUN ไว้เป็นตัวแปรใน Repository เมื่อเปิดใช้งาน ระบบจะทำงานทุกขั้นตอนโดยไม่ไปกระทบกับระบบภายนอกจริง ช่วยให้เราซ้อมและทดสอบเวิร์กโฟลว์ได้จนมั่นใจก่อนใช้งานจริง

หลังจบงาน ใช้คำสั่ง Slash Command

งานหลังจบอีเวนต์ที่เคยน่าเบื่อ ตอนนี้เหลือเพียงสองคำสั่งง่ายๆ คือ /lead-upload สำหรับดึงรายชื่อและจัดฟอร์แมตเพื่อส่งเข้า CRM และ /event-report เพื่อดึงตัวชี้วัดมาสร้างรายงานสรุปผลใน Issue เดียวกัน

ความลับเบื้องหลังคือ GitHub Copilot agent skills ซึ่งเป็นไฟล์ Markdown ที่เขียนอธิบายขั้นตอนการทำงานด้วยภาษาปกติ (Plain language) ถ้าคุณเขียนคู่มือการทำงานได้ คุณก็สามารถสร้าง Skill ให้ AI ทำงานแทนได้

การใช้ Skill แทนการเขียนโปรแกรมตายตัวช่วยให้แต่ละประเทศในภูมิภาคปรับปรุงขั้นตอนของตนเองได้ง่าย เพียงแค่แก้ไขไฟล์ Markdown โดยไม่ต้องแก้โค้ดระบบหลัก และยังสามารถใช้กระบวนการ Pull Request เพื่อตรวจสอบความถูกต้องก่อนเริ่มใช้งานได้อีกด้วย

ปลอดภัยด้วยเกราะป้องกันในตัว

การใช้ระบบอัตโนมัติกับข้อมูลลูกค้าอาจฟังดูเสี่ยง แต่ระบบของ GitHub มีเกราะป้องกัน (Guardrails) ที่แน่นหนา:

• Push Protection: ระบบจะบล็อกการบันทึก API Token หรือความลับต่างๆ ลงใน Repository โดยอัตโนมัติ
• นโยบายข้อมูลของ Copilot: ข้อมูลธุรกิจที่นำมาวิเคราะห์จะไม่ถูกนำไปฝึกโมเดลต่อ ทำให้เราใช้งาน AI กับข้อมูลสำคัญได้อย่างสบายใจ
• การเลือกโมเดลที่เหมาะสม: เราสามารถเลือกใช้โมเดลที่ทำงานเร็วและราคาถูกสำหรับงานทำความสะอาดข้อมูล และใช้โมเดลที่ฉลาดกว่าสำหรับงานสร้างสรรค์เนื้อหาแคมเปญ

บทเรียนสำคัญอย่างหนึ่งคือ อย่าทำระบบอัตโนมัติแล้วทิ้งไว้โดยไม่เฝ้าดู ระบบควรมีการแจ้งเตือนเมื่อเกิดข้อผิดพลาดเพื่อให้เราเข้าไปแก้ไขได้ทันที

เริ่มต้นด้วยงานเดียว

สำหรับใครที่อยากเริ่ม ให้เลือกงานที่ทำซ้ำซากที่สุดมาหนึ่งอย่าง ตรวจสอบว่ามี API หรือ CLI ให้ใช้ไหม แล้วเริ่มสร้างเวอร์ชันที่เล็กที่สุดก่อน เช่น Issue form หรือสคริปต์ง่ายๆ รันมันด้วยสวิตช์ Dry-run จนมั่นใจแล้วค่อยขยายผล

ผมไม่ได้เขียนโค้ดที่ซับซ้อน ผมแค่เขียนสิ่งที่ผมรู้อยู่แล้วว่างานนั้นต้องทำอย่างไร และให้แพลตฟอร์มจัดการส่วนที่เหลือ ความสำเร็จในการลดภาระงานอาจอยู่ห่างจากคุณเพียงแค่การเขียนคู่มือการทำงานออกมาหนึ่งชุดเท่านั้น

เริ่มต้นใช้งาน:

• Syntax for issue forms
• GitHub Actions documentation
• GitHub Copilot documentation
• บล็อกสร้างแรงบันดาลใจ: I automated my job (and it made me a better leader)