ربط واتساب API بشركتك: وش تجهّز قبل البداية؟

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

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

الخلاصة أولاً

• تطبيق واتساب للأعمال تطبيق تفتحه وترد منه. المنصة (API) ما لها تطبيق ولا واجهة؛ هي قناة برمجية تحتاج نظاماً يستقبل منها ويرسل إليها.
• الرقم الواحد يشتغل على التطبيق أو على المنصة، مو على الاثنين. والنقل إلى المنصة يعني فقدان أرشيف المحادثات القديمة على الجهاز.
• على المنصة، الرد الحر مسموح داخل نافذة 24 ساعة من آخر رسالة للعميل. خارجها ما ترسل إلا قالباً معتمداً مسبقاً.
• تبدأ بحد 250 عميلاً فريداً كل 24 ساعة، ويرتفع بعد توثيق المنشأة وحسن الاستخدام إلى 1,000 ثم 10,000 ثم 100,000.
• نصف المشروع إرسال، والنصف الثاني استقبال عبر Webhook وحفظ وربط بالطلب. الربط اللي يرسل فقط ما هو ربط.

التطبيق والمنصة: وش الفرق فعلاً؟

كثير من أصحاب المتاجر يسمعون "واتساب للأعمال" ويفترضون أنه شيء واحد. هما منتجان مختلفان تماماً في طريقة العمل والتكلفة والقيود.

تطبيق واتساب للأعمال تنزّله على جوال، فيه صندوق وارد جاهز، وردود سريعة، ووسوم، وكتالوج منتجات، وحالة (ستوري)، وقوائم بث. مجاني. ويشتغل على الجوال الأساسي مع عدد محدود من الأجهزة المرتبطة (أربعة).

• تفعيل خلال دقائق، بدون مطوّر ولا خادم ولا عقود.
• ما فيه تكلفة لكل رسالة، ولا موافقة مسبقة على نص الرسائل.
• ما يتكامل مع نظام الطلبات أو الـCRM. كل ربط يحتاج نسخاً يدوياً.
• توزيع المحادثات على الفريق غير موجود. الجميع يشوف الكل، وما فيه "هذي المحادثة لفلان".
• لا سجل تدقيق ولا صلاحيات. موظف يمسح محادثة، وما عندك طريقة تعرف.

منصة واتساب للأعمال (API) ما لها تطبيق ولا شاشة. هي نقطة اتصال برمجية: نظامك يرسل طلباً فتُرسل الرسالة، وواتساب يرسل لك الأحداث على خادمك. الواجهة التي يشتغل عليها الموظفون تختارها من السوق أو تبنيها ضمن المشروع.

• عدد غير محدود من المستخدمين على نفس الرقم، مع صلاحيات وسجل لمن رد ومتى.
• تكامل حقيقي: رقم الطلب، حالة الشحن، تذكير الموعد، فاتورة — كلها تطلع من نظامك تلقائياً.
• أتمتة وتوجيه: محادثة الدعم لفريق، والمبيعات لفريق آخر، حسب كلمة أو مصدر الرسالة.
• مدفوعة. التسعير اليوم مبني على الرسائل القالبية وفئتها (تسويقي، خدمي، مصادقة)، ويختلف من دولة لدولة. راجع الأسعار السارية وقت التنفيذ لأن ميتا تحدّثها.
• ميزات التطبيق المألوفة غير متاحة: لا حالة، ولا قوائم بث بنفس الشكل، ولا مجموعات.
• كل رسالة ترسلها خارج نافذة الـ24 ساعة تحتاج قالباً تمت الموافقة عليه مسبقاً. ما تقدر ترتجل نصاً.

الفرق العملي بجملة: التطبيق يحل مشكلة الرد. المنصة تحل مشكلة التشغيل — من يرد، وعلى أي طلب، وبأي بيانات، وبأي أثر مسجّل.

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

متى تحتاج API فعلاً؟

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

علامات واضحة أن التطبيق ما عاد يكفيك:

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

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

نافذة الـ24 ساعة والقوالب: هنا يختلف كل شيء

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

القالب نص ثابت فيه متغيرات ({{1}} للاسم، {{2}} لرقم الطلب)، ترفعه وينتظر المراجعة. الموافقة غالباً تجي خلال دقائق، وقد تمتد إلى 24 ساعة. والرفض وارد: نص غامض، أو أخطاء إملائية، أو تصنيف خاطئ (ترسل عرضاً تسويقياً وتصنّفه خدمياً).

حالات حافة تستحق الانتباه:

• تأخر العميل في الرد: يكتب الساعة 11 مساءً، وتردون الساعة 2 ظهراً اليوم التالي — داخل النافذة. لكن لو رد بعد يومين، تحتاج قالباً، والقالب له تكلفة.
• تغيير نص قالب معتمد يعني مراجعة جديدة. لا تربط حملة بتاريخ محدد وأنت ما رفعت القالب إلا في نفس اليوم.
• جودة الحساب: كل رقم له تقييم جودة (أخضر/أصفر/أحمر) يتأثر بحظر العملاء لك وتجاهلهم رسائلك. الهبوط المتكرر يخفّض حدك اليومي أو يوقف قوالب فئة كاملة.
• الحد يبدأ عند 250 عميلاً فريداً في 24 ساعة، ويرتفع إلى 1,000 بعد توثيق المنشأة، ثم 10,000 و100,000 مع حجم مستقر وجودة جيدة. إذا كنت مخططاً لحملة على قاعدة عملاء كبيرة، تدرّج قبلها بأسابيع.
• الرسائل القادمة من إعلانات "انقر للمراسلة" لها معاملة خاصة في التسعير والنافذة. تحقق من تفاصيلها السارية قبل ما تبني ميزانيتك عليها.

