IOSOR

IOSOR Знания

Отчетите трябва да съответстват на DLR, а не на броя изпращания

Изпратено не означава доставено. Износът на отчети за финансите и продукта трябва да следва DLR потвържденията — никога не фактурирайте седмица само въз основа на общо приети за изпращане съобщения.

Броят изпращания създава фалшиво успокоение: API е приел съобщението, така че седмицата е 'успешна'. Това успокоение обаче се срива през седмицата за фактуриране. Отчет, който отчита изпращанията като успех, ще противоречи на DLR потвържденията, дебитирането на портфейла за многосегментен трафик и проверките на уебхук.

IOSOR налага правилото: износът на отчети следва потвържденията за доставка. Изпратено, на опашка и прието за изпращане остават оперативни следи. Доставено, неуспешно и неизвестно са колоните, за които финансите и продуктът дискутират.

Изпратено е следа, а не метрика за приключване

Приемането за изпращане доказва само, че системата е поела задачата. То не доказва, че телефонът на получателя е получил SMS съобщението. Ако основният KPI на вашия пакет отчети е броят изпращания, ще надценявате успеха всеки път, когато делът на неизвестните или неуспешните съобщения се увеличи. Запазете изпратено като колона за капацитет, ако е полезно — но никога като заместител на доставено.

Колоните за износ следват потвържденията

Схемата за износ именува състоянията на потвърждение изрично. Доставено изисква DLR. Неуспешно изисква краен сигнал за грешка. Неизвестно остава неизвестно, докато не пристигне потвърждение — то не е меко доставено състояние. Седмиците за фактуриране, които крият неизвестното в успеха, създават класическия спор за недоставения дял.

Съгласувайте уебхук логовете и главната книга спрямо същите потвърждения

Съгласуването на одита на уебхук спрямо износа на главната книга е начинът да докажете, че отчетът не е измислица. Дневните логове на уебхук, състоянията на DLR и редовете в предплатената главна книга трябва да разказват една и съща история. Ако уебхук показват неуспех, докато отчетът показва успех, отчетът е грешен — коригирайте износа, а не 'нагласяйте' портфейла.

Отказвайте седмици за фактуриране въз основа на изпращания

Всяко приключване, което фактурира или отчита успех само въз основа на броя изпращания, се блокира. Пренапишете пакета така, че финансите да се фокусират върху дела на доставените и неизвестните съобщения. Ако договор с партньор все още споменава 'успешни API изпращания', преведете този език в бележки за DLR — не огъвайте колоните, за да паснат на грешна формулировка.

Свързани оперативни пътища

Започнете с IOSOR

Отворете седмичния пакет отчети в конзолата IOSOR и потвърдете, че всеки KPI в заглавието е върху DLR разписки — delivered, failed и unknown — не върху submit или API accept. Ако графика все още брои submit като успех, преименувайте или махнете преди финансовото затваряне. Експортирайте веднъж и споделете същите колони с разписки между продукт и финанси.

Обобщение IOSOR

Отчетите се затварят с DLR разписки: delivered, failed и unknown — не със submit. Submit е само throughput, никога истина за доставка или аргумент за фактура.

Правете: една схема за експорт върху полетата на разписката. Не: продуктът празнува accept, а финансите спорят за failed DLR.

Полезно ли беше ръководството?

Свързани ръководства