في هذه الصفحة
قد تظهر تذكرة دعم بحالة «تم» بينما لا يستطيع العميل استخدام الميزة. في طلب افتراضي لتصدير CSV، دُمجت الشيفرة الخاصة بالتذكرة T-104 لكن إطلاق الميزة ما زال معطلاً. ستكون عبارة «ميزتك متاحة الآن» وعداً مخيباً.
اربط طلباً واحداً بإصدار مؤكَّد واحد وشخص يمكن الوصول إليه. يصف مثال GTM Loop Closer من xAI العثور على الالتزامات، وعرض الأدلة، وإعداد الرد. هنا يخضع الالتزام لاختبار أشد: يجب أن يؤكد مسؤول المنتج ما أُطلق ومن يستطيع استخدامه.
ابدأ عندما يتوافر دليل الإصدار
استخدم سجل إصدار المنتج محفّزاً، لا تغيّر حالة التذكرة. يحتاج السجل إلى feature_id ثابت، وrelease_id، والسلوك المُطلق، وتاريخ الإصدار، وحالة الإتاحة، واسم المسؤول. يجب أن يتحقق المسؤول من إتاحة الميزة لحساب العميل الطالب أو خطته. لا يكفي دمج التغيير أو عرض في بيئة التجربة أو مذكرة إصدار مخطط لها.
اربط سجل الطلب بالإصدار بواسطة معرّف الميزة، والطلب بالعميل بواسطة معرّف جهة الاتصال المحفوظ في نظام الدعم. احفظ الربط والحالة فقط. لا يحتاج Grok Bot إلى صندوق الوارد أو الكتالوج كاملاً. إذا غاب أحد المعرّفين، فأعد بنداً للمراجعة بدلاً من التخمين اعتماداً على تشابه الأسماء.
| المدخل | الحد الأدنى من الحقول | ما يجب التحقق منه |
|---|---|---|
| الطلب | معرّف التذكرة، ومعرّف الميزة، وتاريخ الطلب، ومعرّف جهة اتصال الطالب | أن هذا الشخص طلب هذه الميزة فعلاً |
| الإصدار | معرّف الإصدار، ومعرّف الميزة، والسلوك المُطلق، والإتاحة، وتوقيع المسؤول | أن هذا الحساب يستطيع استخدامها الآن |
| جهة الاتصال | معرّف جهة الاتصال، ومسار الدعم المعتمد، وحالة الحظر | أن هذا الشخص يمكنه تلقي هذا النوع من الردود |
الطلب ليس موافقة تسويقية. استخدم قناة تواصل الدعم المعتمدة للرد الواقعي على ذلك الطلب. إذا روّجت المسودة لميزات أخرى أو طلبت ترقية أو استهدفت أشخاصاً لم يطلبوا الميزة، فتعامل معها بوصفها حملة تسويقية منفصلة لها قواعد أهلية خاصة. احترم إلغاء الاشتراك والحظر في القناة المختارة. يشرح دليل الاشتراك بالتأكيد المزدوج لماذا لا تحل التذكرة محل سجل الاشتراك.
أعد إجابة واحدة بطلب محدود
يربط ناتج افتراضي T-104 بـF-7 وR-22، لكنه يجد أن الإتاحة معطلة. انتظر؛ لا ترسل.
انسخ هذا الطلب بعد تقديم السجلات المعتمدة:
افحص سجلات الطلب والإصدار وجهة الاتصال التي أقدمها فقط. طابق باستخدام معرّف الميزة الثابت ومعرّف جهة الاتصال، لا تشابه الكلمات وحده. لكل مرشح، اعرض معرّف التذكرة والميزة والإصدار، واعتماد المسؤول، وإتاحة الميزة للحساب، والغرض المعتمد للتواصل، وحالة الحظر. ضع الأدلة المفقودة أو المتعارضة في حالة «محظور». اكتب رداً واقعياً قصيراً فقط لإصدار مؤكَّد ومتاح. اذكر ما تغيّر، وأين يستطيع العميل استخدامه، وأين يجد المساعدة، باستخدام الحقائق المقدمة فقط. لا تستنتج موافقة تسويقية، ولا تضف ادعاءات ترويجية، ولا تنشئ أو تحدّث جهات اتصال، ولا ترسل رسالة، ولا تغلق تذكرة. أعد جدول الأدلة والمسودة هنا للمراجعة.
الفحص: يقارن مسؤول المنتج المسودة بسجل الإصدار ويختبر الإتاحة في الحساب الطالب. ويتحقق مسؤول الدعم من هوية المستلم وغرض التواصل. أبقِ المسودة في المحادثة إذا فشل أي فحص. يشرح دليل البدء لاستخدام Grok Bot مع Brevo اتصال MCP الموثّق وسبب ضرورة فحص العمليات المتاحة؛ ولم يُشغّل هذا المسار في حساب Grok Bot.
أرسل مرة واحدة، ثم سجّل الإيصال
قبل إدراج إرسال معتمد في الطابور، احسب مفتاح منع التكرار من feature_id + contact_id + release_id واحجزه حجزاً ذرياً في سجل دائم. يمنع وجود مفتاح محجوز أو معلّق أو مجهول الحالة أو ناجح إدراج إرسال آخر. يجب ألا يجتاز عاملان فحصاً منفصلاً للقراءة ثم الكتابة. بعد انتهاء المهلة، طابق الحدث مع إيصالات مزود الإرسال قبل التفكير في أي إعادة محاولة؛ عدم تلقي رد ليس دليلاً على عدم التسليم.
بعد المراجعة، اضبط المسار المعتمد في Brevo. ضمن Automations > Workflows > Create an automation، إذا كان حسابك يتيح محفّز حدث مخصص وإجراء بريد إلكتروني، فاربط حدثك المقترح feature_followup_approved بقالب معتمد لغرض الدعم. يحتاج الحدث إلى معرّف جهة اتصال متحقق منه؛ معرّفا الميزة والإصدار خاصيتان مقترحتان للحدث، وليستا قيمتين افتراضيتين في Brevo. اختبر بجهة اتصال داخلية قبل التفعيل. أطلق حدثاً واحداً فقط بعد الموافقة ونجاح حجز المفتاح. وإلا فاستخدم رداً يدوياً من الدعم. توثّق Brevo الأحداث المخصصة وإعداد مسارات العمل؛ افحص الإجراءات المتاحة في حسابك. مسودة Grok Bot لا تأذن بالتنفيذ. يغطي دليل Brevo API مسار API المنفصل. سجّل قبول الحدث منفصلاً عن إيصال إرسال الرسالة. قبول الحدث لا يثبت إرسال بريد. سجّل المستلم المحدد، والنص المعتمد، ودليل الإصدار، والغرض، والقناة، ومعرّف الإرسال لدى المزود، والطابع الزمني. لا تضع علامة «تمت المتابعة» على تذكرة الدعم إلا بعد إيصال إرسال مؤكَّد أو رد دعم يدوي موثّق. يثبت توثيق Brevo MCP وجود سطح تكامل ممكن، وليس توافر كل عمليات الكتابة أو الصلاحيات في عميلك.
حدّد موعد انتهاء للملاحظة لكل إصدار، مثل سبعة أيام بعد تأكيد المسؤول الإتاحة. عند ذلك الموعد، قِس الإكمال بوصفه الطلبات المؤهلة ذات متابعة مؤكَّدة واحدة مقسومة على الطلبات المؤهلة لذلك الإصدار. أبقِ الطلبات المحظورة والتي يتعذر الوصول إلى أصحابها في أعداد منفصلة. تساعد حالة التسليم وردود العملاء في كشف الإخفاق؛ ولا تثبت عمليات الفتح أن العميل رأى الميزة أو استخدمها. الإصدار الذي لا يملك مستلماً متحققاً منه لا يزال عملاً مفتوحاً. تنطبق دقة الأدلة نفسها على تجربة حملة، وإن اختلف قياس نتيجتها.
الأسئلة المتكررة
متى تكون الميزة المطلوبة جاهزة لمتابعة العميل؟
فقط بعد تأكيد المسؤول معرّف الإصدار وإتاحة الميزة لحساب ذلك العميل والسلوك الفعلي الذي أُطلق. التذكرة المغلقة أو طلب تعديل شيفرة تم دمجه أو مسودة ملاحظات الإصدار ليست دليلاً على إمكان استخدامها.
هل يسمح طلب الدعم بإرسال بريد تسويقي؟
لا. أرسل رداً واقعياً على طلب هذا العميل عبر مسار تواصل الدعم المعتمد. تحتاج الحملة الترويجية الأوسع إلى جمهور مؤهل وأساس اشتراك مستقل؛ ولا تنشئ التذكرة ذلك.
هل يستطيع Grok Bot إرسال إشعار الإصدار تلقائياً عبر Brevo؟
يستخدم هذا الدليل Grok Bot لمطابقة الأدلة وصياغة رد. أي كتابة أو إرسال عبر Brevo يحتاج إلى اتصال متحقق منه على حدة، وفحص إذن، وموافقة. لم نختبر توافق MCP الموثّق عملياً هنا.