IOSOR

IOSOR Ghiduri

Contabilitatea segmentelor SMS: de ce un mesaj nu este o singură linie de cheltuială

Ghid de prețuri: GSM-7 vs UCS-2, overhead de concatenare multipart și cum reconciliați fiecare trimitere cu portofelul prepaid fără ghicitori.

Utilizatorul a tastat un mesaj. Portofelul prepaid a debitat trei unități. Nu este un bug — este contabilitatea segmentelor, iar echipele de finanțe care nu înțeleg GSM-7 vs UCS-2 și concatenarea multipart deschid tichete împotriva unui motor de facturare care funcționează exact așa cum a fost proiectat.

IOSOR tratează fiecare linie de cheltuială SMS ca fiind reconstruibilă până la numărul de segmente, encoding și destinație — nu ca un comision opac de platformă. Aproape de USD 1.000+ utilizare lunară a platformei, disciplina segmentelor este diferența dintre o reconciliere lunară curată și o escaladare recurentă „de ce a costat mai mult”.

De ce un SMS nu este o singură linie de cheltuială

Ce vede expeditorul Ce vede portofelul
„Am trimis un text” 1–3 unități facturate în funcție de encoding și lungime
Un emoji adăugat la final Întregul mesaj trece la UCS-2
O variabilă de șablon cu câteva caractere mai lungă Mesajul trece o limită de segment

GSM-7 vs UCS-2: de ce setul de caractere schimbă matematica

  • GSM-7 acoperă un alfabet latin limitat și un set mic de simboluri; fiecare caracter costă mai puțin „buget” pe segment
  • UCS-2 (orice caracter în afara GSM-7 — emoji, majoritatea scrierilor non-latine, anumită punctuație) forțează întregul mesaj într-un encoding mai larg cu limită mai mică pe segment
  • Un caracter „invizibil” (ghilimele inteligente dintr-un document, o bifă, un emoji) poate răsuci în tăcere întregul mesaj din GSM-7 în UCS-2

Segmentare multipart și overhead de concatenare

Encoding Limita unui segment Limita în multipart De ce multipart este mai mic
GSM-7 160 caractere 153 caractere Antetul de concatenare rezervă spațiu
UCS-2 70 caractere 67 caractere Același antet, buget alfabetic mai mic

Depășirea limitei unui singur segment nu „rotunjește” elegant — mesajul se împarte în mai multe segmente, fiecare cu overhead de concatenare, și se refactorizează corespunzător.

Unde se ascund numărările de segmente

  • O previzualizare în composer arată „1 mesaj” în timp ce encoding-ul real produce 2–3 segmente facturate
  • Variabile de șablon care împing lungimea peste o limită doar pentru unii destinatari
  • Caractere specifice locale (accente, scrieri non-latine) care trec QA într-o limbă și înmulțesc costul în alta
  1. Estimați encoding-ul și numărul de segmente înainte de trimitere cu aceleași reguli pe care le va factura portofelul
  2. Avertizați — nu permiteți în tăcere — când o editare de șablon trece o limită de segment
  3. Afișați encoding-ul în composer, nu doar numărul de caractere
  4. Testați cu locale reale ale destinatariilor, nu doar limba de scriere

Reconcilierea segmentelor cu portofelul prepaid

Fiecare linie de debit ar trebui să arate: destinație, lungimea mesajului, encoding detectat, număr de segmente și tarif unitar — nu o „taxă SMS” amestecată. Dacă finanțele nu pot mapa un debit din portofel la aceste cinci câmpuri, ledger-ul nu este reconciliabil — se are încredere prin credință.

Începeți cu IOSOR

Verifică șabloanele de expediere în consola IOSOR înainte de a iniția trimiteri masive. Configurează filtre de validare prin API pentru a semnala orice mesaj care depășește un singur segment sau trece neașteptat de la codificarea GSM-7 la UCS-2.

Rezumat IOSOR

Un singur mesaj text trimis rareori se traduce într-o singură linie de cost.

A fost util acest ghid?

Ghiduri conexe