الحساب والرقم يكونان باسم المنشأة

• حدّد من يملك حساب الأعمال والرقم وحقوق الإدارة.
• احفظ الوصول في حسابات المنشأة، ولا تتركه محصوراً عند المطوّر.
• راجع وضع الرقم الحالي وطريقة ضمه أو نقله حسب المسار المتاح لحسابك، قبل أي تغيير عليه.
• فرّق بين تجربة برقم اختبار وبين إطلاق الخدمة على رقم العملاء الحقيقي.
• رمز التحقق بخطوتين: تسجيل الرقم على المنصة يحتاج رمز PIN من ستة أرقام. احفظه عند المنشأة، لأن فقدانه يعطّل إعادة التسجيل لاحقاً.
• الاسم الظاهر للعميل يمر على مراجعة، ويفضّل أن يطابق اسم نشاطك التجاري. الأسماء العامة أو العبارات الترويجية تُرفض.
• التوثيق التجاري يحتاج مستندات المنشأة (سجل تجاري، عنوان، وسيلة تواصل) مطابقة لما هو مسجّل. أي اختلاف بسيط يرجّع الطلب.

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

وانتبه لرقم موظف المبيعات الشخصي. لو العملاء اعتادوا عليه، نقله إلى المنصة يقطع عادة قائمة، وبقاؤه خارجها يعني أن جزءاً من مبيعاتك باقٍ خارج النظام. قرّر من البداية أي الرقمين هو الرسمي.

الإرسال نصف الربط فقط

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

تفاصيل تقنية تفرق فعلاً في التشغيل:

• نقطة الاستقبال لازم تكون HTTPS بشهادة سارية، وترد بنجاح خلال ثوانٍ. البطء يعني إعادة إرسال الحدث عليك مرة أخرى.
• منع التكرار: خزّن معرّف الرسالة الفريد واستخدمه مفتاحاً. بدونه، إعادة التسليم تنشئ طلبين لنفس العميل.
• روابط الوسائط مؤقتة وتنتهي خلال دقائق معدودة. نزّل الصورة أو الملف فوراً واحفظه عندك، لا تخزّن الرابط.
• حالات الرسالة أربع: مُرسلة، سُلّمت، قُرئت، فشلت. اربطها بالطلب وإلا ما عرفت أن تذكير الموعد ما وصل أصلاً.
• الرموز المؤقتة: رمز الوصول التجريبي ينتهي خلال 24 ساعة. الإطلاق يحتاج رمز مستخدم نظام دائم باسم المنشأة.
• فيه سقف لعدد الرسائل في الثانية. الحملة الكبيرة تحتاج طابوراً يوزّع الإرسال، لا حلقة ترسل كل شيء دفعة واحدة.

اسأل عن حماية هذا المسار، وعن منع معالجة الحدث مرتين لو أُعيد تسليمه. وإذا تعطل نظام المتابعة، وين تبقى الرسالة؟ الربط الجيد يحتفظ بالطلب ويبين الخطأ للمسؤول، بدلاً من إخفائه خلف رد ناجح للعميل.

قبل الإطلاق، جرّب رحلة كاملة

1. عميل جديد يرسل سؤالاً ويتلقى جواباً مناسباً.
2. موظف يستلم المحادثة ويعرف ما قيل قبل وصولها إليه.
3. طلب يتسجل مرة واحدة، حتى مع تكرار الحدث أو الضغط.
4. تعطل مؤقت في النظام يظهر في سجل يمكن متابعته.
5. صلاحية موظف تُلغى بدون تعطيل عمل بقية الفريق.
6. عميل يرد بعد ثلاثة أيام: هل يفتح النظام محادثة بقالب صحيح، ولا يحاول إرسال نص حر ويفشل بصمت؟
7. عميل يرسل صورة ثم ملف PDF: هل حُفظا عندك وارتبطا بنفس الطلب؟
8. رسالة تفشل (رقم خاطئ أو جهاز بلا واتساب): هل يظهر الفشل لموظف مسؤول خلال وقت معقول؟

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

اتفق على مسؤولية التشغيل

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

حدّد مسؤولاً بالاسم عن: تقييم جودة الرقم، وانتهاء الرموز والشهادات، ورفض القوالب الجديدة، وتجديد مستندات التوثيق. وضع حداً واضحاً: كم رسالة فاشلة في اليوم تُعتبر مشكلة تستدعي اتصالاً، لا مجرد سطر في سجل ما أحد يقرأه.

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

1. اكتب عدد من يرد على العملاء اليوم، وعدد المحادثات اليومية تقريباً. هذا يحسم لك: تطبيق أم منصة.
2. قرّر الرقم: جديد، أم نقل رقم قائم مع قبول فقدان أرشيفه.
3. جهّز مستندات المنشأة وابدأ التوثيق مبكراً، لأنه يرفع حدك اليومي من 250 إلى 1,000.
4. اختر مساراً واحداً فقط للمرحلة الأولى — طلب عرض سعر مثلاً — واكتب خطواته من أول رسالة إلى إغلاق الطلب.
5. ارفع القوالب التي يحتاجها هذا المسار، وانتظر اعتمادها قبل تحديد موعد الإطلاق.
6. شغّل أسبوع تجربة على فريق مصغّر، وراجع الرسائل الفاشلة والطلبات المكررة قبل التوسع.

ابدأ بمسار واحد، مثل طلب عرض سعر، ثم وسّع الربط بعد ما تثبت فائدته. وللتفاصيل التي تجعل التكامل قابلاً للصيانة، راجع دليل ربط أنظمة الشركة عبر API. وإذا تحتاج تحدد نطاق مشروعك، راسلنا بوصف رحلة العميل الحالية ونراجع أين يضيف الربط قيمة فعلية.