من $9,000 شهريًا إلى $700 شهريًا

أعاد بحث العقارات من 50 إلى 500 مشترٍ. كان المسار القديم يولد رسائل تواصل لكل نتيجة قبل أن يختار المستخدم أي شخص للاتصال به.

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

أنشأ SendFlow المسودة الأولى مع ما يصل إلى ثلاث محاولات. قبل Review Gate المسودة أو رفضها، وعدّل Content Rewriter النبرة والتفاصيل، وأنتج Message Humanizer نسختين أو ثلاثًا. شغّلت ثمانية خيوط تنفيذ هذه السلسلة بالتوازي وخزنت المخرجات في قاعدة البيانات قبل أن يضغط أحد Send.

نتيجة البحث
  -> SendFlow (حتى ثلاث محاولات)
  -> Review Gate
  -> Content Rewriter
  -> Message Humanizer (2–3 نسخ)
  -> تخزين كل نتيجة

نفذت السلسلة أربعة إلى خمسة استدعاءات للنموذج لكل مشترٍ. وللبحث الذي يعيد 500 مشترٍ، كان ذلك يعني نحو 2,500 استدعاء قبل اختيار المستخدم لأي مستلم.

تواصل المستخدمون مع نحو 100 مشترٍ من مثال النتائج الـ500. لم تُستخدم قرابة 80% من الرسائل المحسوبة مسبقًا، فبقي نحو 2,000 استدعاء بلا نتيجة يراها المستخدم. كان ضبط المطالبات قادرًا على خفض كلفة كل استدعاء، لكنه لم يكن يبرر تشغيل الاستدعاءات غير المستخدمة.

أعاد البحث المنقح المشترين من دون توليد رسائل تواصل. استدعى إجراء Regenerate with AI صريح وكيلًا متخصصًا واحدًا لجهة الاتصال المختارة. شمل سياق الطلب الموقع والهاتف والاسم الأول لكل من المشتري والمرسل والسوق ونشاط المشتري وسجل المحادثة المنسق ومعرّف المشتري؛ وظلت النتيجة قابلة للتحرير قبل الإرسال.

البحث عن 500 مشترٍ -> توليد 0 رسالة
يختار المستخدم مشتريًا -> تجميع سياق جهة الاتصال والمحادثة
Regenerate with AI -> 1 استدعاء للنموذج
ProgressReporter -> تحديث WebSocket كل ثانيتين
نتيجة قابلة للتحرير -> يقرر المستخدم ما إذا كان سيرسلها

تطوّر التنفيذ. استخدمت إحدى لقطات المستودع طلب REST مباشرًا عند فتح لوحة جهة الاتصال المحددة؛ وفي التدفق اللاحق الموثق في مصدر المقال، لم يُشغّل الإجراء إلا بعد طلب صريح من المستخدم، مع بث التقدم عبر WebSocket. هاتان مرحلتان من المنتج، وليستا مسار شفرة واحدًا يعمل في الوقت نفسه.

ضم المنتج أكثر من 25 إعدادًا لوكلاء متخصصين على gpt-4.1-nano. اختير إعداد واحد لكل طلب؛ ولم تكن هذه سلسلة من 25 وكيلًا. أرسل ProgressReporter تحديثًا عبر WebSocket كل ثانيتين أثناء توليد الرسالة.

أصبح الانتظار مرئيًا بعد نقل التوليد إلى إجراء يبدأه المستخدم بنقرة. أبقيت النتيجة قابلة للتحرير، وأظهرت التقدم، ولم أولّد الرسالة إلا للمستلم الذي اختاره المستخدم.

في المثال الموثق الذي يضم 500 مشترٍ، انخفضت الاستدعاءات من نحو 2,500 إلى نحو 100، أي بنسبة 96%. وانخفض الإنفاق الشهري على النماذج من نحو $9,000 إلى نحو $700. وتعني هذه الأرقام الشهرية المقرّبة خفضًا سنويًا في الإنفاق يبلغ نحو $100,000.

أزال التغيير أيضًا 1,218 سطرًا، منها معالج الدفعات المكون من 640 سطرًا. وحذف ذلك المسار عمليات إعادة المحاولة والعمّال والحفظ الدائم والتنسيق متعدد الوكلاء التابعة له.

• قس مقدار المخرجات المولدة التي يستخدمها المستخدمون فعلًا.
• ضع العمل المكلف خلف حدث المنتج الذي يحتاج إليه.
• استخدم تقدمًا مرئيًا عندما لا ينتهي العمل عند الطلب فورًا.
• احذف بنية الدفعات بعد أن يتوقف المنتج عن الاعتماد عليها.