CRM لخدمة التوصيل

لماذا لا يكفي الـ CRM وحده لخدمة التوصيل

صُمِّم الـ CRM للمبيعات: بطاقة العميل، ومسار الصفقات، والصفقات نفسها، ومهام المسؤولين، وسجل المراسلات. وفي هذا يؤدي AmoCRM وBitrix24 عملهما جيداً. لكن العمل الأساسي لخدمة التوصيل يبدأ بعد الفوز بالصفقة — وهنا يصطدم الـ CRM التقليدي بحدوده سريعاً.

• لا خريطة ولا مسارات. لا يرى الـ CRM أين يوجد المندوب، ولا يستطيع ترتيب العناوين مع مراعاة نوافذ التسليم.
• لا شاشة عمل للمنفّذ. يحتاج المندوب إلى شاشة بسيطة تقول له «إلى أين تذهب، وماذا تحمل، وكيف تسجّل النتيجة»، لا إلى واجهة مسؤول مبيعات.
• لا تأكيد في الموقع. الصور وقائمة التحقق وعلامة التسليم — كلها تُجمَع في تطبيقات المراسلة ثم تُنقَل يدوياً.
• الحالات عامة جداً. مرحلة «سُلِّم للتوصيل» في مسار الصفقات لا تُظهر إن كان الطلب في الطريق، أو عند الباب، أو عائداً إلى المستودع.

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

كيف توزّع الأدوار بين الـ CRM ونظام التوصيل

القاعدة الذهبية لربط الـ CRM بالتوصيل: لكل كيان مالك واحد. فإذا أمكن تعديل الحقل نفسه في مكانين، ستتباعد البيانات عاجلاً أم آجلاً.

• الـ CRM يملك العميل والصفقة: جهات الاتصال، والبيانات الرسمية، ومحتوى الطلب، والمبلغ، واتفاقات المسؤول.
• نظام إدارة المندوبين يملك التنفيذ: لمن أُسنِد الطلب، وبأي ترتيب يتنقّل المندوب، والوقت الفعلي، والتقرير المصوّر، وتأكيد الإنجاز.
• 1C أو نظام المحاسبة الآخر يملك الأموال والمخزون: المستندات، والمدفوعات، وحركة المستودع.

بهذا التقسيم يواصل المسؤول العمل في الـ CRM المعتاد، ويعمل المنسّق على خريطة تضم الطلبات والمسارات، ويعمل المندوب من واجهة ويب للجوال دون الحاجة إلى تثبيت تطبيق. كلٌّ يرى ما يخصّه، لكن البيانات لا تتكرر: يُنشأ الطلب مرة واحدة، ثم تتغير حالته فقط.

ويجدر أن تحدد أيضاً من يرى سير التوصيل من الخارج. فالعميل يفضّل متابعة الحالة في حساب العميل الشخصي بدل الاتصال بالمسؤول — وهذا يخفّف الضغط عن قسم المبيعات وعن غرفة التنسيق معاً.

تبادل الطلبات مع الـ CRM: ماذا يُنقَل ومتى

من الأسهل تصميم تبادل الطلبات مع الـ CRM على أنه تدفّقان: الطلب يذهب من الـ CRM إلى التوصيل، والنتيجة تعود في الاتجاه المعاكس.

من الـ CRM إلى نظام التوصيل يُنقَل ما لا يستطيع المندوب تنفيذ الطلب بدونه:

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

من نظام التوصيل إلى الـ CRM يعود ما يحتاجه المسؤول والعميل:

• تغيّر الحالة: أُسنِد، في الطريق، سُلِّم، لم يُسلَّم؛
• سبب الرفض أو التأجيل؛
• الوقت الفعلي للتنفيذ ورابط التقرير المصوّر أو التأكيد.

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

كيف تختار الحل: قائمة تحقق لخدمة التوصيل

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

• ربط جاهز مع الـ CRM لديك. هل يوجد تكامل جاهز مع AmoCRM أو Bitrix24، أم ستضطر إلى كتابة التبادل من الصفر.
• العمل مع المحاسبة. إن كانت الأموال والمستندات في 1C، فأنت بحاجة إلى ربطها أيضاً — وإلا ستبقى المطابقة يدوية.
• التوزيع والمسارات. هل يقترح النظام ترتيباً للعناوين يراعي نوافذ التسليم والقيود، أم يكتفي بعرض النقاط على الخريطة.
• شاشة المنفّذ. هل يستطيع المندوب بدء العمل من هاتفه في اليوم الأول، وهل تتوفر التقارير المصوّرة وقوائم التحقق.
• الحالات العائدة. هل يرى المسؤول نتيجة التوصيل في بطاقة الصفقة دون الاتصال بالمندوب.
• التصدير. هل يمكن سحب البيانات إلى Excel للمراجعات والتقارير.
• مدة الإطلاق. كم من الوقت يلزم حتى أول وردية عمل فعلية، وهل يُشترط عقد طويل الأجل.

على هذه المتطلبات بُني itlogist: استقبال الطلبات وتوزيعها، ومسارات على الخريطة في الوقت الفعلي، وتحسين المسارات بمحرك OR-Tools مع مراعاة نوافذ التسليم، وواجهة جوال للمنفّذ، وتكاملات مع 1C وAmoCRM وBitrix24 وExcel. التفاصيل في قسم إمكانات itlogist.

التطبيق دون إيقاف العمل

الأفضل إطلاق ربط الـ CRM بالتوصيل على مراحل، كي تواصل الخدمة توصيل الطلبات بينما يُضبط التبادل.

• الخطوة 1. تدفّق واحد. اختر نوعاً واحداً من الطلبات أو منطقة واحدة، واضبط نقل الطلبات من الـ CRM. يعمل مندوبو هذه المجموعة في النظام الجديد منذ البداية.
• الخطوة 2. الحالات العائدة. حين تصل الطلبات بانتظام، فعّل إعادة الحالات وأسباب الرفض إلى الـ CRM. وتحقّق من أن المسؤولين توقّفوا عن الاتصال بالمنسّق للاستفسار.
• الخطوة 3. المسارات والنوافذ. فعّل تحسين المسارات وقارن الخطة بالطريقة التي كان المنسّق يوزّع بها الطلبات يدوياً.
• الخطوة 4. التوسّع. انقل بقية أنواع الطلبات والمناطق، وأضف حساباً شخصياً للعملاء.

الأخطاء الشائعة في هذا الطريق: إدخال الطلب يدوياً في النظامين «احتياطاً»، وعدم تحديد مفتاح المطابقة (فتظهر النسخ المكررة)، والسماح بتعديل العنوان في الـ CRM بعد إرسال الطلب إلى التوصيل. يُستحسن تثبيت هذه القواعد كتابياً قبل الإطلاق. صُمِّم itlogist لفرق تضم من 5 إلى 100 منفّذ، ويُطلَق خلال 7 أيام دون عقود طويلة الأجل — وتظهر النتائج الأولى منذ التدفّق التجريبي.