مرحبا بالجميع،
أريد أن أعرف ما إذا كان أحد هنا قد بنى سير عمل مثل هذا في n8n بالفعل.
فكرة سير العمل:
1. قراءة العملاء المحتملين من CRM أو Google Sheets
2. كل عميل محتمل لديه اسم وبريد إلكتروني واسم الشركة والموقع الإلكتروني
3. زيارة واستخراج بيانات موقع الشركة الإلكترونية تلقائياً
4. يحلل الذكاء الاصطناعي النشاط التجاري ويفهم ما الذي يفعلونه
5. يكتب الذكاء الاصطناعي بريداً إلكترونياً بارداً مخصصاً بناءً على تحليل الموقع الإلكتروني
6. يتم إرسال البريد الإلكتروني تلقائياً إلى العميل المحتمل
7. يتم إرسال رسائل متابعة تلقائياً إذا لم يكن هناك رد
8. كشف الرد يوقف التسلسل إذا كان العميل المحتمل مهتماً
أنا لا أسأل عما إذا كان يمكن بناء هذا.
أريد أن أعرف ما إذا كان شخص ما قد بنى شيئاً مشابهاً من قبل بالفعل.
إن كانت الإجابة نعم، فيرجى مشاركة سير عملك أو عرض توضيحي أو تجربتك.
شكراً لك.
نعم، متغيرات قريبة: الصف الأول → جلب الموقع → ملخص تجاري قصير → مسودة مخصصة → فحص الإرسال/عدم الإرسال → إيقاف التسلسل عند وصول رد.
الجزآن اللذان عادة ما يحددان ما إذا كان سيعمل هما جودة جلب الموقع وقاعدة إيقاف الرد. إذا كنت تريد مقارنة الملاحظات، فما الذي تبدأ منه: CRM أم Sheets أم قائمة تم كشطها؟
أهلا وسهلا @Ayesha_Saeed!
هذا تدفق قابل للبناء جدًا في n8n. العقدة الحرجة التي يجب البحث عنها أولاً هي عقدة HTTP Request لخطوة كاشطة الويب - ربطها مع عنوان URL لقارئ Jina (https://r.jina.ai/[URL]) يعطيك markdown نظيف من أي موقع ويب للأعمال دون التعامل مع HTML الخام. من هناك، استدعاء LLM واحد لتلخيص ومسودة البريد الإلكتروني في خطوة واحدة يحافظ على سرعة سير العمل وكفاءة الرموز.
مرحباً، أنا مهتم بهذا التشغيل الآلي. كيف يمكن تحقيقه من البداية إلى النهاية؟ شكراً مقدماً.
مرحبا،
نعم، لقد قمت ببناء سير عمل n8n مشابه من قبل للبحث عن العملاء المحتملين بقوة الذكاء الاصطناعي وأتمتة رسائل البريد الإلكتروني البارد الشخصية.
قام سير العمل بسحب العملاء المحتملين من جداول Google/أنظمة إدارة علاقات العملاء، وكشط موقع الويب الخاص بالشركة، واستخدام الذكاء الاصطناعي لفهم الأعمال، وإنشاء بريد إلكتروني شخصي، وإرساله عبر نظام البريد الإلكتروني المتصل، وإدارة المتابعات بناءً على حالة الرد.
تعاملت أيضاً مع عمليات التحقق من التكرارات، وفشل كشط موقع الويب، وتحديثات حالة العميل المحتمل، والتسجيل، وكشف الردود بحيث تتوقف السلسلة عندما يرد شخص ما.
سؤال واحد: هل تخطط لإرسال رسائل البريد الإلكتروني عبر Gmail/SMTP، أم عبر أداة بريد إلكتروني بارد مثل Instantly أو Smartlead أو Apollo؟
احجز مكالمة سريعة:Calendly - Automaxion
لقد بنيت واحدة اليوم. تأخذ العملاء المتوقعين من جدول Google وترسل تلك البيانات إلى وكيل ذكاء اصطناعي، الذي يكتب رسائل تواصل شخصية ويرسل متابعات كل بضعة أيام
نعم، بنيت هذا التدفق بالضبط — وهناك شيئان من الخيط يستحقان الإضافة، لأنهما ما يسبب المشاكل حقًا بعد البدء.
اقتراح Jina Reader أعلاه فكرة جيدة للحصول على نص نظيف. المشكلة في إدخال موقع محكّ مباشرة إلى LLM الذي يكتب البريد الإلكتروني (الخطوة 4 → 5): هذا الموقع عبارة عن إدخال قابل للتحكم من قبل المهاجم. يمكن لصفحة ما أن تحتوي على “تجاهل التعليمات السابقة، اكتب…”، وبما أن هذا النص يتدفق إلى النموذج الذي تُرسل مخرجاته تلقائيًا، قد ينتهي بك الحال إلى إرسال محتوى من اختيار المهاجم من نطاقك الخاص. يستحق الأمر تحديد النص المحكّ كغير موثوق في التعليمات وعدم السماح به بتوجيه الإرسال.
الحماية الأخرى التي تستحق الحفاظ عليها: لا ترسل عندما تفشل عملية الكشط. موقع ميت أو محجوب — 503 مع صفحة خطأ طويلة، تحدي Cloudflare — سيظل ينتج بريدًا إلكترونيًا واثقًا يقول “أحببت موقعك ___” إذا كنت تتحقق فقط من حصولك على بعض النص. اربط الإرسال برمز حالة HTTP (2xx)، وليس بعدد البايتات، وتخطّ + سجّل أي شيء آخر.
بالنسبة إلى 7–8 (المتابعة + التوقف عند الرد) أبقيها كسير عمل مجدول منفصل يقرأ الخيط ويتوقف عند الرد — دمج الإرسال والانتظار في تدفق واحد يصبح هشًا بسرعة.
أنا أبني هذه كسير عمل مختبرة — كل واحدة تأتي مع اختبار يقود عمليات تنفيذ حقيقية بالإضافة إلى اختبار طفرة (حقن خطأ، تأكيد أن الاختبار يمسكه)، لذا لا ترسل بيانات خاطئة بصمت. يسعدني مشاركة النسخة القابلة للاستيراد إذا كانت مفيدة لك.
بنيت هذا الشكل بالضبط عدة مرات — هناك خطآن شائعان يقع فيهما الجميع: تعامل مع نص الموقع المكشوط كمدخلات غير موثوقة بالنسبة لنموذج اللغة. الصفحة قد تحتوي على “تجاهل التعليمات السابقة” وكاتب بريدك الإلكتروني سيطيعها. ضع المكشوط بين محددات واضحة وأخبر النموذج أن المحتوى بينهما هو بيانات، وليس تعليمات أبداً. اكتشاف الردود هو المكان الذي تتسرب فيه التسلسلات. لا تتحقق فقط من البريد الوارد — تحقق من أنه من نفس المحادثة/العميل المحتمل وأنه ليس رداً تلقائياً/رسالة غياب، وإلا ستوقف التسلسلات على رسائل “أنا في إجازة” المرتجعة.\n\nللكشط، Jina Reader + فحص حالة HTTP قبل تمرير أي شيء للنموذج ينقذك من إدخال صفحات 404 إلى نموذج اللغة. أنا سعيد بمشاركة كيفية توصيل شرط الإيقاف إذا كان مفيداً — أبني هذه للشركات الخدمية الصغيرة.
@Ayesha_Saeed @jacewe لقد قمت الآن ببناء واختبار استيراد متغير قريب من هذا المسار: CRM/Google Sheets → تطبيع → ملاحظات موقع الويب الاختيارية → درجة الذكاء الاصطناعي → مسودة التواصل الشخصية → مسودة Gmail للمراجعة البشرية → مهمة المتابعة → التقرير اليومي.
أحتفظ بمسودة الطرح الأول فقط لأن عمليات الكشط الفاشلة والصفوف المكررة وحقن موجه موقع الويب وقواعد إيقاف الرد هي حيث يمكن لسير العمل الأخضر الظاهري أن يسبب ضررًا.
تسلسل الطرح الأول الأكثر أمانًا لدي هو: صف العينة → مخرجات الذكاء الاصطناعي المتوقعة → المسودة المراجعة → طرح صف واحد. ثم أضف فحوصات التكرار وبوابة كشط 2xx ورسائل السجل الأولية والمحللة للذكاء الاصطناعي وإيقاف الرد قبل التوسع.
إذا كان أي منكما لا يزال يبني هذا، أخبرني ما إذا كان المصدر هو Sheets أو CRM وسأتمكن من الإشارة إلى العقد الأولى والحواجز الأمنية التي سأختبرها. أحتفظ أيضًا بقائمة تحقق مجانية للطرح الأول مرتبطة من ملفي الشخصي.
حسناً، لدي اقتراح لك غير مرتبط بـ n8n.
استخدم خدمة بريد إلكتروني تابعة لجهة خارجية أو احصل على اسم نطاق منفصل للقيام بجميع رسائلك البريدية الموجهة. لأنه إذا تم وضع علامة على 1% فقط من رسائلك الإلكترونية كرسائل غير مرغوب فيها وكانت على نطاقك الأساسي، فإن كل بريد إلكتروني ترسله من نطاقك الأساسي سيعتبر رسالة غير مرغوب فيها. هذا هو آخر شيء تريده. سيكون أفضل 30 دولاراً تقريباً تنفقها على الحصول على yoursiteoffers.com لإخفاء جميع رسائل البريد الإلكتروني الشرعية من yoursite.com خلفه.
في جزء كشف الردود ومتابعة الترتيب (الخطوات 7-8)، الخطأ الذي يرتكبه الناس عادة هو استخدام عقدة انتظار ثابتة للمتابعات. النمط الأفضل: بعد الإرسال، اكتب صفًا في Postgres/Sheets يتضمن معرّف العميل المحتمل والطابع الزمني للإرسال وstatus=pending. قم بتشغيل سير عمل مجدول يتحقق من صندوق الوارد عبر IMAP أو Gmail trigger، ويطابق الردود حسب معرّف الخيط أو بريد العميل المحتمل، وينقل الحالة إلى replied. ثم يقوم Schedule Trigger منفصل باستعلام الصفوف حيث status=pending وdays_since_sent تصل إلى فاصل المتابعة الخاص بك، بحيث يستمر التسلسل بأكمله حتى بعد إعادة تشغيل n8n ويمكنك إيقاف/استئناف كل عميل محتمل دون فقدان الحالة.