خلّي كل عميل محتمل يوصل نظامك بنفسه — بدون نسخ ولصق
تربط نموذج موقعك بنظام الـ CRM عبر دالة سحابة تنطلق لحظة ما يضغط الزائر «أرسل»: الطلب ينحفظ أولاً بقاعدة بيانات موقعك، وبعدها ينندفع للنظام الخارجي بمفتاح محفوظ على الخادم. الترتيب هذا مو تفصيلاً تقنياً — هو الفرق بين طلب ضايع وطلب موجود لما يوقع مزوّدك. أي نظام عنده REST API عام يشتغل، ومعه جوجل شيتس وAirtable وNotion وسلاك وديسكورد وواتساب أعمال وتيليجرام. وهالصفحة تشرح المسار كامل: وين تروح البيانات، شو الحدود، وكيف تحمي بيانات عميلك.
نُشر في:
ابدأ مجاناًرحلة العميل المحتمل من النموذج للنظام
خمس محطات، وكل وحدة منها تنفع تشتغل لحالها لو انقطعت اللي بعدها.
خمس خطوات للدفع التلقائي
اربط النموذج بقاعدة بيانات موقعك أولاً
أول شي يسويه النموذج هو cloud.db.insert — صف واحد فيه الاسم والجوال والطلب ومصدر الزيارة. الصف يتحمّل حتى 32 كيلوبايت، وهذا أوسع بكثير من أي نموذج تواصل. مهم تحدّد مستوى الوصول للصف: cloud.db فيه أربعة مستويات وصول، وقائمة العملاء المحتملين لازم تكون بمستوى ما يقرأه إلا صاحب الموقع، لا زائر عابر.
اختر وجهة العميل المحتمل
قبل ما تكتب أي كود، قرّر وين المكان اللي فريقك بيفتحه فعلاً كل صباح. لو الجواب واتساب أو شيت، لا تربط CRM ثقيل ما حدا بيدخله. لو عندك نظام قائم وفريق يعتمد عليه، ادفع له مباشرة. الجدول تحت يعطيك كل وجهة وكيف توصلها وهل تحتاج مفتاحاً.
احفظ مفتاح النظام في «الأسرار»
المفتاح يتحفظ من داخل المحادثة عبر حقل إدخال آمن — القيمة تروح للخادم مباشرة وما تمرّ بالنموذج ولا تنكتب بسجل المحادثة — أو تضيفه بنفسك من لوحة «الأسرار». الاسم بصيغة CRM_API_KEY: حروف كبيرة وأرقام وشرطة سفلية حتى 40 حرفاً، والقيمة حتى 2000 حرف. وانتبه: رابط ويبهوك سلاك أو ديسكورد هو نفسه سرّ، لا تحطه بكود الصفحة.
ابني يكتب دالة الدفع
الدالة تستقبل الصف، تقرأ المفتاح بـ ebnii.secrets.get، وتنادي نظامك بـ ebnii.fetch. رد النظام يرجع نصاً خاماً فالدالة تحلّله وتتحقق من رمز الحالة. لو نجح، تحدّث الصف عندك بمعرّف السجل الخارجي؛ ولو فشل، تعلّم الصف إنه ما انبعث وتعيد المحاولة بمهمة مؤجلة عبر ebnii.jobs.enqueue — عشرة تأجيلات بالتشغيلة و500 باليوم.
شغّل التنبيه الفوري والملخّص اليومي
التنبيه الفوري يوصلك إيميلاً لحظة وصول الطلب، وضمن 500 رسالة مجانية بالشهر لكل مشروع. والملخّص اليومي مهمة مجدولة تُعرَّف بملف functions/_jobs.json، مثلاً daily الساعة 08:00 بتوقيت الرياض. انتبه لثلاث حقائق: المهام ما تشتغل إلا على موقع منشور، وأقصى عدد 10 مهام للموقع الواحد، والمهمة تتعطّل تلقائياً بعد 10 إخفاقات متتالية.
وين ممكن يروح العميل المحتمل
كل وجهة من هذي مجرّبة وتشتغل من داخل ابني. الفرق بينها بمن يفتحها فعلاً، وهل تحتاج مفتاحاً.
| الوجهة | كيف توصلها | تحتاج مفتاحاً؟ |
|---|---|---|
| قاعدة بيانات موقعك | cloud.db.insert مباشرة من الصفحة | لا — جزء من الموقع نفسه |
| جوجل شيتس | cloud.google.sheets.append من الصفحة | لا مفتاح — لكن لازم تربط حساب جوجل لهذا الموقع، وإلا يرجع رفض google_not_connected |
| Airtable أو Notion | ebnii.fetch من دالة سحابة | نعم — والاثنان ضمن المزوّدين المشروحين بخطوات جلب المفتاح |
| سلاك أو ديسكورد | ebnii.fetch على رابط الويبهوك | نعم — الرابط نفسه يُحفظ كسرّ |
| واتساب أعمال أو تيليجرام | ebnii.fetch من دالة سحابة | نعم — Cloud API أو توكن البوت |
| بريدك أنت | cloud.email.send من الصفحة | لا — ضمن 500 رسالة مجانية بالشهر لكل مشروع |
| أي CRM ثاني له REST API | ebnii.fetch بمفتاح محفوظ | نعم — سرّ باسم واضح مثل CRM_API_KEY |
الطلبات كما تشوفها أنت
الدفع التلقائي: وين يشتغل ووين ينكسر
الربط هذا ممتاز لدفع عميل واحد لحظة وصوله. وسيّئ جداً كمزامنة جماعية بين قاعدتين.
يشتغل ممتاز
- دفع فوري لكل عميل محتمل لحظة ما يضغط «أرسل» — بلا انتظار ولا نسخ يدوي.
- نسخة كاملة تبقى عندك بقاعدة بيانات موقعك مهما صار للنظام الخارجي.
- تنبيه فوري لفريق المبيعات على واتساب أعمال أو تيليجرام أو سلاك أو الإيميل.
- ملخّص يومي بمهمة مجدولة يجمع طلبات أمس برسالة وحدة بدل عشرين إشعاراً.
- المفتاح محفوظ على الخادم فقط، وما يظهر بكود الصفحة ولا بأدوات المطوّر.
لا تبني عليه
- ما ينفع تسحب قاعدة الـ CRM كاملة للموقع: ebnii.db.list جوّا الدالة يوقف عند 200 صف بلا offset، وlistAll مو موجودة أصلاً على الخادم.
- الدفع لعميل واحد بالتشغيلة هو النمط الصحيح — 8 نداءات خارجية بالتشغيلة الواحدة فقط.
- مكتبة الـ CRM الرسمية على npm ما تشتغل: الصندوق QuickJS بدون require ولا Node.
- الملخّص اليومي لعملائك المحتملين ما يوصلك قبل ما تنشر الموقع — المهمة المجدولة تحتاج موقعاً منشوراً، وتتعطّل لحالها بعد 10 إخفاقات متتالية فراقبها أول أسبوع.
- لو نظامك ما عنده REST API عام أو موجود على شبكة داخلية، الربط المباشر مو ممكن — النداءات للشبكات الخاصة والعناوين المحلية مرفوضة.
خصوصية بيانات العميل المحتمل
بيانات العميل المحتمل أخطر ما بموقعك، وأول قرار فيها هو مستوى الوصول. cloud.db فيه أربعة مستويات وصول، وقائمة العملاء لازم تكون بمستوى ما يقرأه إلا صاحب الموقع — لا مستوى عام ولا مستوى يقرأه أي مستخدم مسجّل. الخطأ الشائع إن الفريق يخلي صفوف العملاء بنفس مستوى المنتجات، فيصير أي زائر يفتح قائمة الأرقام. لو تبي تعرض للزائر طلبه هو فقط، النمط الصحيح إن الصف يُربط بالمستخدم صاحبه لا إن القائمة كلها تنفتح.
المفتاح ما يمرّ بالمتصفح إطلاقاً: ينحفظ بجدول أسرار خاص بالمشروع على الخادم، وينشطب من السجلات وتقارير الأخطاء. وحتى بيانات الزوّار تنشطب من السجلات وتنكتب مكانها «إيميل محجوب» و«رقم محجوب»، عشان تقدر تسجّل وتراقب بدون ما تبني أرشيفاً ثانياً لأرقام عملائك بمكان ما تنتبه له.
وفيه قيد مقصود تحتاج تعرفه من البداية: cloud.email.send من كود الصفحة يوصل لبريدك أنت أو لبريد المستخدم المسجّل دخوله فقط — أي عنوان ثالث يُرفض. يعني تنبيه لبريد فريق مبيعات خارجي لازم يمرّ عبر دالة سحابة، لأن ebnii.email.send جوّا الدالة توصل لأي عنوان بحد 5 رسائل بالتشغيلة. هذا الحاجز موجود عشان ما يتحوّل موقعك لمرحّل رسائل بيد أول زائر يفتح أدوات المطوّر.
أسئلة شائعة
اقرأ أيضاً
خلّي نموذجك يشتغل لحاله
قل لابني: «خزّن كل طلب من نموذج التواصل عندي وادفعه لنظامي ونبّهني على تيليجرام» — وشوف أول طلب يوصل بنفسه.
ابدأ مجاناً