Raporty muszą odpowiadać DLR, a nie liczbie wysyłek

Liczba wysłanych wiadomości daje fałszywe poczucie bezpieczeństwa: API przyjęło żądanie, więc tydzień wydaje się udany. To złudzenie pryska podczas rozliczenia finansowego. Raport, który traktuje samo wysłanie jako sukces, będzie niezgodny z raportami DLR, obciążeniami portfela za wiadomości wielosegmentowe i audytem webhooków.

Platforma IOSOR wymusza jasną zasadę: eksport raportów bazuje wyłącznie na potwierdzeniach dostarczenia. Statusy wysłane, w kolejce oraz przyjęte do wysyłki pozostają jedynie śladami operacyjnymi. Dostarczone, błędne oraz nieznane to jedyne kolumny, o które opierają się finanse i rozwój produktu.

Wysłanie to ślad operacyjny, a nie wskaźnik zamknięcia

Przyjęcie wiadomości do wysyłki dowodzi jedynie, że system przetworzył zadanie. Nie jest to dowód, że aparat odbiorcy otrzymał SMS. Jeśli głównym wskaźnikiem KPI w Twoim pakiecie raportów jest liczba wysyłek, sukces zostanie zawyżony przy każdym wzroście udziału błędów lub statusów nieznanych. Zachowaj status wysłano jako kolumnę przepustowości, ale nigdy nie używaj go jako zamiennika dostarczenia.

Kolumny eksportu wynikają z potwierdzeń

Struktura eksportu jednoznacznie nazywa statusy odbioru. Status dostarczono wymaga potwierdzenia DLR. Status błąd wymaga końcowego sygnału niepowodzenia. Status nieznany pozostaje nieznany do momentu nadejścia raportu — nie jest to miękkie dostarczenie. Rozliczenia tygodniowe ukrywające nieznane statusy w kategorii sukcesu prowadzą do sporów o rzeczywisty udział dostarczonych wiadomości.

Uzgadniaj webhooki i księgę na podstawie tych samych DLR

Uzgadnianie audytu webhooków z eksportem księgi głównej pozwala udowodnić, że raport odpowiada rzeczywistości. Dzienniki webhooków, statusy DLR i wpisy w księdze przedpłaconej muszą tworzyć jedną spójną całość. Jeśli webhook wskazuje błąd, a raport wykazuje sukces, raport jest błędny — należy poprawić eksport, a nie modyfikować saldo portfela.

Odrzucaj rozliczenia oparte na liczbie wysyłek

Każde zamknięcie tygodnia, które fakturuje lub raportuje sukces wyłącznie na podstawie liczby wysyłek, musi zostać zablokowane. Przeprojektuj pakiet raportów, aby finanse analizowały udział wiadomości dostarczonych i nieznanych. Jeśli umowa z partnerem nadal wspomnia o pomyślnych wysyłkach API, przetłumacz te zapisy na adnotacje DLR, zamiast naginać kolumny do błędnej terminologii.

Powiązane ścieżki operacyjne

• Tydzien faktury DLR: nieznany udział nie dostarczony
• Uzgadnianie dziennych logów webhook z saldem przedpłaconym
• Tydzień faktur rozliczeniowych SMS: gdy matematyka segmentów mija się z rachu…

Zacznij z IOSOR

Otwórz tygodniowy pakiet raportów w konsoli IOSOR i upewnij się, że każdy KPI w nagłówku opiera się na potwierdzeniach DLR — delivered, failed i unknown — a nie na submitach ani acceptach API. Jeśli wykres nadal traktuje submit jako sukces, zmień nazwę lub usuń go przed zamknięciem finansów. Wyeksportuj raz i udostępnij te same kolumny potwierdzeń produktowi i finansom.

Podsumowanie IOSOR

Raporty zamyka się na potwierdzeniach DLR: delivered, failed i unknown — nie na submitach. Submit to tylko throughput, nigdy prawda dostawy ani argument do faktury.

Rób: jeden schemat eksportu na pola potwierdzeń. Nie rób: produkt świętuje accepty, a finanse kłócą się o failed DLR.