IOSOR Ghiduri
Săptămâna incidentelor DID: mesageria down nu este activată
Cum să gestionați primul incident de mesagerie DID în timpul unei căderi, gestionați reținerile preplătite și comunicați statusuri corecte.
Săptămâna incidentelor DID.
Mesageria down înseamnă eșec de rutare, nu stoc epuizat
Când mesageria eșuează pe un număr nou alocat, primul instinct ar putea fi să verificați inventarul sau alertele de reaprovizionare. În operațiunile CPaaS white-label, nu există depozit sau raft fizic. Numerele sunt instanțiate prin provizionare JIT. Dacă livrarea SMS sau OTP se oprește, problema este în tabelele de rutare sau handshake-uri, niciodată într-un coș 'vândut'. Tratați fiecare pană ca pe o excepție live de rețea, nu ca pe o eroare de merchandising.
Înghețare imediată a atribuirilor și cozilor de trimitere
De îndată ce clienții raportează DLR-uri pierdute sau fluxuri OTP tăcute, înghețați imediat atribuirea automată a numerelor și cozile de trimitere cu volum mare. Permiterea scripturilor să continue alocarea rutelor în timpul unei degradări active sporește amploarea impactului. Aplicați o reținere temporară pe soldul preplătit pentru conturile afectate. Comunicați clar că incidentul este în analiză inginerească, menținând intact pragul minim preplătit de 20 USD.
Verificarea pregătirii înainte de a acuza rețeaua
Înainte de a escalada un incident, verificați dacă numărul afectat întrunește cerințele de bază ale protocolului. Multe probleme provin din pașii de validare săriți, menționați în ghidul pregătire mesagerie DID înainte de producție. Verificați statusul de înregistrare 10DLC și răspunsul URL-ului webhook. Dacă headerele returnează erori 5xx, blocajul este pe endpoint-ul aplicației, nu în rețeaua operatorului.
Schimbul, rambursarea sau eliberarea activelor eșuate
Dacă o rută este degradată permanent și nu poate fi recuperată în limitele SLA, nu lăsați clientul în ceață. Executați un schimb curat sau emiteți un credit automat. Revizuiți protocolul pentru eșec comandă DID rambursare și schimb pentru a vă asigura că ajustările de sold sunt corecte. Reținerile preplătite trebuie eliberate imediat pentru ca chiriașul să poată proviziona un activ funcțional.
Predictibilitate financiară după faza de început
Incidente operaționale coincid adesea cu etape de scalare. Odată ce chiriașul trece de testele inițiale și se apropie de revizia de 1.000 USD/lună, tiparele de trafic se mută la campanii A2P susținute. Urmăriți îndeaproape ciclurile DID a doua lună: MRC complet la schimbarea calendarului UTC pentru a vă asigura că taxele recurente și reîncărcările se reconciliază corect fără alerte false.
Începeți cu IOSOR pentru fiabilitate nativă white-label
Când moare DLR sau webhook-ul de mesaje, înghețați coada de trimitere pe acel DID. Nu țineți MT pentru că rândul numărului încă zice assigned. Exportați ora de îngheț, ultimul DLR bun și starea messaging-down. Reluați doar după un smoke viu pe aceleași cifre. Nu e insignă indisponibilă de magazin și nu e dispută de factură.
Rezumat IOSOR
Messaging-down e o înghețare, nu o gaură de inventar.
Faceți: opriți cozile și spuneți tenantilor că mesajele sunt jos. Nu faceți: continuați să trimiteți, nici relabelați DID-ul ca stoc lipsă.
A fost util acest ghid?
Ghiduri conexe
- Predarea DID către al doilea proprietar: cine poate atribui și elibera
Stăpâniți limitele operaționale, provizionarea JIT și pragurile financiare preplătite în timpul predărilor DID către al doilea proprietar.
- Limit de cheltuieli pe DID: Închiriere plus trafic MT pe un număr
Controlați expunerea per număr în CPaaS-ul dvs. white-label cu un plafon combinat de cheltuieli pentru MRC și traficul de terminare mobilă outbound.
- Rutarea webhook-urilor inbound pe DID: MO fără proprietar pierde STOP
Rutați webhook-urile inbound către contul proprietar în mod sigur. Preveniți evenimentele MO orfane și dezabonările ratate în CPaaS prepaid cu etichetă albă.