قبل ما تبني الـ GTM workflow: اسأل الـ 7 أسئلة دي

1. مين الحساب المناسب — وليه؟

قبل ما تكتب اسم tool، اكتب مين المفروض يستفيد من عرضك. الـ fit هو ملاءمة الحساب للعرض؛ مش مجرد وجوده في industry كبيرة، ومش دليل intent أو رغبة في الشراء. السؤال العملي: إيه الصفات التي تجعل البحث في الحساب يستحق وقتك؟

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

شرط التوقف: لا تبدأ enrichment مكلفًا لحساب لم تحدد هويته أو لا تعرف معيار ملاءمته. ممكن تعمل خطوة بحث أولية، لكن لا تسمّيه qualified.

2. إيه الـ output — ومين هيستخدمه؟

المخرج مش لازم يكون dashboard ولا قائمة كبيرة. اختار شيئًا يستطيع شخص استخدامه في قرار واضح: brief حساب، ملاحظة CRM، أو قائمة مراجعة. اسأل المستلم: إيه المعلومات التي تحتاجها فعلًا قبل الخطوة التالية؟

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

شرط التوقف: لو المستلم غير معروف، أو لا يوجد قرار يعتمد على النتيجة، لا تؤتمت توليدها. جرّب إنتاج brief يدويًا وراجع فائدته أولًا.

3. إيه المعلومات الناقصة — ومنين هتجيبها؟

افصل بين معلومة تحتاجها ومعلومة تستطيع أداة جلبها. الـ enrichment هو إضافة معلومات من مصادر إلى داتا عندك؛ فائدته تعتمد على سؤال محدد وعلى صحة المدخلات. Clay توضح إضافة enrichment من الجدول واختيار التكامل والحساب، والتحكم في التشغيل عبر Auto-run وrun conditions. [1]

اكتب المطلوب، الحقل المستخدم كمدخل، والمصدر المتوقع. لو هدفك وصف النشاط، راجع هل الناتج يرتبط بالشركة الصحيحة ويتيح دليلًا يمكنك مراجعته. لو لم يوفر التكامل رابط دليل، لا تعتبر النص وحده حقيقة مؤكدة.

شرط التوقف: مصدر غير معروف، input ناقص، أو نتيجة لا تخص الكيان. Unknown أفضل من معلومة تبدو كاملة ولا يمكن إثباتها.

مصادر: [1]

4. إيه اللي بيبدأ — وإيه الخطوة التالية؟

الـ trigger هو الحدث الذي يبدأ workflow. الـ action هي خطوة تعمل على الداتا بعد البداية. في n8n ده الفرق بين node تبدأ وnode تعالج. صورة Asana في الوثائق تعرض الاثنين معًا: event يبدأ، وقائمة actions لا تبدأ وحدها. هي شرح للمفهوم، مش flow جاهز لبحث الحسابات. [2]

اكتب التسلسل في جملة واحدة: تشغيل يدوي → فحص المدخلات → استكمال معلومة → إعداد brief → مراجعة → تحديث حالة. عند كل سهم اسأل: هل مخرج الخطوة الأولى كافٍ للثانية؟ اكتب شرطًا بدل افتراض أن الخطوة ستنجح دائمًا.

شرط التوقف: أي انتقال لا تعرف مدخله أو المسؤول عنه. لا تنقل صفًا للـ CRM لمجرد أن طلبًا انتهى بلا خطأ.

1. ابدأ يدويًا بحساب معروف؛ افحص الـ input قبل أي اتصال خارجي.
2. بعد كل action افتح الـ output، وحدد إن كان صالحًا للخطوة التالية.
3. أضف طريقًا للمعلومة الناقصة: بحث إضافي، لا ملء تلقائي بالتخمين.
4. افصل نقطة المراجعة البشرية عن نقطة تحديث الأنظمة.

مصادر: [2]

5. إزاي تعرف إن الحساب اتعالج قبل كده؟

التكرار مش مجرد أسماء متشابهة. نفس الشركة قد تكتب بأكثر من اسم، والفرع قد يحتاج سجلًا منفصلًا حسب طريقة عملك. اتفق على مفتاح الحساب ومستوى الكيان قبل إنشاء records.

الـ domain الموحّد يمكن يكون مفتاحًا تنظيميًا مفيدًا بعد مراجعة الهوية، لكنه لا يحل وحده مسألة الشركات التابعة أو الفروع. قبل إنشاء سجل، ابحث عن الموجود وقرر هل تحدثه أو تراجع التعارض. احتفظ بسبب القرار بدل تركه في ذهن شخص واحد.

شرط التوقف: وجود سجل متعارض أو عدم وضوح مستوى الشركة/الفرع. إعادة تشغيل الدفعة لا يجب أن تتحول لإنشاء نسخ جديدة بلا مراجعة.

6. مين صاحب القرار — ومعنى الـ stage إيه؟

الـ pipeline ترتيب مراحل توضح أين وصل السجل. HubSpot تعرض stages كجزء من عملية السجل، لكن تعريف التأهيل ومسؤولية الانتقال ليسا شيئًا تمنحه الأداة تلقائيًا. إعدادات الأنواع والصلاحيات والتوفر تختلف حسب النظام والخطة. [3]

اختار مراحل تعكس قرارات حقيقية، لا أفعال تقنية فقط. Enriched تعني رجعت داتا؛ Reviewed تعني شخص راجعها؛ Qualified يحتاج معايير تأهيل محددة. لا تسوي بين الثلاثة. ولا تنشئ deal لمجرد ظهور اسم شركة في قائمة بحث.

شرط التوقف: stage لا يعرف الفريق معناها أو انتقال لا يملكه أحد. اكتب دليلًا بسيطًا للانتقالات قبل وصل automation بالـ CRM.

مصادر: [3]

7. إيه اللي يتراجع قبل الإرسال — ولو فشل الشغل؟

اكتمال brief لا يساوي إذن إرسال. راجع مصدر الداتا وصلاحية استخدامها، صلة الرسالة بالمتلقي، ومتطلبات قناة الإرسال. Gmail توضح متطلبات authentication وإضافات تخص bulk senders؛ راجع الأصل وقت التنفيذ حسب نوع إرسالِك، ولا تعامل checklist قديمة كضمان وصول. [4]

جهّز طريقًا للفشل أيضًا. n8n تتيح Error workflow يبدأ بـ Error Trigger ويتحدد في إعدادات الـ workflow. استخدامه للتنبيه مفيد، لكن محتوى التنبيه يعتمد على نوع الخطأ والحقول المتاحة. مراجعة Executions تساعد في تشخيص أين توقفت الخطوة. [5]

شرط التوقف: دليل ناقص، بيانات غير مشروعة الاستخدام، رسالة غير ذات صلة، أو خطأ غير مشخص. التصرف الصحيح ليس زيادة الإرسال أو إعادة نفس العملية بلا نهاية.

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

املأ النموذج ده قبل أول automation

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

لشرح التسلسل بالتفصيل، ارجع لمقال «متشتريش tools عشوائي — ابني workflow الأول». الدليل ده يساعدك تحسم القرارات قبل البناء؛ المقال يشرح كيف ترتبط ببعضها.

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