مطالعه موردی مهندسی
پیام‌رسانی مشتری در بله، روبیکا و ایتا
رسیدن به مشتری ایرانی یعنی بله و روبیکا و ایتا، نه پلتفرم‌هایی که بیشتر ابزارهای پیام‌رسانی فرضشان را گرفته‌اند. هرکدام 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 از کمپین‌هاست. یکی‌کردنشان میان‌بر رایجی است که به بدترین شکل ممکن خراب می‌شود.
ذخیره‌کردن انصراف به‌جای مشتق‌کردنش، از آن تصمیم‌هایی است که زیادی به نظر می‌رسد — تا روزی که دیگر به نظر نمی‌رسد.