دليل الموافقة على قالب DLT
يجب أن يصف قالب DLT بالضبط ما سيرسله تطبيقك.
تصبح الموافقة على النموذج فوضوية عندما تقوم الفرق بإخفاء النسخة المتغيرة داخل المتغيرات، أو مزج التسويق مع OTPs، أو إرسال المحتوى قبل أن يصبح حدث العمل واضحًا. تبدأ القوالب النظيفة بقصد الرسالة وسياق الموافقة والصيغة الثابتة وتعيين حمولة المطور.
تسجيل قالب DLT هو المكان الذي تتباطأ فيه العديد من مشاريع الرسائل القصيرة. قد يكون تسجيل الكيان مكتملاً. قد تتم الموافقة على الرأس. قد يكون موفر خدمة الرسائل القصيرة جاهزًا. ثم يتم رفض قالب المحتوى، أو يكون غير واضح، أو واسع جدًا، أو يستحيل على المطورين إرساله دون تغيير الصياغة.
يشرح هذا الدليل كيفية إعداد قوالب DLT من خلال عدسة التنفيذ العملي: اختر فئة الرسالة الصحيحة، وقرارات الموافقة والمحتوى المنفصلة، وكتابة نسخة ثابتة من الرسالة، والحفاظ على المتغيرات ضيقة، وإعداد عينات نظيفة، وتعيين القوالب المعتمدة في SMS API.
ملاحظة المصدر الرسمية: تدرج TRAI تسجيل قالب المحتوى وتسجيل الموافقة كجزء من سير عمل المرسل. تنشر شركة Airtel أيضًا مواد إرشادية لقالب المحتوى لمنصة الاتصالات التجارية الخاصة بها. تحقق دائمًا من تعليمات البوابة الحالية قبل الإرسال: نصائح TRAI للمرسلين.
تعتمد الموافقة على النموذج على الوضوح
إجابة سريعة
تكون الموافقة على قالب DLT أسهل عندما تكون الرسالة محددة وجاهزة للإنتاج.
قبل إرسال قالب DLT، تأكد من:
- حدث العمل الذي يقوم بتشغيل الرسائل القصيرة.
- رأس المرسل الذي سيرسله.
- سواء كانت الرسالة لمرة واحدة (OTP)، أو خدمة ضمنية، أو خدمة صريحة، أو ترويجية.
- ما إذا كانت موافقة العميل مطلوبة لهذا التدفق.
- نص الرسالة الثابتة بالضبط.
- المتغيرات وما يسمح لكل متغير أن يحتوي عليه.
- حقول واجهة برمجة تطبيقات الموفر وعينة الحمولة.
- حكم تغيير اللفظ بعد الموافقة.
قالب المحتوى مقابل قالب الموافقة
يرتبط قالب المحتوى ونموذج الموافقة ولكنهما غير قابلين للتبديل.
| نوع القالب | ما يصفه | مثال على سؤال التخطيط |
|---|---|---|
| نموذج الموافقة | لماذا وكيف يتم الحصول على الإذن عند الاقتضاء | "هل وافق العميل صراحة على تلقي تذكيرات المواعيد أو العروض؟" |
| قالب المحتوى | نص الرسائل القصيرة المتكررة المرسلة من خلال الموفر | "ما هي الصياغة والمتغيرات الدقيقة التي سيرسلها التطبيق؟" |
بالنسبة لمرة واحدة (OTP) وتنبيهات الخدمة التي تم تشغيلها، تركز الفرق غالبًا على قوالب المحتوى. بالنسبة لاتصالات الموافقة الصريحة أو التدفقات الترويجية، يصبح التعامل مع الموافقة مسألة تشغيلية أكبر. يجب تأكيد المسار الدقيق من خلال بوابة المشغل الحالية وتوجيهات المزود.
الانضباط المتغير
المتغيرات تكون مفيدة فقط عندما تكون ضيقة. المتغير الجيد يغير القيمة دون تغيير معنى الرسالة.
أمثلة الجودة المتغيرة
| حالة الاستخدام | متغير أفضل | متغير محفوف بالمخاطر |
|---|---|---|
| مكتب المدعي العام | code، expiry_minutes | جملة كاملة مع الكود ونسخة العرض. |
| تحديث الطلب | order_id، status، tracking_link | فقرة الحالة بأكملها في عنصر نائب واحد. |
| تذكير بالموعد | doctor_name، date، time | تم استبدال نص التذكير العام في كل مرة. |
| إيصال الدفع | amount، invoice_id، short_link | إيصال مختلط ورسالة الحملة. |
إذا كان بإمكان المتغير أن يحتوي على أي شيء، فلن يتمكن المراجعون والمطورون المستقبليون من معرفة ماهية الرسالة حقًا. احتفظ بلغة العمل الثابتة خارج المتغيرات واستخدم المتغيرات فقط للقيم التي تتغير بشكل حقيقي لكل مستلم.
ورقة عمل مراجعة القالب
استخدم ورقة عمل قبل إرسال البوابة الإلكترونية:
قائمة التحقق من جاهزية قالب DLT
- تم توثيق حدث الرسالة.
- تم تحديد رأس المرسل.
- يتم اختيار الفئة قبل كتابة النسخة.
- الصياغة الثابتة نهائية أو قريبة جدًا من النهائية.
- تتم تسمية المتغيرات وشرحها.
- قيم العينة وهمية وواقعية.
- يتم تسجيل علاقة الموافقة حيثما ينطبق ذلك.
- تتم مراجعة الروابط ومراجع APK وأرقام الهواتف وعناوين URL لتلبية متطلبات الموفر الإضافية.
- تم تحديد حقول حمولة المطور.
- يوقع صاحب العمل على الصياغة النهائية.
لا ترسل نسخة "مؤقتة" إلا إذا أدرك الجميع أن رمز الإنتاج قد يحتاج إلى انتظار النسخة النهائية المعتمدة.
أنماط الرفض الشائعة
نية مختلطة
يبدأ القالب كتنبيه لمرة واحدة أو خدمة ولكنه يتضمن عروضًا أو لغة ترويجية واسعة النطاق أو تنبيهات غير ذات صلة.
علاقة ضعيفة بالعلامة التجارية
يشير المحتوى إلى علامة تجارية أو منتج أو اسم مرسل لا يرتبط بشكل واضح بالكيان أو الرأس المسجل.
متغير واسع النطاق
يقوم المتغير بإخفاء الجمل الكاملة أو نسخة الحملة أو المطالبات المتغيرة. وهذا يجعل القالب المعتمد غير قابل للتنبؤ به.
غموض الموافقة
تتضمن الرسالة اتصالًا قائمًا على الموافقة، ولكن لم يتم توثيق قالب الموافقة أو الغرض أو رحلة العميل.
ماذا تفعل بعد الموافقة
الموافقة على القالب ليست نهاية العمل. يجب ترجمة القالب المعتمد إلى سلوك الإنتاج.
قم بتسجيل معرف القالب المعتمد
قم بتخزينه مع الرأس والفئة وحدث الرسالة وملاحظات البوابة الإلكترونية. إخفاء المعرفات الحساسة في لقطات الشاشة العامة.
تعيين المتغيرات إلى حمولة API
يحتاج المطورون إلى ترتيب المتغير والقيم المسموح بها ونص الطلب النموذجي باستخدام بيانات وهمية.
تشغيل الاختبارات الخاضعة للرقابة
أرسل رسالة نصية قصيرة تجريبية لكل قالب وقارن النص المستلم بالصيغة المعتمدة.
إنشاء سياسة التغيير
يجب مراجعة أي تغيير في المحتوى لمعرفة تأثير DLT قبل أن يصل إلى مرحلة الإنتاج.
الأسئلة الشائعة
هل يمكنني تغيير صياغة الرسائل القصيرة بعد الموافقة على قالب DLT؟
التعامل مع تغييرات الصياغة بعناية. إذا لم تعد رسالة الإنتاج مطابقة للنمط المعتمد، فقد تحتاج إلى المراجعة وإعادة الإرسال وتحديثات الموفر وإعادة الاختبار.
هل يمكن للمتغير أن يحتوي على جملة كاملة؟
تجنب ذلك. يجب أن تحمل المتغيرات قيمًا ضيقة، ولا تغير غرض الرسالة. من الصعب مراجعة متغيرات الجملة الكاملة والمحافظة عليها.
هل تحتاج كافة النماذج إلى نموذج موافقة؟
ليس دائما بنفس الطريقة. تعتمد الحاجة على فئة الرسالة ومسار الموافقة وقواعد البوابة/الموفر الحالية. توثيق القرار قبل تقديمه.
هل تستطيع Shinka مراجعة النماذج المرفوضة الحالية؟
نعم. يمكن لـ Shinka مراجعة الصياغة والمتغيرات وملاءمة الفئة وسياق الموافقة وتعيين واجهة برمجة التطبيقات قبل إعادة الإرسال. تظل الموافقة خاضعة للتحكم من خلال عملية المشغل.
