كيف حوّل فريق GitHub عمليات الفعاليات التسويقية إلى سير عمل برمجي

حوّل فريق التسويق لدى GitHub في اليابان وكوريا الجنوبية عمليات الفعاليات المتكررة إلى سير عمل قابل للتنفيذ داخل GitHub، بدلاً من إدارة كل خطوة يدوياً بين صفحات التسجيل والروابط وحملات البريد وقواعد بيانات العملاء. ووفقاً لتوموكو تاناكا، تبدأ العملية من GitHub Issue واحدة، ثم تتولى GitHub Actions إعداد الحدث، ومراجعة قوائم المسجلين، وتنفيذ أعمال المتابعة بعد انتهائه.

المادة لا تقدم إطلاقاً لمنتج جديد، بل تعرض ممارسة تشغيلية طورتها تاناكا باستخدام أدوات GitHub الموجودة أصلاً، مع الاستفادة من GitHub Copilot في تحويل أدلة الإجراءات الداخلية إلى أتمتة. أهمية التجربة أنها تربط بين إدارة التسويق ومفاهيم مألوفة لفرق البرمجيات، مثل المراجعة، وسجل التغييرات، والمشغلات، وسير العمل القابل للتكرار.

المشكلة: خطوات صغيرة وأخطاء متسلسلة

تتضمن فعاليات الفريق ندوات دورية لمطوري المؤسسات، ولقاءات مجتمعية في طوكيو، وجلسات مغلقة للمديرين التنفيذيين في سيول. وبعد اعتماد أي فعالية، تبدأ سلسلة من الأعمال المتكررة: نسخ صفحة الهبوط، إنشاء روابط تحمل وسوم UTM لكل قناة، إعداد رسالة الدعوة، تسجيل طلب الإرسال، إضافة الحدث إلى لوحتي مشاريع، ثم تنزيل قائمة المسجلين وتنظيفها يومياً حتى موعد الفعالية.

بعد انتهاء الحدث، يجب تصدير قائمة الحضور، وإعادة تشكيلها لتناسب الرفع إلى نظام إدارة علاقات العملاء، ووضع الوسوم المناسبة على السجلات، وإعداد تقرير. لا تبدو أي خطوة صعبة بمفردها، لكن الخطأ في رابط أو اسم حملة أو تحديث يومي قد يؤثر في التقارير والعمليات اللاحقة.

ثلاث لبنات لبناء سير العمل

اعتمدت التجربة على ثلاث وظائف أساسية في GitHub:

• Issue Forms: تعمل كنماذج طلب منظمة بدلاً من مربع نص فارغ، وتجمع حقولاً مثل عنوان الحدث وتاريخه والمنطقة واسم الحملة والجمهور المستهدف. توجد نماذج مختلفة للندوات والفعاليات الحضورية، لكنها تغذي آلية التشغيل نفسها.
• Labels: لا تستخدم كوسوم وصفية فقط، بل كمفاتيح تشغيل. فعند إضافة وسم مثل event-setup يبدأ سير العمل المرتبط به.
• GitHub Actions: تنفذ المهام، وتقرأ الحقول الموجودة في نص الطلب، ثم تتصل بالأدوات الخارجية لإعداد الحدث أو متابعة المسجلين أو إنهاء الأعمال اللاحقة.

بهذا التصميم تصبح الـ Issue وحدة العمل التي تجمع الخطة والنقاش والحالة، وتوفر تاريخاً مرئياً للقرارات ورابطاً لكل تغيير. كما يمكن التعامل مع تعديل سير العمل بوصفه تغييراً برمجياً يمر عبر طلب سحب ومراجعة قبل دمجه.

دور GitHub Copilot في تحويل الإجراءات إلى أتمتة

لم تبدأ تاناكا بكتابة الشيفرة مباشرة، بل كتبت أدلة التشغيل الخاصة بالفريق وقدمتها إلى GitHub Copilot، ثم طورت الأتمتة من خلال الحوار. وتقول إن خبرتها السابقة في تشغيل قواعد البيانات على خوادم Linux ساعدتها على رؤية هذه الإجراءات بوصفها خط أنابيب قابلاً للبرمجة، حتى مع اعترافها بأن مهاراتها البرمجية لم تعد كما كانت.

يبدأ التخطيط بمحادثة تصف الفكرة، مثل تنظيم ندوة عن التطوير المدعوم بالذكاء الاصطناعي في نوفمبر. بعد ذلك يقرأ Copilot ملف AGENTS.md الموجود في جذر المستودع، وهو دليل مكتوب بصيغة Markdown يحدد قواعد تسمية الحملات، وربط الأرباع المالية بالتواريخ، والمناطق الزمنية، ومعايير رسالة الدعوة. وبالاستناد إلى هذه القواعد وإلى فعالية سابقة مشابهة، يقترح Copilot اسم الحملة، ويعد نسختين من رسالة الدعوة، ويطرح الأسئلة التي يطلبها دليل التشغيل.

ما الذي يتغير عملياً؟

يتيح هذا الأسلوب تقليل الأعمال اليدوية المتكررة من دون إلغاء القرار البشري في مرحلة التخطيط. فالمحادثة تترك مساحة لتخصيص فعالية بعينها، بينما تتولى الأتمتة تنفيذ الخطوات الثابتة بعد اعتمادها. ووفق المادة، كان إعداد فعالية يستغرق يدوياً يومين تقريباً، بينما أصبحت العملية تبدأ من Issue واحدة ثم تنفذ الإعداد والفحص اليومي لقوائم المسجلين والتنظيف بعد انتهاء الحدث.

العنصر الحاسم ليس GitHub Actions وحدها، بل قابلية الأدوات الأخرى للبرمجة. تستخدم منصة إدارة الفعاليات واجهة API، بينما يعتمد نظام إدارة علاقات العملاء على CLI رسمي يغطي المهام المطلوبة ويسجل الدخول عبر المتصفح، لذلك لم تحتج تاناكا إلى إعداد مفتاح API له. القاعدة التي تستخلصها المادة هي أن وجود API أو CLI يكفي لفتح طريق للربط البرمجي، سواء كانت الأداة منصة فعاليات أو نظام CRM أو منشئ نماذج أو خدمة تحليلات.

توضح التجربة أيضاً سبب تفضيل بناء سير مخصص في بيئة متعددة الأسواق. ففريق APAC لا يعمل كسوق واحدة؛ قد تقام الندوة نفسها باليابانية في طوكيو وبالكورية في سيول، مع اختلاف الشرائح وحقول CRM ومعايير تعريف العميل المحتمل الجيد. وتذكر تاناكا أن تكييف منصة جاهزة مع هذه الاختلافات قد يتطلب ميزانيات تخصيص واستشارات وانتظاراً لخارطة طريق المورد، بينما يسمح البناء الداخلي بتغيير سير العمل عبر طلب سحب ومراجعة.

هذه ليست وصفة لإلغاء منصات التسويق الجاهزة، ولا دليلاً على أن الأتمتة مناسبة لكل فريق. القيمة العملية في الحالة المعروضة هي توثيق العمل أولاً، ثم فصل القرارات التي تحتاج مرونة بشرية عن الخطوات المتكررة التي يمكن تنفيذها آلياً. كما أن نجاح النموذج يعتمد على وجود أدوات خارجية قابلة للربط وعلى دقة أدلة التشغيل؛ فإذا كانت القواعد ناقصة أو تغيرت دون تحديث، فقد تنتقل الأخطاء إلى سير العمل الآلي بدلاً من اختفائها.