متشتريش tools عشوائي — ابني workflow الأول

قبل الأدوات: إحنا بنحاول نطلع إيه؟

تخيّل إنك بتبيع خدمة تساعد شركات B2B ترتّب عملية البحث عن حسابات مناسبة. حد في الفريق عنده أسماء شركات، لكنه قبل كل مكالمة بيرجع يدور من الصفر: الشركة دي بتعمل إيه؟ ليه مناسبة؟ وإيه اللي نعرفه فعلًا عنها؟

المشكلة هنا مش إن مفيش tool. المشكلة إن اسم الشركة بيتنقل من شخص للتاني من غير سياق. لو ضفت automation دلوقتي، ممكن تنقل نفس الغموض أسرع. المطلوب مش list أكبر؛ المطلوب brief قصير يخلي الشخص التالي يعرف يراجع الحساب ويقرر الخطوة المناسبة.

هنمشي في مثال تعليمي، مش تجربة عميل ولا وعد بنتيجة: شركة افتراضية اسمها Atlas Logistics، ونفترض إن عرضنا موجّه لشركات لوجستيات B2B في مصر. كل الأسماء والبيانات في المثال افتراضية؛ تطبيقه على شركة حقيقية يحتاج مصادر حقيقية ومراجعة مستقلة.

ارسم رحلة صغيرة وحدد معنى كل مرحلة

الـ workflow هو ترتيب الشغل: حاجة تبدأ العملية، خطوات تعالج المدخلات، وقرارات تغيّر الطريق. الـ trigger هو الحدث اللي يبدأ؛ مثل تشغيل يدوي لدفعة بحث. الـ action هي خطوة تعمل حاجة، مثل جلب معلومة أو تحديث سجل.

في البداية اختار تشغيلًا يدويًا بدل ربط كل شيء بحدث تلقائي. هتقدر تشوف المدخلات وتفهم الخطأ قبل ما يتكرر. التسلسل المقترح هنا: إدخال حساب → فحص المدخلات → enrichment مطلوب → إعداد brief → مراجعة بشرية → تحديث حالة في الـ CRM. ده تصميم تعليمي، مش template جاهز موصول بحساباتك.

الـ enrichment معناه استكمال الداتا بمعلومات من مصادر أخرى. أما orchestration فهو تنظيم مين يشتغل قبل مين وإيه اللي يحصل بعدها. ممكن تعمل الاثنين يدويًا في البداية؛ استخدام أدوات منفصلة مش شرط.

1. اكتب المخرج أولًا: brief يقدر زميل يراجعه ويقرر بناءً عليه، لا مجرد spreadsheet ممتلئ.
2. اكتب المدخلات الضرورية: اسم الشركة وdomain صحيح ورابط مصدر متاح بصورة مشروعة.
3. حدد شروط التوقف: domain ناقص أو شركة ملتبسة أو مصدر لا يدعم المعلومة. النتيجة هنا Needs research، مش تخمين.
4. حدد المستلم: reviewer معروف، وليس inbox لا يفتحه أحد.
5. حدد متى تعتبر الخطوة منتهية: كل ادعاء واقعي له مصدر، والناقص مكتوب، والقرار له صاحب مسؤولية.

مصادر: [1][2]

ابني input contract: إيه اللي يدخل وإيه اللي ممنوع نفترضه؟

الـ input contract اتفاق بسيط على شكل المدخلات. لو حد كتب اسم شركة فقط، لا تعتبره كافيًا لتحديد الكيان الصحيح. أسماء الشركات ممكن تتكرر، والـ domain نفسه قد يخص فرعًا أو علامة أخرى. افتح المصدر وتأكد إن الاسم والنشاط يخصان الحساب المقصود.

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

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

Clay: شغّل enrichment لأنك محتاج معلومة بعينها

