مطالعه موردی مهندسی
پیامرسانی مشتری در بله، روبیکا و ایتا
رسیدن به مشتری در ایران یعنی بله، روبیکا و ایتا نه پلتفرمهایی که بیشتر ابزارهای پیامرسانی فرض میکنند. هرکدام API خودش و رفتار شکست خودش را دارد، و هیچکدام نباید برای کدی که تصمیم میگیرد چه چیزی فرستاده شود قابلدیدن باشند.
مسئله تجاری
یکپارچهسازیهای پیامرسانی وقتی جزئیات ارائهدهنده به منطق کسبوکار نشت میکند میپوسند. یک پلتفرم دوم اضافه کنید و یا کد کمپین را تکرار میکنید یا شرطها را داخلش میبافید. علاوه بر این، پیامرسانی مشتری تعهداتی دارد که فنی نیستند: انصراف باید دائمی رعایت شود، ترافیک OTP نباید مسیرش را با ترافیک کمپین شریک شود، و کسی باید یک قالب را پیش از دریافتش توسط هزاران نفر تأیید کند.
آنچه تحویل دادم
- a2-bale-customer-hub، یک افزونهی وردپرس که رکوردهای مشتری را به گردشکارهای بات بله و پیامرسانی سفیر وصل میکند.
- منطق مخصوص ارائهدهنده جداشده پشت کلاسهای پلتفرم و ارائهدهندهی OTP، تا افزودن یا جایگزینی یک کانال به کد کمپین دست نزند.
- صفهای کمپین با قالبها، تا یک ارسال یک شیء قابل بازبینی باشد نه حلقهای که از قبل شروع شده.
- انصراف ذخیرهشده بهشکل یک رکورد نه استنتاجشده، چون لغو اشتراکی که به درستنوشتهشدن یک کوئری وابسته باشد یک کوئری بد با یک مشکل انطباق فاصله دارد.
- ایمپورت مخاطب با یکپارچهسازی منابع مخاطب ووکامرس و CRM جایی که در دسترس باشند.
- مدیریت درخواست پشتیبانی روی همان رکوردهای مشتری، تا یک پرسش ورودی و یک کمپین خروجی نمای مشترکی از مشتری داشته باشند.
رویکرد فنی
- مرز ارائهدهنده خودِ معماری است. هرچه بالای آن است دربارهی مشتری، قالب و صف حرف میزند؛ هرچه زیرش است API یک پلتفرم را میشناسد.
- OTP پشت انتزاع ارائهدهندهی خودش نگه داشته میشود، جدا از پیامرسانی کمپین، چون این دو فوریت متفاوت، مدیریت شکست متفاوت و پیامدهای متفاوتی هنگام اشتباهگرفتن دارند.
- صف بهجای ارسال مستقیم، تا یک کمپین قابل بازرسی، توقف و استدلال باشد نه درخواستی که یا تمام شد یا نشد.
- انصراف در زمان ارسال بهعنوان یک رکورد مثبت بررسی میشود. هر چیزی کمتر از این، درستی را به دقیقنوشتهشدن هر کوئری آینده وابسته میکند.
- توکنها، رازهای وبهوک و خروجیهای مخاطب طبق سیاست از مخزن حذف شدهاند، و توصیف عمومی این کار به همین دلیل در سطح معماری میماند.
نتیجه و شواهد
پیامرسانی مشتری روی پلتفرمهای ایرانیای که کسبوکار واقعاً لازم دارد اجرا میشود، با جزئیات ارائهدهنده مهارشده و قوانین محافظت از مشتری اجراشده بهشکل ساختاری نه قراردادی.
اهمیت برای کارفرما
پیامرسانی جایی است که یک کسبوکار تجاری سریعترین آسیب را به رابطهاش با مشتری میزند. ساختن مرحلهی بازبینی و رکورد انصراف از ابتدا خیلی ارزانتر از اضافهکردنشان بعد از یک حادثه است.
خلاصه اجرایی خوانا
خلاصه_اجرایی {
پروژه: "Bale / Rubika / Eitaa Customer Messaging"
افزونه: "a2-bale-customer-hub (وردپرس، PHP 7.4+)"
مرز: "کلاسهای پلتفرم + ارائهدهندهی OTP؛ کد کمپین
هیچوقت API یک ارائهدهنده را نمیبیند"
otp: "انتزاع ارائهدهندهی جدا از ارسالهای کمپین"
صفها: "کمپینها اشیای قابل بازرسیاند، نه حلقه"
انصراف: "رکورد ذخیرهشده، بررسی در زمان ارسال؛ هرگز استنتاج"
منابع: "ایمپورت مخاطب از ووکامرس + CRM"
خارج_از_مخزن: "توکن، راز وبهوک، راز OTP،
فهرست مخاطب، خروجی، لاگ"
}ارزش حرفهای این پروژه
مرز آداپتور یک شیوهی خوب معمولی است؛ چیزی که به آن اشاره میکنم گذاشتن OTP پشت ارائهدهندهای جدا از کمپینهاست. قاطیکردنشان یک میانبر رایج است و به بدترین شکل ممکن شکست میخورد.
برخورد با انصراف بهعنوان وضعیت ذخیرهشده نه یک شرط مشتقشده، از آن تصمیمهایی است که تا روزی که نباشد افراطی بهنظر میرسد.