Звіти мають збігатися з DLR, а не з submit

Лічильники submit заспокоюють: API прийняв повідомлення, тож тиждень «спрацював». Цей спокій ламає invoice-тижні. Звіт, що рахує submit як success, розійдеться з DLR receipts, debit гаманця на multi-segment і webhook-аудитами.

IOSOR фіксує правило: export звітів слідує delivery receipts. Submitted, queued і accepted-for-send — операційні хлібні крихти. Delivered, failed і unknown — колонки, про які сперечаються finance і product.

Submitted — крихта, не метрика close

Accept-for-send доводить, що шлях узяв задачу. Він не доводить, що SMS дійшов до handset. Якщо headline KPI пака — submits, ви завищите success, коли росте частка unknown або failed. Залиште submit колонкою throughput за потреби — ніколи як proxy delivered.

Тренуйте ритуал close: спочатку колонки DLR. Запитайте, яка частка ще unknown, що failed, що delivered. Лише потім дивіться submits, чи виріс обсяг. Launch-рев’ю product йдуть у тому ж порядку, щоб marketing-слайди не перевизначали success серед тижня.

Колонки export слідують receipts

Схема export явно іменує стани receipt. Delivered потребує DLR. Failed — термінальний сигнал відмови. Unknown лишається unknown, доки не прийшов receipt — це не м’який delivered. Invoice-тижні, що ховають unknown всередині success, народжують класичну суперечку «unknown share не delivered».

Коли математика сегментів розходиться з рахунком, починайте з рядків на receipts і сегментів на цих рядках — не з submit totals, помножених на середній guess сегментів. Шлях mismatch сегментів SMS-invoice поруч; звіт усе одно відмовляє submit-as-delivered.

Звіряйте webhooks і ledger за тими ж receipts

Звірка webhook-аудиту з ledger export доводить, що звіт не фантазія. Щоденні webhook-логи, статуси DLR і рядки prepaid ledger мають розповідати одну історію. Якщо webhooks показують failed, а звіт — success, винний звіт: лагодьте export, не «підкручуйте» гаманець.

Тримайте аудит нудним: день, receipts із webhook, ledger export, пак звітів, збіг message id. Прогалини — в ops; вигаданий success — власникам схеми.

Відмовтеся від invoice-тижнів на submit

Будь-який close, що білить або святкує лише за submit, блокується. Перепишіть пак так, щоб finance зводив delivered і частку unknown. Якщо партнерський контракт досі каже «successful API submits», перекладіть комерційну мову в DLR-ноти export — не змінюйте колонки під погане формулювання контракту.

Пов’язані шляхи

• Тиждень рахунків DLR: unknown share не delivered
• Звірка webhook-аудиту з ledger export
• Тиждень рахунків SMS: mismatch сегментів

Почніть з IOSOR

Відкрийте тижневий пакет звітів у консолі IOSOR і переконайтеся, що кожен KPI в шапці будується з DLR receipts — delivered, failed і unknown — а не з submit чи accept API. Якщо графік досі вважає успіхом submit, перейменуйте або приберіть його до закриття фінансів. Зробіть один експорт з тими самими колонками receipts для продукту й фінансів.

Підсумок IOSOR

Звіти закриваються за DLR receipts: delivered, failed і unknown — не за submit. Submit лишається лише throughput, не правдою доставки й не аргументом для рахунку.

Робіть: одну схему експорту на поля receipts. Не робіть: продуктові дашборди святкують accept, поки фінанси сперечаються за failed DLR.