في هذا المقال7
السؤال الذي يصل دائمًا بصيغة «هل عندكم ربط مع نظامنا؟» جوابه الصادق: لا يوجد زرّ واحد يربط أي نظام إدارة عملاء. يوجد ما هو أفيد — بطاقة داخل التدفق تنادي واجهة نظامك مباشرة، وتحفظ ردّه، وتكمل المحادثة به.
لماذا لا يوجد «ربط جاهز» ولماذا هذا في صالحك
الروابط الجاهزة في المنصّة اليوم هي سلة وزد ومنصّة الفعاليات. هذه متاجر ومنصّات فعاليات، لا أنظمة إدارة عملاء. وأنظمة إدارة العملاء تختلف عن بعضها أكثر مما تتشابه: حقولك أنت، ومراحل بيعك أنت، وتسمياتك أنت.
الربط الجاهز مع نظام لم يُبنَ له تحديدًا يعني أن تسميته تفرض نفسها على تسميتك. الربط عبر الواجهة البرمجية يعني العكس: أنت تقرّر أي حقل يذهب أين، ومتى، وبأي شرط.
أين يقف الربط في المحادثة
decisionبطاقة «طلب HTTP» داخل المسار
- العميل يكتب، والتدفق يجمع ما يحتاجه منه أولًا.
- ثم تنادي البطاقة واجهة نظامك: أنشئ عميلًا محتملًا، اقرأ حالة طلب، حدّث حقلًا.
- الردّ يُحفظ في متغيّر ويُستعمل في الرسالة التالية.
- لا قيود قوالب هنا: المحادثة مفتوحة لأن العميل هو من بدأها.
مشغّل «ويب هوك» على رأس التدفق
- نظامك يستدعي رابط التدفق برقم العميل وما يلزم من بيانات.
- يصلح للإشعارات: شُحن الطلب، اقترب الموعد، تأخّر الدفع.
- هذه رسالة يبدأها النشاط التجاري — قالب معتمد ونافذة الأربع والعشرين ساعة.
- الرابط يخرج من شريط أدوات المنشئ، وتستطيع تدويره.
بطاقة «طلب HTTP»: ما تفعله بالضبط
هذه هي البطاقة كلّها. تجدها في قائمة الكتل تحت مجموعة الإجراءات، وتضعها في أي موضع من المسار.
| الخانة | ما تضعه فيها | ملاحظة عملية |
|---|---|---|
| الطريقة | GET أو POST أو PUT أو PATCH أو DELETE. | القراءة بـ GET، والإنشاء بـ POST، والتحديث الجزئي بـ PATCH. |
| الرابط | عنوان نقطة الوصول في نظامك. يقبل المتغيّرات داخله. | يمكنك بناء الرابط من متغيّر: عنوان ينتهي برقم الطلب الذي كتبه العميل قبل قليل. |
| الترويسات | مفتاح الوصول ونوع المحتوى وما يطلبه نظامك. | هنا مكان المفتاح — لا في نصّ الرسالة. الترويسات لا تظهر للعميل إطلاقًا. |
| الجسم | البيانات المُرسَلة، وتقبل المتغيّرات أيضًا. | نوع المحتوى يُضبط تلقائيًا إن لم تحدّده أنت. |
| حفظ الردّ في | اسم متغيّر يُحفظ فيه ردّ نظامك كاملًا. | أهمّ خانة في البطاقة. بدونها ينجح الطلب ولا تستفيد من ردّه في شيء. |
مثال كامل: «وين طلبي؟»
أكثر سؤال يستهلك وقت فريقك، وأسهل سؤال يُؤتمت بالكامل — لأن الإجابة موجودة في نظامك لا في رأس الموظّف.
من سؤال العميل إلى حالة الطلب الحقيقية
sequence- 1طرح سؤال — «أرسل رقم طلبك»يحفظ ما كتبه العميل في متغيّر باسم تختاره، مثل رقم_الطلب.
- 2طلب HTTP — اقرأ من نظامكGET إلى عنوان طلباتك ينتهي بقيمة المتغيّر، ومعه ترويسة المفتاح. الردّ يُحفظ في متغيّر آخر.
- 3شرط — هل وُجد الطلب؟تقارن حقلًا من الردّ المحفوظ. رقم خاطئ أو طلب غير موجود له مسار مختلف عن طلب موجود — وهذه هي الحالة التي ينساها أغلب من يبني هذا التدفق.
- 4إرسال رسالة — بالمعلومة نفسهاتُدرج قيمًا من الردّ المحفوظ داخل نصّ الرسالة: الحالة، وشركة الشحن، والتاريخ المتوقّع. الفرق بين «تم استلام طلبك» و«طلبك خرج من المستودع أمس ويصل خلال يومين» هو هذه الخطوة.
- 5تسليم للموظف — عند الحاجة فقطفرع الخطأ وفرع «لم يُعثر على الطلب» ينتهيان هنا، لا في الفراغ. الموظّف يفتح المحادثة وقد قرأ العميل رقمه بالفعل.
الاتجاه المعاكس: نظامك يبدأ المحادثة
حين تتغيّر حالة في نظامك — شُحن الطلب، اقترب الموعد، تأخّر الدفع — لا داعي أن ينتظر العميل حتى يسأل. مشغّل ويب هوك يمنح التدفق رابطًا خاصًّا به؛ يستدعيه نظامك برقم العميل وما يلزم، فينطلق التدفق.
- الرابط يخرج من شريط أدوات المنشئ — لا تكتبه بنفسك، ولا تشاركه خارج نظامك، وتستطيع تدويره متى شئت.
- هذه رسالة يبدأها النشاط التجاري — أي أنها تخضع لقواعد القوالب المعتمدة ونافذة الأربع والعشرين ساعة، تمامًا كأي رسالة أخرى تبدأ منك. راجع دليل اعتماد القوالب قبل أن تبني عليها إشعارًا يوميًا.
- ابدأ بحدث واحد — «شُحن الطلب» وحده يكفي لتتعلّم منه. عشرة أحداث دفعة واحدة تعني عشرة مسارات لم تُختبر أيّ منها.
حين لا يكون لنظامك واجهة برمجية
لا يزال أمامك مساران، وكلاهما أفضل من ترك البيانات داخل نصّ المحادثة.
| المسار | كيف يعمل | متى يناسبك |
|---|---|---|
| أداة ربط وسيطة | أي أداة تقدّم رابط ويب هوك: التدفق ينادي الأداة، والأداة تكتب في نظامك بالطريقة التي تفهمها. | حين يكون لنظامك تكامل مع أدوات الربط الشائعة ولو بلا واجهة عامّة. |
| حقول جهة الاتصال والوسوم | التدفق يكتب ما جمعه في حقول جهة الاتصال داخل المنصّة ويضع وسمًا، ثم تُصدَّر القائمة دوريًا. | حين لا يوجد أي منفذ برمجي. البيانات تبقى مجمّعة وقابلة للتصفية والتصدير بدل أن تذوب في المحادثات. |
قبل أن تبني: خمس نقاط تختصر عليك أسبوعًا
- مفتاح بصلاحية محدودة. أنشئ مفتاحًا يقرأ الطلبات ويكتب العملاء المحتملين فقط. مفتاح المدير في ترويسة تدفّق هو أوسع صلاحية ستمنحها في حياتك لأقلّ سبب.
- اختبر بالمحاكي قبل النشر. المحاكي يمشي على المسار كعميل ويُظهر قيمة كل متغيّر لحظة بلحظة، فترى ردّ نظامك كما وصل فعلًا لا كما تتوقّعه.
- صِل فرع الخطأ دائمًا. قبل أن تصل الفرع الناجح.
- لا تضع أسرارًا في نصّ الرسالة. ما يُكتب في نصّ رسالة يراه العميل. المفاتيح مكانها الترويسات وحدها.
- عنوان عام لا داخلي. المنصّة ترفض في الإنتاج استدعاء عنوان يقع على شبكة داخلية أو محجوزة. إن كان نظامك خلف جدار، فأنت تحتاج نقطة وصول عامّة أو أداة وسيطة.
ما لا يفعله هذا الربط
نقطة تُوفّر خيبة أمل: بطاقة «طلب HTTP» تنادي نظامك عند مرور المحادثة عليها. هي ليست مزامنة دائمة في الخلفية. لا يوجد جدول يمشي كل ساعة يقارن قاعدتين ويوفّق بينهما.
هذا كافٍ تمامًا لأغلب ما يُطلب فعلًا — إنشاء عميل محتمل، قراءة حالة، تحديث حقل عند حدث. أمّا مزامنة ثنائية مستمرّة بين قاعدتين فهي مشروع تكامل بذاته، وليست ما تفعله بطاقة داخل تدفّق. اعرف الفرق قبل أن تَعِد به أحدًا في شركتك.
هل يوجد ربط جاهز بنقرة واحدة مع نظام إدارة العملاء لدي؟
لا. الروابط الجاهزة اليوم هي سلة وزد ومنصّة الفعاليات — وهي متاجر ومنصّات فعاليات لا أنظمة إدارة عملاء. الربط مع نظامك يتمّ عبر واجهته البرمجية (API) من داخل التدفق، وهذا ليس التفافًا على نقص: هو الطريقة التي تُبقي الربط تحت سيطرتك، لأن أي «ربط جاهز» مع نظام لم يُبنَ له تحديدًا سيفرض عليك تسمية حقوله لا تسميتك.
نظامنا لا يملك واجهة برمجية أصلًا. ما البدائل؟
مسار وسيط أو مسار يدوي. الوسيط: أي أداة ربط تقدّم رابط ويب هوك يستقبل منّا ويكتب في نظامك. اليدوي: التدفق يكتب البيانات في حقول جهة الاتصال ووسومها داخل المنصّة، ثم تُصدَّر دوريًا. الثاني ليس مثاليًا لكنه يبقي البيانات مجمّعة في مكان واحد بدل أن تضيع في نصّ المحادثة.
ماذا يحدث إن كان نظامنا معطّلًا لحظة إرسال الطلب؟
العميل لا يرى شيئًا. طلب HTTP له مهلة خمس عشرة ثانية، وأي ردّ من فئة الخطأ (400 وما فوق) أو انقطاع في الاتصال يُخرج المسار من فرع «الخطأ» على البطاقة إن كنت قد وصلته. وصْل هذا الفرع هو الفرق بين «نعتذر، سنعاود التواصل» وبين محادثة تتوقّف في الفراغ.
هل أستطيع استخدام ردّ نظامي داخل الرسالة التالية؟
نعم، وهذا أهمّ ما في البطاقة. تختار اسم متغيّر في خانة «حفظ الردّ في»، فيُحفظ ردّ نظامك كاملًا فيه، ثم تُدرجه في أي رسالة أو شرط بعده. هكذا يقول الردّ «طلبك رقم 4471 خرج من المستودع» بدل «تم استلام طلبك».
هل يستطيع نظامنا أن يبدأ محادثة واتساب بنفسه؟
نعم، عبر الاتجاه المعاكس: مشغّل «ويب هوك» يعطي التدفق رابطًا يستدعيه نظامك. يرسل نظامك رقم العميل وما يلزم من بيانات، فيبدأ التدفق. انتبه أن هذه محادثة يبدأها النشاط التجاري، فتخضع لقواعد القوالب ونافذة الأربع والعشرين ساعة كأي رسالة أخرى.
هل الربط آمن؟ نحن نرسل بيانات عملاء.
المفاتيح تُوضع في ترويسات الطلب لا في نصّ الرسالة، ولا تظهر للعميل. والمنصّة ترفض في بيئة الإنتاج استدعاء أي عنوان يقع على شبكة داخلية أو عنوان محجوز — وهي حماية ضدّ إعادة توجيه الطلب إلى داخل الخوادم. يبقى عليك أنت: مفتاح بصلاحية محدودة لا مفتاح المدير، وتدويره كل فترة.