Clay بتشرح enrichments كطريقة لجلب معلومات إضافية من مصادر مختلفة. الدليل الرسمي الحالي يبدأ من جدول: Add enrichment، ثم اختيار enrichment تحت Integrations، وبعده اختيار الحساب المناسب. بعض التكاملات توفرها Clay بحساباتها؛ أخرى قد تحتاج حسابك وصلاحياتك. لا تفترض إن كل enrichment متاح بنفس الشروط أو التكلفة. [1]

في مثالنا السؤال المحدد هو: هل نقدر نضيف وصفًا لنشاط الشركة من مصدر مناسب؟ مش: إيه كل الحقول اللي نقدر نجيبها؟ اختار enrichment يخدم السؤال، واعرف أي input يحتاجه فعلًا. لو يحتاج domain، map الحقل الصحيح له؛ لو المدخل ناقص، لا تشغّل الخطوة ثم تتعامل مع الناتج كأنه حقيقة.

افتح إعدادات run الخاصة بالعمود قبل التشغيل. الدليل يوضح إن Auto-run يعيد التشغيل عند تغيّر المدخلات، وإن Add run condition يسمح بالتشغيل عندما يتحقق شرط. في تجربة أولى، التشغيل اليدوي يسهّل تتبع النتيجة والمصاريف. لا نضع هنا formula ندّعي إنها جاهزة لكل جدول؛ أسماء أعمدتك ونوع enrichment هي التي تحددها.

1. اختار المعلومة الناقصة والمصدر المتوقع لها؛ راجع وصف التكامل ومدخلاته وتكلفته قبل التشغيل.
2. من جدول Clay اختار Add enrichment، ابحث عن التكامل المناسب، ثم حدد الحساب الذي تملك حق استخدامه.
3. اربط input الشركة بالحقل الصحيح. جرّب صفًا معروفًا بدل تشغيل الدفعة كلها.
4. راجع Run settings: هل Auto-run مفعل؟ هل تحتاج شرطًا يمنع التشغيل لو الـ domain ناقص؟
5. افتح الناتج وقارنه بالمصدر الأصلي. نجاح الخطوة لا يثبت أن الوصف يخص الشركة الصحيحة.
6. احتفظ بالنتيجة والمصدر وتاريخ مراجعته؛ لو التكامل لا يعطي رابط دليل مناسب، أضف خطوة تحقق مستقلة قبل قبول الادعاء.

مصادر: [1]

n8n: خلّي كل خطوة لها input وoutput واضحين

في n8n الـ nodes هي الوحدات الأساسية: triggers تبدأ الـ workflow وactions تعالج الداتا. اختيار node مش مجرد اختيار logo؛ لازم تعرف العملية التي ستنفذها والحقول التي تنتظرها. الصورة التالية من وثائق n8n نفسها تعرض قائمة Asana: حدث يبدأ workflow، وتحته actions تحتاج شيئًا يشغّلها. هي مثال رسمي للتمييز، وليست توصية باستخدام Asana في مثالنا. [2]

ابدأ flow يدويًا، أدخل حسابًا واحدًا، وتحقق من الحقول قبل الاتصال بأي نظام خارجي. بعد كل خطوة راجع output: هل رجع سجل الشركة؟ هل يوجد مصدر؟ هل البيانات فارغة؟ بعد ذلك فقط مرّرها للخطوة التالية. لا توصل الـ CRM أثناء أول تجربة إذا لم تتأكد من نتيجة المعالجة.

أي اتصال بـ Clay أو CRM يعتمد على التكامل المتاح عندك وبياناته وصلاحياته. هذا المقال يشرح التصميم والمراجعة، ولا يدّعي أن screenshots التالية تعرض flow كاملًا موصولًا بهذه الخدمات.

لقطة Google Sheets → Edit Fields أدناه توضح خطوتين منفصلتين في canvas حقيقي. الأولى تقرأ داتا، والثانية تنظّم الحقول. نستخدمها لشرح فكرة فصل القراءة عن المعالجة، مش لإثبات إن الـ workflow ده تم تشغيله لحسابنا الافتراضي. شكل الواجهة في اللقطات هو الشكل المنشور في الوثائق وقت المراجعة وقد يختلف عن إصدار حسابك.

