ماذا تغير واجهة واتساب للأعمال في متجر جزائري؟

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

ما هذه الواجهة بلا لغة تسويقية؟

تطبيق واتساب للأعمال هاتف واحد وخلفه إنسان. أما رقم مسجل على منصة ميتا فيتصرف كطرف يمكن مخاطبته برمجيا: الرسائل الواردة تصل إلى خادمك كإشعارات، والردود تخرج كطلبات إلى الواجهة، والاتجاهان قابلان للبرمجة. تستضيف ميتا هذا باسم Cloud API، والنسخة القديمة التي تعمل على خادمك تخرج من الخدمة، فخطط على المسار المستضاف.

الفرق العملي ليس «الأتمتة»، بل أن المحادثة تصير مدخلا لشيء آخر: طلب، أو سجل عميل، أو حالة توصيل، بدل أن تنتهي في ذاكرة شخص.

ما الإعدادات الثلاثة الموجودة فعلا؟

كلها حقيقية ولا واحد منها خطأ. الذي يتغير هو من يجيب، ومن يصون الشيء، وأين تعيش البيانات.

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

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

لماذا يكون الرقم أول قرار؟

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

هذا قرار يتخذ قبل ضبط أي شيء، لأنه يغير ما يراه العميل. متجر يبدأ فجأة بالرد من رقم جديد يبدو كمتجر تغير مالكه.

ما القوالب والنافذة التي لا يمكن عبورها؟

الرد الحر مسموح داخل نافذة خدمة تفتح حين يراسلك العميل. خارجها ترسل قالبا وافقت عليه ميتا سلفا. القوالب تمر بمراجعة، والنص التسويقي الغامض يعود مرفوضا عادة، أما الرسالة التنفيذية الواضحة فتمر.

النتيجة عملية: الرسائل التي تستحق الكتابة هي الأربع التي يرسلها المتجر كل يوم.

1. استلام الطلب: رقمه وأصنافه وإجماليه وسعر التوصيل.
2. الخروج: اسم الناقل ورقم التتبع إن وفره واليوم المتوقع.
3. في الطريق، أو في الوكالة للاستلام.
4. الوصول أو الرفض، وما يترتب عليه.

اكتب هذه الأربع قبل كتابة أي كود. وإذا لم تستطع جعلها دقيقة، فسجل الطلب خلفها غير جاهز، والواجهة تجعل عدم الدقة أسرع فقط.

لماذا يربط الطلب بالمحادثة لا العكس؟

العطل الشائع أتمتة ملتصقة برقم هاتف. يكتب العميل «أين طلبي» فيصل رد لطيف لا يحمل معلومة، لأنه لا شيء خلف الرقم سوى مجيب آلي.

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

ما الذي يستحق الأتمتة أولا؟

1. الإقرار: يكتب العميل، فينشأ طلب، وتعود التفاصيل للتأكيد. هذا يزيل قلق «هل رأوا رسالتي» الذي ينتج ثلاث رسائل متابعة لكل طلب.
2. إشعار الخروج: يجيب عن «أين طلبي» قبل أن يسأل، ولهذا هو الثاني.
3. جواب الحالة: حين يصل السؤال، يأتي الجواب من السجل لا من لوحة المفاتيح.
4. متابعة الرفض: طرد مرفوض يستقبل قالبا بشروط الإعادة، بدل جدال.
5. الرسائل الجماعية، أخيرا، وللعملاء الذين طلبوها فقط.

الرسائل الجماعية هي ما يريده الجميع أولا، وهي أسرع ما يضر الرقم. قائمة تصلها عروض مرتين في الأسبوع ولا يصلها تحديث مفيد هي قائمة تكتم المتجر.

أين يذهب هذا الربط خطأ؟

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

إلى أين يقف هذا الكلام؟

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

وإذا لم يكن عندك من يصون خادما فلا تبدأ بـ Cloud API؛ استخدم منصة مستضافة حتى يبرر الحجم غيرها. وإذا توقف التوثيق التجاري عند مشكلة في وثيقة، فأصلح الوثيقة: لا كود يتجاوز سجلا تجاريا مرفوضا.

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