- ابدأ بجرد نماذج الموقع وتحديد مصير كل نموذج: ليس كل نموذج يُنشئ عميلًا محتملًا. طلب الدعم تذكرة، وطلب التوظيف خارج CRM أصلًا.
- صمّم النموذج لخدمة التوجيه: كل حقل ظاهر يجب أن يُستخدم في التوزيع أو التأهيل، والحقول المخفية تلتقط المصدر ومعرّفات الحملة والصفحة دون أن يراها الزائر.
- اختر طريقة الربط حسب قدرة فريقك التقني وحاجتك للتحكم: نموذج يوفره CRM، أو نموذج موقعك يرسل من الخادم عبر واجهة API أو Webhook. تجنب الاعتماد على البريد كوسيط.
- الطلب لا يصل «للشخص الصحيح» إلا بترتيب واضح: مطابقة مع السجلات القائمة أولًا، ثم نوع الطلب، ثم المنطقة أو المنتج، ثم التوزيع داخل الفريق، مع إشعار للمندوب والعميل ومؤقت للرد.
هذه المقالة لفريقي التسويق وتقنية المعلومات عند ربط نماذج الموقع بنظام CRM. تغطي تصميم النموذج وحقوله المخفية والموافقة، وطرق الربط ومتى تناسب كل طريقة، وقواعد التوجيه بعد وصول الطلب، ومنع الرسائل المزعجة دون خسارة طلبات حقيقية، وما يصل العميل بعد الإرسال، ثم قائمة اختبار ومراقبة بعد الإطلاق.
جرد النماذج: ماذا يصبح كل طلب داخل النظام؟
في أغلب المواقع أكثر من نموذج: «اطلب عرض سعر»، و«احجز عرضًا توضيحيًا»، و«تواصل معنا»، وربما «طلب دعم» و«انضم إلينا» و«سجّل كمورد». إذا رُبطت كلها بطريقة واحدة، امتلأت قائمة العملاء المحتملين بطلبات توظيف وشكاوى، وتشوهت تقارير المصادر. لذلك قبل أي ربط، جهّز جدولًا بثلاثة أعمدة لكل نموذج:
| النموذج | ماذا يُنشئ في CRM | من يعالجه |
|---|---|---|
| اطلب عرض سعر | عميل محتمل بأولوية عالية، أو يُربط بالعميل القائم | فريق المبيعات حسب المنطقة أو المنتج |
| احجز عرضًا توضيحيًا | عميل محتمل مع موعد مقترح | المبيعات، أو فريق ما قبل البيع |
| تواصل معنا | يُصنف حسب «نوع الطلب» الذي يختاره الزائر، ثم يتفرع | حسب النوع |
| طلب دعم | تذكرة خدمة مرتبطة بالعميل، لا عميلًا محتملًا | خدمة العملاء |
| تحميل دليل أو نشرة | عميل محتمل بحالة «جديد» دون إسناد فوري، يدخل رحلة رعاية | التسويق |
| التوظيف والموردون | لا يدخل مسار العملاء؛ يُحوَّل إلى البريد أو النظام المختص | الموارد البشرية أو المشتريات |
النموذج العام «تواصل معنا» هو أكثر ما يسبب الفوضى. الحل البسيط أن يحتوي قائمة «نوع الطلب» إلزامية بخيارات محدودة (استفسار عن خدمة، طلب سعر، دعم فني، شراكة، أخرى)، لأن هذا الحقل وحده يحدد نصف قواعد التوجيه. والتمييز بين الاستفسار البيعي وغيره بعد وصوله موضوع مستقل تشرحه مقالة التمييز بين الاستفسار العام والفرصة.
تصميم النموذج: حقول ظاهرة قليلة وحقول مخفية كثيرة
كل حقل ظاهر يقلل عدد من يكملون النموذج، وكل حقل ناقص يؤخر التوجيه أو التأهيل. القاعدة العملية: لا تضع حقلًا ظاهرًا إلا إذا كان سيُستخدم في قاعدة توزيع أو في قرار التأهيل الأول. ما عدا ذلك يسأل عنه المندوب في المكالمة.
| الحقل | ظاهر أم مخفي | لماذا | ملاحظة التصميم |
|---|---|---|---|
| الاسم والجهة | ظاهر | التعريف، والمطابقة مع العملاء القائمين | حقل الجهة اختياري في نماذج الأفراد |
| الجوال | ظاهر | التواصل، ومنع التكرار | تحقق من الصيغة السعودية (05 متبوعًا بثمانية أرقام، أو بالمفتاح الدولي) وحوّلها إلى صيغة موحدة قبل الحفظ |
| البريد | ظاهر | التواصل، والمطابقة بنطاق الجهة | تحقق من الصيغة فقط، لا تمنع البريد الشخصي في النماذج العامة |
| المدينة | ظاهر بقائمة | التوزيع حسب المنطقة | قائمة منسدلة لا نص حر، حتى لا تصل «الرياض» بخمس صيغ |
| نوع الطلب أو المنتج | ظاهر بقائمة | التوزيع حسب الفريق | خيارات محدودة يفهمها الزائر، لا أسماء الأقسام الداخلية |
| معرّفات الحملة (UTM) | مخفي | المصدر والقناة والحملة والمحتوى | تُقرأ من رابط الزيارة الأولى وتُحفظ طوال الجلسة، لا من صفحة النموذج فقط |
| صفحة الإرسال والصفحة المُحيلة | مخفي | أي صفحة أنتجت الطلب، ومن أين جاء الزائر | تُلتقط تلقائيًا |
| معرّف النموذج ولغة الصفحة | مخفي | التمييز بين نماذج متشابهة، وإسناد الطلب لمن يتحدث لغة العميل | ثابت لكل نموذج |
أكثر خطأ يُضيع المصدر أن تُقرأ معرّفات الحملة من صفحة النموذج نفسها. الزائر يصل غالبًا من إعلان إلى صفحة خدمة، ثم يتنقل بين صفحتين أو ثلاث، ثم يصل إلى النموذج، فتكون المعرّفات قد اختفت من الرابط. الحل أن يحفظ الموقع قيم الزيارة الأولى عند الوصول، ويضعها في الحقول المخفية عند الإرسال. أما هيكل المصدر نفسه (القناة والحملة والتفاصيل) وقاعدة عدم الكتابة فوقه فتفصيلهما في دليل تتبع مصدر العميل في CRM.
الموافقة داخل النموذج
أضف خيارًا منفصلًا غير محدد مسبقًا للموافقة على الرسائل التسويقية، منفصلًا عن الموافقة على التواصل بخصوص الطلب نفسه. من طلب عرض سعر ينتظر أن تتصل به بخصوص طلبه، لكنه لم يوافق بالضرورة على النشرات. ويُحفظ مع الموافقة في CRM نص الخيار كما ظهر، وتاريخ الإرسال، والنموذج، حتى يمكن إثباتها لاحقًا. وضع رابطًا لسياسة الخصوصية بجانب زر الإرسال. طريقة حفظ الموافقات وتطبيقها على كل إرسال مشروحة في مقالة إدارة تفضيلات التواصل والموافقات.
طرق الربط: أيها يناسب موقعك؟
توجد أربع طرق شائعة لإيصال بيانات النموذج إلى CRM. لا توجد طريقة صحيحة لكل موقع، والمقارنة التالية تساعد على الاختيار:
| الطريقة | كيف تعمل | متى تناسب | ما تنتبه له |
|---|---|---|---|
| نموذج يوفره CRM ويُضمَّن في الموقع | يُبنى النموذج في CRM ويُضاف إلى الصفحة بشيفرة تضمين | فريق تقني محدود، أو حاجة لإطلاق سريع | التحكم في التصميم أقل، وتأكد أن النموذج يظهر بالعربية واتجاهها ويلتقط معرّفات الحملة |
| نموذج الموقع يرسل من الخادم عبر API | الموقع يستقبل النموذج ثم يرسل البيانات من خادمه إلى واجهة CRM | موقع مبني بفريق تقني، وحاجة لتحكم كامل في التصميم والتحقق | أفضل تحكم، لكن يحتاج معالجة للفشل وإعادة المحاولة على جانب الموقع |
| إضافة نماذج ترسل Webhook | إضافة النماذج في نظام إدارة المحتوى ترسل إشعارًا فوريًا بالبيانات إلى عنوان يستقبله CRM | مواقع ووردبرس ونحوها بإضافات نماذج شائعة | تحقق من أن الإضافة تعيد المحاولة عند الفشل وتحتفظ بنسخة من الإرسال |
| البريد كوسيط | النموذج يرسل بريدًا، ويُحلل CRM البريد لاستخراج الحقول | حل مؤقت فقط لموقع قديم لا يمكن تعديله | هش: تغيير صغير في صيغة البريد يكسر التحليل، والحقول المخفية تضيع غالبًا |
تنبيه أمني: لا تضع مفتاح واجهة CRM في شيفرة تعمل في متصفح الزائر. أي مفتاح يظهر في الصفحة يمكن نسخه واستخدامه للكتابة في نظامك. الإرسال بالمفتاح يكون من خادم الموقع، أو عبر نموذج يوفره CRM نفسه، وبمفتاح صلاحيته محصورة في إنشاء العملاء المحتملين فقط.
وأيًا كانت الطريقة، اطلب ثلاثة أمور: سجلًا لكل إرسال يوضح إن وصل ونجح أو فشل ولماذا، وإعادة محاولة تلقائية عند انقطاع مؤقت، ومنع إنشاء سجلين إذا ضغط الزائر زر الإرسال مرتين. هذه البنود تُكتب في بطاقة التكامل قبل التنفيذ كما في طريقة تصميم كل تكامل. أما نماذج الإعلانات داخل منصات التواصل الاجتماعي فلها مسار ربط مختلف يشرحه دليل ربط نماذج الإعلانات بـCRM.
التوجيه: كيف يصل الطلب إلى من يعالجه؟
بمجرد وصول البيانات يبدأ العمل الأهم: تحديد من يتولى الطلب. الترتيب هنا مهم، لأن القاعدة الأولى التي تنطبق هي التي تحسم:
- الإرسال والتحققصيغة الجوال والبريد، والحقول الإلزامية، وفحوص الرسائل المزعجةالموقع وCRM
- المطابقة مع السجلات القائمةهل هو عميل حالي، أو عميل محتمل مفتوح، أو له فرصة جارية؟ إن نعم يُربط الطلب بالسجل ويُنبَّه مسؤولهCRM آليًا
- إنشاء السجل بمصدرهعميل محتمل أو تذكرة حسب النموذج، مع معرّفات الحملة والصفحة والموافقاتCRM آليًا
- تحديد الفريقحسب نوع الطلب أولًا، ثم المنطقة أو المنتج أو حجم الجهةقواعد التوزيع
- الإسناد داخل الفريقبالتناوب أو حسب الحمل، مع استبعاد الغائبينقواعد التوزيع
- الإشعار والمؤقتتنبيه للمندوب برابط السجل، ورد تلقائي للعميل، ومهمة تواصل بموعدالمندوب
تفاصيل تستحق الاتفاق عليها قبل الإطلاق:
- العميل الحالي يذهب لمسؤوله: إذا طابق الجوال أو البريد عميلًا قائمًا، يُسند الطلب لمسؤول حسابه، حتى لو كانت قاعدة المنطقة تقول غير ذلك.
- الطلبات خارج الدوام: تُسند فورًا لكن يبدأ مؤقت الرد مع بداية يوم العمل التالي، ويُبلَّغ العميل بذلك في الرد التلقائي.
- عند غياب البيانات: إذا لم يختر الزائر المدينة أو كانت «أخرى»، يذهب الطلب إلى قائمة فرز لدى مشرف، لا إلى فريق عشوائي.
- الأولوية: طلب عرض السعر أو الموعد يحمل أولوية أعلى ومهلة رد أقصر من استفسار عام.
ترتيب قواعد التوزيع وأولوياتها والبدائل عند الغياب موضوع مفصل في دليل توزيع العملاء تلقائيًا. ما يهم في سياق النماذج أن تحمل البيانات القادمة من الموقع ما تحتاجه تلك القواعد، وإلا تعطلت.
منع الرسائل المزعجة دون خسارة طلبات حقيقية
أي نموذج عام على الإنترنت سيتلقى إرسالات آلية. إذا دخلت كلها إلى CRM، فسيتعلم المندوبون تجاهل الطلبات الجديدة، وهذا أخطر من الرسائل المزعجة نفسها. وإذا شددت الفلترة كثيرًا، فستحجب طلبات حقيقية دون أن تعرف. الحل طبقات متعددة خفيفة بدل عقبة واحدة ثقيلة:
- حقل مصيدة مخفي
حقل لا يراه الإنسان ولا يعبئه، وتعبئه البرامج الآلية غالبًا. الإرسال الذي يملؤه يُعزل.
الموقع - زمن التعبئة
الإرسال الذي يتم بعد ثانية أو ثانيتين من تحميل الصفحة ليس من إنسان في الغالب.
الموقع - حد التكرار
عدد محدود من الإرسالات من المصدر نفسه خلال فترة قصيرة.
الموقع أو الخادم - تحقق غير مرئي من الإنسان
أدوات التحقق التي تعمل في الخلفية وتظهر اختبارًا فقط عند الاشتباه، بدل اختبار ظاهر لكل زائر.
الموقع - التحقق من المحتوى في CRM
أرقام جوال بصيغة غير صالحة، أو نص يحتوي روابط كثيرة، أو كلمات إعلانية معروفة. هذه تُعطى حالة «للمراجعة» بدل الإسناد.
CRM آليًا
النقطة الحاسمة: لا تحذف ما يُشتبه فيه، بل اعزله. قائمة «للمراجعة» يطلع عليها شخص من التسويق مرتين في الأسبوع، ويعيد الطلب الحقيقي إلى المسار. وإذا وجد أن الفلتر يعزل طلبات حقيقية بانتظام، فالقاعدة تحتاج تعديلًا.
ما يصل العميل بعد الإرسال
تجربة العميل بعد الضغط على «إرسال» جزء من التكامل، لا تفصيلة تصميم. ثلاث طبقات:
- صفحة التأكيد: رسالة واضحة بأن الطلب وصل، وما الذي سيحدث بعده، ومتى. لا تكتفِ بعبارة «شكرًا لك» في مكان النموذج.
- رد تلقائي بالبريد: يحمل رقمًا مرجعيًا من CRM، وملخص ما طلبه، والمدة المتوقعة للتواصل بحسب أيام العمل، ووسيلة تواصل مباشرة. الرقم المرجعي يسهّل على العميل وعلى الموظف إن تواصل العميل مرة أخرى بقناة مختلفة.
- رسالة واتساب إن وُجدت موافقة: رسالة تأكيد قصيرة بقالب معتمد. منصة واتساب للأعمال تشترط الحصول على موافقة الشخص قبل مراسلته، كما في إرشادات الموافقة في منصة واتساب للأعمال، والرسائل التي تبدأها المنشأة خارج نافذة المحادثة تُرسل بقوالب معتمدة مسبقًا وفق توثيق المنصة. لذلك لا تُرسل رسالة واتساب لمجرد أن الزائر كتب رقم جواله.
والوعد في الرد التلقائي يجب أن يطابق ما يستطيع الفريق الوفاء به. رسالة تقول «سنتواصل معك خلال ساعة» ثم يأتي الاتصال بعد يومين أسوأ من رسالة تقول «خلال يوم عمل» ويُوفى بها.
الاختبار قبل الإطلاق والمراقبة بعده
أغلب أعطال ربط النماذج لا تظهر برسالة خطأ، بل بطلبات تختفي بصمت. لذلك اختبر قبل الإطلاق بقائمة مكتوبة:
- إرسال تجريبي من كل نموذج، ولكل نوع طلب، ولمدينتين مختلفتين على الأقل، والتأكد من وصول كل منها إلى الفريق الصحيح.
- زيارة من رابط يحمل معرّفات حملة، والتنقل بين صفحتين قبل الإرسال، ثم التأكد من ظهور المعرّفات في السجل.
- إرسال بجوال عميل قائم، والتأكد من ربطه بملفه وتنبيه مسؤوله بدل إنشاء سجل جديد.
- ضغط زر الإرسال مرتين، والتأكد من عدم إنشاء سجلين.
- إيقاف الربط مؤقتًا ثم إرسال نموذج، والتأكد من حفظ الإرسال وإعادة محاولته بعد عودة الربط.
- إرسال خارج ساعات العمل، والتأكد من نص الرد التلقائي وبداية المؤقت.
وبعد الإطلاق، المطابقة الأسبوعية هي أهم فحص: عدد الإرسالات التي سجلتها إضافة النماذج أو أداة تحليلات الموقع مقارنة بعدد السجلات التي أنشأها CRM من المصدر نفسه، مع السجلات المعزولة للمراجعة. أي فرق غير مفسر يعني أن هناك طلبات لم تصل.
مثال توضيحيفي أسبوع ما، سجلت إضافة النماذج 64 إرسالًا لنموذج «اطلب عرض سعر». وفي CRM وُجد 52 عميلًا محتملًا جديدًا من النموذج، و5 طلبات رُبطت بعملاء قائمين، و4 سجلات معزولة للمراجعة. المجموع 61، أي أن 3 إرسالات لم تصل. سجل التكامل أظهر أنها فشلت أثناء تحديث للموقع، فأُعيد إرسالها يدويًا، وأُضيف تنبيه عند فشل أي إرسال.
ما الذي تحدده مع فريق التكامل؟
قبل التنفيذ، ينبغي أن يكون لكل نموذج بطاقة تجيب عن: ماذا يُنشئ، وما الحقول الظاهرة والمخفية ومطابقتها مع حقول CRM، وطريقة الربط، وقواعد التوجيه، وفحوص الرسائل المزعجة، ونص الرد التلقائي، ومن يُنبَّه عند الفشل. وتتوزع المسؤوليات عادة بين فريق الموقع الذي يعدّل النماذج ويلتقط المعرّفات، وفريق CRM الذي يُعدّ الاستقبال والمطابقة والتوجيه.
في وحدة العملاء المحتملين يُنشأ السجل من النموذج بالحقول المعبأة والصفحة ومعرّفات الحملة، ويُطابق الجوال والبريد مع العملاء القائمين قبل الحفظ. ويُنفَّذ الربط عبر واجهة API أو Webhook أو نموذج يوفره النظام، ضمن طرق الربط المتاحة. وإذا كانت لديكم نماذج قائمة وتريدون تحديد طريقة ربطها ونطاقه، فيمكنكم إرسال قائمة نماذجكم لمناقشة التكامل وسنعود إليكم ببطاقة ربط لكل نموذج.
أسئلة شائعة
غالبًا لا. إذا كان الموقع مبنيًا بنظام إدارة محتوى يدعم إضافات نماذج ترسل Webhook، أو يمكن لفريقه إضافة إرسال من الخادم، فالربط تعديل محدود. وإن تعذر ذلك، يمكن استبدال النماذج نفسها بنماذج يوفرها CRM وتُضمَّن في الصفحات دون المساس ببقية الموقع.
يجب أن يحوّل التحقق الأرقام العربية المشرقية (٠١٢...) إلى أرقام لاتينية قبل فحص الصيغة والحفظ، وإلا فشلت المطابقة مع السجلات القائمة وظهرت أرقام متشابهة كسجلات مختلفة. أما لغة النص فلا تمنع الإرسال، ويمكن التقاط لغة الصفحة في حقل مخفي لإسناد الطلب لمن يتحدث لغة العميل.
اختيار المدينة أفضل من اختيار الفرع، لأن الزائر يعرف مدينته ولا يعرف بالضرورة تقسيمكم الداخلي. أما اختيار المندوب بالاسم فيناسب حالات محدودة، مثل عميل يعرف مندوبه. وحتى في هذه الحالة يُفضَّل أن تحسم المطابقة مع السجلات القائمة الإسناد، لا اختيار الزائر.
لا يوجد رقم ثابت، لكن اختبر كل حقل بسؤال: هل ستستخدمه قاعدة التوزيع أو قرار التأهيل الأول؟ إن لم يكن كذلك، فالمندوب يستطيع السؤال عنه في المكالمة. وفي الطلبات المعقدة التي تحتاج تفاصيل كثيرة، يمكن تقسيم النموذج إلى خطوتين: بيانات التواصل أولًا ثم التفاصيل، تُحفظ الأولى حين يضغط الزائر زر المتابعة، حتى لو لم يكمل الثانية.