مصادر: [2]

المراجعة والـ CRM: السجل مايتقدمش لمجرد إنه اتملّى

الـ brief المفيد يجاوب على ثلاثة أسئلة: نعرف إيه؟ الدليل فين؟ وإيه اللي لسه مانعرفوش؟ كتابة فقرة واثقة من غير مصادر مش enrichment ناجح. ولو هتستخدم AI لصياغة الملخص، خليه يرتب الأدلة المتاحة فقط؛ لا تسمح له بإكمال المعلومة الناقصة بتخمين.

HubSpot بتوضح إن pipelines تحتوي stages توضح أين وصل السجل في العملية. تعريف stage في شغلك مسؤوليتك. ممكن تستخدم مراحل بحث داخلية، لكن لا تساوي بين Research completed وQualified deal. اختيار نوع السجل وإعداد pipeline والصلاحيات يختلف حسب نظامك وخطتك؛ لا تنشئ deal لمجرد أنك وجدت شركة على الإنترنت. [3]

في مثالنا التحديث الآمن الأول هو حالة البحث وربط الـ brief بالسجل المناسب بعد المراجعة. الاتصال البيعي مرحلة منفصلة تحتاج سببًا مناسبًا وصلاحية استخدام الداتا ومراجعة متطلبات القناة.

• طابق الكيان: هل الروابط والوصف يخصان نفس الشركة؟
• راجع كل معلومة واقعية مقابل مصدرها، وافصل الرأي عن الحقيقة.
• اكتب Unknown بدل تخمين صاحب القرار أو الاحتياج.
• راجع وجود السجل قبل إنشاء آخر؛ مفتاح التكرار واتفاق الفريق أهم من اسم stage.
• لا تعتبر فتح pipeline أو نجاح update دليلًا على جودة الحساب.

مصادر: [3][4]

صمّم طريقًا للفشل، وبعدها فكّر في التوسع

الـ workflow اللي له happy path بس هش: مصدر ممكن لا يرد، حقل يتغير، أو صلاحية اتصال تنتهي. فرّق بين فشل تقني ونتيجة غير كافية. الأول يحتاج تشخيص التنفيذ؛ الثاني يحتاج بحثًا أو مراجعة، وليس إعادة نفس الطلب بلا نهاية.

n8n تتيح Error workflow يبدأ بـ Error Trigger ويُختار من Workflow Settings. يمكن استخدامه للتنبيه عند فشل التنفيذ. راجع Executions لمعرفة أي خطوة فشلت والداتا التي وصلت لها. الدليل يذكر أيضًا أن أخطاء trigger قد ترسل تفاصيل مختلفة عن أخطاء الخطوات التالية؛ لا تبنِ التنبيه على افتراض أن كل الحقول موجودة دائمًا. [5]

لو المرحلة التالية email، ارجع لمتطلبات Gmail حسب نوع وحجم الإرسال، بما فيها authentication ومتطلبات bulk senders. تجهيز داتا لا يبرر إرسالًا غير مرتبط بالمتلقي، وتوصيل أداة إرسال ليس ضمانًا للوصول. [4]

التوسع يأتي بعد أن يقرأ شخص الـ brief ويستفيد منه. اسأل: هل معلوماته صحيحة؟ هل يوضح الناقص؟ هل القرار التالي واضح؟ لو الإجابة لا، تحسين الـ handoff أهم من إضافة أداة أو زيادة عدد الصفوف.

ابدأ من الـ output، وحدد الـ inputs والـ decisions والـ handoffs. جرّب خطوة بخطوة. راجع الأدلة قبل انتقال الحالة. بعدها اختار الأدوات التي تؤدي دورًا واضحًا. الـ stack نتيجة للتصميم، مش نقطة بدايته.

مصادر: [4][5]

مرفقات المقال