أتمتة Triage لتذاكر الدعم: من Gmail إلى Linear بدون فوضى

مستوى القارئ: متوسط

هتكسب من المقال ده workflow عملي يقلل فرز رسائل الدعم من ساعة يوميًا إلى 10 دقائق مراجعة، بدل ما الفريق يفتح Gmail وLinear ويفضل ينسخ ويلصق.

المشكلة باختصار

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

الافتراض إن عندك Gmail للدعم، وفريق هندسي شغال على Linear، وحجم الرسائل أقل من 500 رسالة يوميًا. فوق الرقم ده هتحتاج queue حقيقي ومراقبة أفضل.

الفكرة: افصل القراءة عن القرار

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

مثال بسيط: رسالة عنوانها “Payment failed after upgrade” تتحول إلى ticket بعنوان “Payment failure after plan upgrade”، أولوية عالية، label اسمه billing. رسالة “Where is invoice?” ممكن تتحول إلى ticket منخفض الأولوية أو تفضل خارج Linear لو عندك support macro جاهز.

حسب توثيق Gmail API، طريقة users.messages.list ترجع id وthreadId، وبعدها تستخدم users.messages.get لجلب تفاصيل الرسالة. المصدر: Google Workspace Gmail API. وفي Linear، إنشاء issue يتم عبر mutation اسمها issueCreate وتقدر ترجع success وبيانات التذكرة. المصدر: Linear GraphQL API.

الخطوات العملية

1. اعمل label في Gmail باسم support-triage أو استخدم query مثل to:support@example.com is:unread.
2. هات LINEAR_API_KEY وLINEAR_TEAM_ID من Linear.
3. شغل السكربت كل 15 دقيقة من cron أو GitHub Actions.
4. احفظ hash لكل رسالة عشان تمنع إنشاء نفس ticket مرتين.
5. ابدأ بقواعد بسيطة قبل أي AI: كلمات الدفع تروح billing، كلمات login تروح auth، وكلمات slow تروح performance.

import hashlib
import os
import requests

LINEAR_API_KEY = os.environ["LINEAR_API_KEY"]
LINEAR_TEAM_ID = os.environ["LINEAR_TEAM_ID"]
LINEAR_URL = "https://api.linear.app/graphql"

RULES = [
    ("billing", 2, ["payment", "invoice", "card", "charge"]),
    ("auth", 2, ["login", "password", "2fa", "otp"]),
    ("performance", 3, ["slow", "timeout", "latency", "loading"]),
]

def classify(subject, body):
    text = f"{subject} {body}".lower()
    for label, priority, words in RULES:
        if any(word in text for word in words):
            return label, priority
    return "support", 4

def create_linear_issue(subject, body, sender):
    label, priority = classify(subject, body)
    digest = hashlib.sha256(f"{sender}:{subject}".encode()).hexdigest()[:12]
    mutation = """
    mutation IssueCreate($input: IssueCreateInput!) {
      issueCreate(input: $input) {
        success
        issue { id title url }
      }
    }
    """
    payload = {
        "query": mutation,
        "variables": {
            "input": {
                "teamId": LINEAR_TEAM_ID,
                "title": f"[{label}] {subject[:90]}",
                "description": f"From: {sender}\n\nHash: {digest}\n\n{body[:2500]}",
                "priority": priority,
            }
        },
    }
    r = requests.post(
        LINEAR_URL,
        json=payload,
        headers={"Authorization": LINEAR_API_KEY, "Content-Type": "application/json"},
        timeout=20,
    )
    r.raise_for_status()
    return r.json()

قبل وبعد بالأرقام

في سيناريو واقعي: 40 رسالة دعم يوميًا. الفرز اليدوي بياخد تقريبًا 60 دقيقة لو كل رسالة محتاجة دقيقة ونصف. بعد الأوتوميشن، 40 رسالة ممكن تتحول إلى 8 أو 12 تذكرة فعلية بعد إزالة التكرار والأسئلة البسيطة. المراجعة اليومية تبقى 10 إلى 15 دقيقة.

الـ trade-off هنا واضح. بتكسب سرعة وتنظيم وسجل واضح داخل Linear. بتخسر شوية بساطة، لأن عندك API keys، cron، واحتمال تصنيف غلط. لذلك خلي الأولوية العالية تحتاج مراجعة بشرية قبل أي تصعيد للعميل.

تفاصيل لازم تنتبه لها

• الخصوصية: لا ترسل نصوص بطاقات أو بيانات حساسة داخل description. اعمل masking قبل إنشاء ticket.
• التكرار: استخدم hash من المرسل والعنوان أو Gmail threadId. غير كده نفس المشكلة هتفتح 3 مرات.
• الـ parsing: لو بتقرأ raw email، استخدم parser رسمي بدل split عشوائي. توثيق Python يوضح إن email.parser يتعامل مع MIME ورسائل multipart. المصدر: Python email.parser.
• القياس: سجل عدد الرسائل المقروءة، عدد التذاكر المنشأة، وعدد التذاكر المكررة. لو نسبة التذاكر من الرسائل أعلى من 60%، غالبًا قواعدك واسعة زيادة.

متى لا تستخدم هذه الطريقة

لا تستخدمها لو فريق الدعم عندك شخص واحد ويستقبل أقل من 5 رسائل يوميًا. التكلفة الذهنية أعلى من المكسب. ولا تستخدمها لو عندك Zendesk أو Intercom مضبوطين وفيهم routing جاهز. في الحالة دي اربطهم بـ Linear مباشرة بدل ما تبني طبقة جديدة.

الخلاصة

الأوتوميشن الناجح هنا مش إنه يعمل كل حاجة. الناجح إنه يحول الضوضاء إلى قائمة tickets قابلة للتنفيذ. خليه محافظ في البداية. ابدأ بـ 3 labels فقط: billing، auth، performance. بعد أسبوع، راجع 100 رسالة وشوف أين أخطأ التصنيف.

الخطوة التالية

الخطوة التالية: اعمل نسخة من السكربت، وشغله على 20 رسالة قديمة بدون إنشاء tickets فعلية. اطبع التصنيف المقترح فقط. لو الدقة أقل من 80%، عدّل القواعد قبل ما توصله بـ Linear.