گزارش‌ها باید با DLR مطابقت داشته باشند، نه آمار ارسال اولیه

آمار ارسال اولیه حس کاذبی از موفقیت ایجاد می‌کند: API پیام را پذیرفته است، پس هفته موفقیت‌آمیز به نظر می‌رسد. اما این حس در زمان بسته شدن حساب‌های مالی از بین می‌رود. گزارش‌هایی که ارسال اولیه را موفقیت تلقی می‌کنند، با رسیدهای DLR، کسر موجودی کیف پول و حسابرسی وب‌هوک‌ها مغایرت خواهند داشت.

سیستم IOSOR یک قانون قاطع دارد: خروجی گزارش‌ها همواره از رسیدهای تحویل (DLR) پیروی می‌کنند. وضعیت‌های ارسال شده، در صف و پذیرفته‌شده صرفاً ردپای عملیاتی هستند. تحویل‌شده، ناموفق و ناشناخته تنها ستون‌هایی هستند که تیم‌های مالی و محصول بر اساس آنها تصمیم‌گیری می‌کنند.

ارسال اولیه یک ردپای عملیاتی است، نه متریک نهایی

پذیرش پیام برای ارسال تنها ثابت می‌کند که سیستم درخواست را دریافت کرده است. این امر به معنای دریافت SMS توسط دستگاه گیرنده نیست. اگر KPI اصلی گزارش شما آمار ارسال اولیه باشد، با افزایش سهم پیام‌های ناموفق یا ناشناخته، میزان موفقیت را بیش از حد واقعی برآورد خواهید کرد.

روال بستن حساب‌ها را اصلاح کنید: ابتدا ستون‌های DLR (ناشناخته، ناموفق، تحویل‌شده) را بررسی کنید و سپس نگاهی به حجم کل ارسال‌ها بیندازید. بررسی‌های محصول نیز باید از همین ترتیب پیروی کنند تا گزارش‌های بازاریابی تعریف موفقیت را تغییر ندهند.

ستون‌های خروجی از رسیدها پیروی می‌کنند

ساختار خروجی گزارش‌ها وضعیت رسیدها را شفاف می‌کند. وضعیت تحویل‌شده نیازمند DLR معتبر است. وضعیت ناموفق نیازمند سیگنال قطعی شکست است. وضعیت ناشناخته تا زمان دریافت رسید، ناشناخته باقی می‌ماند و تحویل موفق محسوب نمی‌شود.

هنگامی که محاسبات بخش‌های پیامک و فاکتور نهایی مغایرت دارند، بررسی را از ردیف‌های دارای DLR آغاز کنید، نه از ضرب آمار ارسال اولیه در میانگین تخمینی.

تطبیق وب‌هوک‌ها و دفتر کل بر اساس یک رسید واحد

تطبیق حسابرسی وب‌هوک با خروجی دفتر کل تنها راه اثبات واقعی بودن گزارش است. گزارش‌های روزانه وب‌هوک، وضعیت‌های DLR و تراکنش‌های دفتر کل پیش‌پرداخت باید یک روایت یکسان ارائه دهند. اگر وب‌هوک شکست را نشان دهد اما گزارش موفقیت را ثبت کند، گزارش اشتباه است — خروجی گزارش را اصلاح کنید و موجودی کیف پول را دستی تغییر ندهید.

روال حسابرسی را منظم نگه دارید: یک روز را انتخاب کنید، رسیدهای وب‌هوک، خروجی دفتر کل و گزارش‌ها را بر اساس شناسه پیام تطبیق دهید.

رد صورتحساب‌های مبتنی بر آمار ارسال اولیه

هرگونه بستن حسابی که بر اساس آمار ارسال اولیه صورتحساب صادر کند باید مسدود شود. ساختار گزارش را بازنویسی کنید تا تیم مالی سهم تحویل‌شده و ناشناخته را تحلیل کند.

مسیرهای عملیاتی مرتبط

• هفته فاکتور DLR: سهم ناشناخته تحویل داده نمی شود
• تطبیق گزارش‌های روزانه وب‌هوک با موجودی پیش‌پرداخت
• صورتحساب هفتگی پیامک: وقتی محاسبات بخش و صورتحساب با هم نمی‌خوانند

شروع با IOSOR

بسته گزارش این هفته را در کنسول IOSOR باز کنید و مطمئن شوید هر KPI سرفصل بر اساس رسیدهای DLR — delivered، failed و unknown — است نه submit یا accept API. اگر نموداری هنوز submit را موفقیت می‌داند، قبل از بستن مالی نامش را عوض یا حذف کنید. یک‌بار خروجی بگیرید و همان ستون‌های رسید را بین محصول و مالی مشترک کنید.

جمع‌بندی IOSOR

گزارش‌ها با رسید DLR بسته می‌شوند: delivered، failed و unknown — نه با submit. submit فقط throughput است، نه حقیقت تحویل و نه استدلال صورتحساب.

انجام دهید: یک طرح خروجی قفل‌شده روی فیلدهای رسید. نکنید: محصول accept جشن بگیرد و مالی روی failed DLR دعوا کند.