دليل تنفيذ SMS DLT
تسجيل DLT ليس نموذجًا واحدًا. إنه سير عمل المرسل والقالب وواجهة برمجة التطبيقات (API).
بالنسبة للرسائل النصية القصيرة للأعمال الهندية، فإن الهدف المفيد ليس فقط الحصول على تسجيل دخول إلى البوابة. الهدف هو المغادرة مع أصول المرسل المسجلة، وقوالب الرسائل المعتمدة، والمعرفات الجاهزة للمطورين، وسجل التسليم الذي يمكن للشركة الاحتفاظ به.
يقع تسجيل DLT للرسائل النصية القصيرة في الهند بين الامتثال للاتصالات والعمليات التجارية وتطوير التطبيقات. قد يعتقد المؤسس أنه بحاجة إلى "تنشيط الرسائل النصية القصيرة الجماعية". قد يعتقد المطور أنه يحتاج فقط إلى مفتاح بوابة الرسائل القصيرة. قد يعتقد فريق العمليات أن المزود سوف يحل كل شيء بعد الشراء. من الناحية العملية، لن تكون الرسالة موثوقة حتى تصف هوية المرسل وقالب المحتوى والمتغيرات وحمولة واجهة برمجة التطبيقات حالة الاستخدام نفسها.
يشرح هذا الدليل سير العمل الكامل: تسجيل الكيان الرئيسي، وتسجيل رأس المرسل، وتخطيط قالب الموافقة، وتسجيل قالب المحتوى، وتخطيط المسوق عبر الهاتف أو الموفر، وتكامل واجهة برمجة التطبيقات، واختبار الرسائل القصيرة، والتسليم. إنه مكتوب للفرق التي ترسل OTPs وتنبيهات الطلبات وتذكيرات المواعيد وإشعارات الدفع والتحديثات التشغيلية للأرقام الهندية.
ملاحظة المصدر الرسمية: تسرد إرشادات مرسل TRAI تسجيل الكيان الرئيسي، وتسجيل الرأس، وتسجيل قالب المحتوى، وتسجيل الموافقة، ومتطلبات الاتصالات المجمعة باعتبارها أنشطة من جانب المرسل. استخدم تعليمات TRAI الحالية وبوابة المشغل كمصدر نهائي للإرسالات المباشرة: نصائح TRAI للمرسلين.
تسلسل العمل
OTP وتنبيهات الخدمة
ابدأ بالأحداث الفعلية، ترويسة المرسل المعتمدة، نص قالب المحتوى، ترتيب المتغيرات وحمولة الاختبار قبل تعديل الكود.
إعداد بوابة المشغل
جهز KYC، التفويض، خيارات الترويسة، قوالب الموافقة وقوالب المحتوى قبل الإرسال عبر بوابة DLT المختارة.
تسليم المطور
حوّل PE IDs والترويسات وtemplate IDs والمتغيرات ومفاتيح API وwebhooks الخاصة بـ DLR إلى دليل تشغيل موجز يمكن صيانته بعد الإطلاق.
إجابة سريعة
يجب أن ينتهي تسجيل DLT للرسائل النصية القصيرة بالأصول المعتمدة ودليل التشغيل الجاهز للمطورين.
يجب أن يتضمن سير العمل العملي لتسجيل DLT ما يلي:
- KYC للأعمال وتفاصيل الاتصال المعتمدة لتسجيل الكيان الرئيسي.
- مرشحات الرأس أو معرف المرسل التي تتطابق مع العلامة التجارية للأعمال وفئة الرسالة.
- قوالب الموافقة حيث تتطلب حالة الاستخدام موافقة صريحة من العميل.
- قوالب المحتوى لكل نص رسالة متكررة، مع إبقاء المتغيرات ضيقة ويمكن التنبؤ بها.
- تعيين الموفر أو المسوق عبر الهاتف حتى تتمكن البوابة من الإرسال نيابة عن الكيان المسجل.
- خريطة حمولة توضح معرف PE، والرأس، ومعرف القالب، والترتيب المتغير، وإرسال العينات.
- مذكرة تسليم تسجل المالكين والبوابات الإلكترونية والمعرفات المعتمدة ونتائج الاختبار وقواعد التغيير المستقبلية.
إجابة سريعة: تسجيل DLT للرسائل النصية القصيرة
تسجيل DLT للرسائل النصية القصيرة هو عملية جعل مرسل الأعمال قابلاً للتعرف على النظام البيئي للاتصالات قبل وصول الرسائل إلى المستلمين الهنود. يمس التنفيذ عادةً ثلاثة فرق:
| فريق | ما يجب أن يعرفوه | لماذا يهم |
|---|---|---|
| صاحب العمل | الكيان القانوني، الأسماء التجارية، الشخص المرخص له، حالات الاستخدام | تحتاج بوابات المشغل إلى الهوية التجارية وتبرير المرسل. |
| العمليات أو التسويق | فئات الرسائل والموافقة والمحتوى وضوابط الحملة | يجب أن تتطابق القوالب والعناوين مع غرض الاتصال الفعلي. |
| المطور | حقول واجهة برمجة التطبيقات، ومعرفات القوالب، والمتغيرات، وتقارير التسليم، وإعادة المحاولة | تكون القوالب المعتمدة عديمة الفائدة إذا أرسل الكود حمولة مختلفة. |
الفشل الأكثر شيوعًا هو التعامل مع هذه المهام كمهام منفصلة. تتم الموافقة على الرأس، لكن القوالب تستخدم علامة تجارية مختلفة. تتم الموافقة على القالب، لكن المطور يغير الصياغة في الإنتاج. حساب الموفر نشط، ولكن معرفات PE/الرأس/القالب مفقودة من الحمولة. الإخراج الصحيح هو سير عمل متصل، وليس لقطة شاشة لشاشة بوابة واحدة معتمدة.
المرحلة الأولى: إعداد تسجيل الجهة الرئيسية
الكيان الرئيسي هو الشركة أو المؤسسة التي ترغب في إرسال اتصالات تجارية أو خدمية. قبل بدء تدفق بوابة DLT، قم بإعداد سجل الأعمال بطريقة منظمة.
قائمة مراجعة إعداد الكيان الرئيسي
- الاسم التجاري القانوني والاسم التجاري.
- PAN أو ضريبة السلع والخدمات أو التأسيس أو تسجيل المتجر أو المستندات الأخرى ذات الصلة بنوع الكيان.
- اسم الشخص المعتمد، والهاتف، والبريد الإلكتروني الذي تسيطر عليه الشركة.
- موقع الويب أو التطبيق أو المنتج أو رحلة العميل التي توضح سبب إرسال الرسائل القصيرة.
- حالات الاستخدام مفصولة حسب الفئة: OTP، تحديثات الطلب، تذكير المواعيد، إشعارات الدفع، الحملات.
- تفاصيل موفر خدمة الرسائل القصيرة أو جهة التسويق عبر الهاتف، إذا تم تحديدها بالفعل.
- مكان آمن لتخزين ملكية تسجيل الدخول إلى البوابة وملاحظات التسليم.
لا تتعجل في هذه الخطوة. إذا كانت هوية العمل أو أسماء العلامات التجارية أو تفاصيل الاتصال المعتمدة غير متسقة، يصبح من الصعب شرح كل مرحلة لاحقة. بالنسبة للشركات الصغيرة، فإن المسار الأنظف هو تحديد من سيمتلك حساب البوابة الإلكترونية بعد الإعداد وقبل بدء التسجيل.
المرحلة 2: إعداد رؤوس المرسل ومعرفات مرسل الرسائل القصيرة
رأس المرسل هو هوية المرسل المرئية المرتبطة بتدفق الرسائل القصيرة. غالبًا ما يطلق عليه الناس معرف مرسل الرسائل القصيرة. في الهند، قد يشتمل العرض النهائي على بادئات الشبكة أو التنسيق الذي يتحكم فيه المشغلون ومقدمو الخدمة، لذا يجب أن يركز الإعداد على أصول المرسل المعتمد، وليس فقط شاشة الهاتف.
يجب أن يجيب إعداد الرأس على:
- هل الرأس مرتبط بشكل واضح بالعلامة التجارية أو المنتج أو الخدمة؟
- هل يتم استخدام الرأس للمعاملات أو الخدمات أو الاتصالات الترويجية؟
- هل يمكن للشركة إثبات العلاقة بين الرأس والكيان؟
- هل تحتاج نفس الشركة إلى رؤوس متعددة لمنتجات أو عمليات سير منفصلة؟
- من الذي سيتتبع الرؤوس المعتمدة والمرفوضة والمعلقة بعد الإرسال؟
لا ينبغي أن تحتاج الرؤوس إلى شرح
إذا لم يتمكن مراجع البوابة الإلكترونية من ربط الرأس بالأعمال، فسيصبح الإرسال هشًا. احتفظ بالدليل ومراجع مواقع الويب وأسماء التطبيقات وأسماء المنتجات جاهزة.
لا تخلط بين هويات الحملة وهويات الخدمة
قد تحتاج OTPs وتنبيهات الطلبات وتذكيرات المواعيد والعروض الترويجية إلى معالجة تشغيلية مختلفة. افصل بينهما قبل التقديم.
احتفظ بسجل الرأس خارج البوابة
احتفظ بجدول بسيط بالرؤوس المطلوبة، والموافقة، والمرفوضة، والمتقاعدة. يساعد هذا عندما يسأل المطورون عن المرسل الذي يجب استخدامه.
تعامل مع تغييرات الرأس مع تغيرات الإنتاج
يؤثر معرف المرسل الذي تم تغييره على القوالب، وحمولات واجهة برمجة التطبيقات، والبرامج النصية للدعم، والتعرف على العملاء. سجل لماذا تغير.
المرحلة 3: تسجيل الموافقة وقوالب المحتوى
تحل قوالب الموافقة وقوالب المحتوى مشكلات مختلفة. يصف قالب الموافقة كيفية الحصول على الإذن عند الاقتضاء. يصف قالب المحتوى نص الرسالة المتكررة التي سيتم إرسالها.
بالنسبة لتنبيهات الخدمة وتدفقات OTP، عادةً ما يكون قالب المحتوى هو المركز التشغيلي للعمل. بالنسبة للتسويق الصريح أو الاتصالات القائمة على الموافقة، تصبح سجلات الموافقة ومعالجة التفضيلات أكثر أهمية. يجب التحقق من المسار الدقيق وفقًا لتعليمات البوابة الحالية وتوجيهات موفر خدمة الرسائل القصيرة (SMS) المحدد.
ورقة عمل تخطيط القالب
| حقل القالب | إعداد جيد | تحضير ضعيف |
|---|---|---|
| الغرض التجاري | "تسجيل الدخول لمرة واحدة للوصول إلى حساب العميل" | "الرسائل القصيرة العامة" |
| نص الرسالة | صياغة ثابتة مع متغيرات ضيقة | جملة كاملة مخفية داخل متغير واحد |
| المتغيرات | code، order_id، appointment_time | message، details، anything |
| الفئة | تم تعيين حالة استخدام المعاملة أو الخدمة أولاً | الفئة المحددة بعد كتابة الصياغة |
| دليل | تدفق موقع الويب/التطبيق، مذكرة الموافقة، حدث الطلب | لا يوجد دليل على سبب وجود الرسالة |
حافظ على انضباط المتغيرات. إذا كان القالب المعتمد يقول Your login code is [code]، فيجب ألا تحول حمولة الإنتاج هذا المتغير إلى فقرة بنسخة تسويقية. إذا كان القالب المعتمد يقول Your order [order_id] is packed، فيجب أن يكون المتغير معرف أمر أو قيمة حالة، وليس جملة تغير معنى الرسالة.
المرحلة 4: العلاقات بين مزود الخرائط والتسويق عبر الهاتف
تقوم العديد من الفرق بشراء حساب بوابة الرسائل القصيرة قبل أن تصبح أصول DLT جاهزة. هذا أمر جيد، لكن حساب الموفر ليس هو نفسه إعداد DLT الكامل. لا يزال المزود بحاجة إلى الأصول المسجلة الصحيحة لإرسال رسائل نصية قصيرة للأعمال متوافقة.
قبل التكامل، تأكد من:
- ما هو حساب المزود الذي سيرسل رسائل نصية قصيرة للإنتاج؟
- ما إذا كان الموفر يتطلب تعيين سلسلة PE-TM أو أي ربط مكافئ بين المرسل والموفر.
- أي رأس معتمد ينتمي إلى كل فئة من فئات الرسائل.
- معرف القالب الذي ينتمي إلى كل نص الرسالة.
- ما إذا كانت الروابط أو مراجع APK أو أرقام الهواتف أو عناوين URL تحتاج إلى مراجعة إضافية أو إدراج في القائمة البيضاء.
- من يمكنه فتح تذاكر الدعم في حالة فشل القالب أو المسار.
والغرض ليس إنشاء الأوراق. والغرض من ذلك هو منع المطور من اكتشاف المعرفات المفقودة أثناء بدء الإنتاج.
المرحلة 5: تعيين أصول DLT في واجهة برمجة تطبيقات الرسائل القصيرة (SMS API).
بعد الموافقة، قم بتحويل سجلات DLT إلى خريطة جاهزة للمطورين. تختلف حقول واجهة برمجة التطبيقات (API) المحددة حسب المزود، ولكن الفكرة التشغيلية متسقة: يجب أن يحدد الطلب المرسل، والقالب المعتمد، والمتغيرات، وأحيانًا الكيان الرئيسي أو سلسلة التسويق عبر الهاتف.
جمع المعرفات المعتمدة
سجل معرف PE، ورأس المرسل، ومعرف قالب المحتوى، ومعرف قالب الموافقة حيثما أمكن، ومراجع حساب الموفر.
اكتب أمثلة الحمولة
قم بإنشاء طلب نموذجي واحد لكل نوع رسالة باستخدام قيم وهمية. احتفظ بالأسرار وأرقام الهواتف الحقيقية وسجلات العملاء خارج المستند.
اختبار مع المستلمين الخاضعين للرقابة
أرسل رسائل اختبار حقيقية فقط بعد أن يصبح مسار الموفر جاهزًا. تحقق من المحتوى المستلم وعرض المرسل وحالة التسليم والسجلات.
قواعد تغيير الوثيقة
اشرح متى يتطلب تغيير القالب إعادة إرسال البوابة وتغييرات التعليمات البرمجية ومراجعة الدعم وإعادة الاختبار.
الأخطاء الشائعة في تسجيل DLT
كتابة القوالب قبل رسم الخرائط للأحداث
إذا لم تقم الشركة بفصل تسجيل الدخول لمرة واحدة (OTP)، وحالة الطلب، وتذكير الموعد، وحالات استخدام الحملة، فستصبح القوالب غامضة ويصعب الدفاع عنها.
السماح لمتغير واحد بحمل الرسالة بأكملها
المتغيرات الواسعة تجعل سلوك المراجعة والإنتاج غير قابل للتنبؤ به. حافظ على النص الثابت ثابتًا والمتغيرات ضيقة.
تخطي التسليم
يجب أن تعرف الشركة من يملك حساب البوابة الإلكترونية، والمعرفات التي تمت الموافقة عليها، والموفر الذي تم تعيينه، وما المطورين الذين لا ينبغي تغييرهم.
التعامل مع الموافقة على أنها أمان دائم
تحتاج سجلات DLT إلى رعاية مستمرة. يجب مراجعة المحتوى الجديد والروابط الجديدة وتدفقات الحملة الجديدة وتغييرات الموفر قبل استخدام الإنتاج.
ما يعالج شينكا
تساعد Shinka Systems الفرق على تحويل تسجيل DLT من مهمة بوابة مربكة إلى عملية تسليم للتنفيذ. يمكن أن يتضمن العمل إعداد المستندات، وتخطيط الرأس، وتنظيف القالب، وملاحظات تنسيق الموفر، وتعيين حمولة واجهة برمجة التطبيقات (API)، واختبار التحقق من الرسائل القصيرة، ودليل التشغيل النهائي.
لا يحل العمل محل بوابة المشغل أو مزود الاتصالات أو المشورة القانونية. موافقات مراقبة المشغلين والأنظمة التنظيمية. تكمن القيمة في إعداد مدخلات أنظف، وتقليل التنقل ذهابًا وإيابًا، والتأكد من أن الأصول المعتمدة قابلة للاستخدام من قبل فريق التطبيق.
الأسئلة الشائعة
هل أحتاج إلى تسجيل DLT إذا أرسلت رسالة نصية قصيرة لمرة واحدة (OTP) فقط؟
بالنسبة للرسائل النصية القصيرة للأعمال إلى أرقام هندية، لا تزال رسائل OTP ورسائل الخدمة بحاجة إلى المرسل المسجل الصحيح وأصول القالب. تعامل مع OTP كتدفق لاتصالات الإنتاج، وليس كتجاوز.
هل يجب علي التسجيل في Jio أو Airtel أو بوابة DLT أخرى؟
تعتمد نقطة البداية الصحيحة على مزود الخدمة الخاص بك وحالة الكيان الحالي وتعليمات المشغل. الإخراج المهم هو إعداد مرسل كامل يمكن لبوابة الرسائل القصيرة الخاصة بك استخدامه.
هل يمكن لقالب محتوى واحد أن يغطي العديد من الرسائل المختلفة؟
عادة ما يخلق ذلك المخاطر. استخدم قوالب منفصلة لأحداث منفصلة، خاصة عندما تتغير الصياغة أو القصد أو المتغيرات أو أساس الموافقة.
هل تستطيع Shinka ضمان موافقة DLT؟
لا. قرارات الموافقة تقع على عاتق عمليات البوابة والمشغل. يمكن لـ Shinka المساعدة في إعداد الوثائق الأنظف وعينات الرسائل والقوالب وملاحظات تسليم المطورين.
