IOSOR

IOSOR Kennis

SMS-segmentboekhouding: waarom één bericht geen één kostenregel is

Prijsleidraad: GSM-7 vs UCS-2, multipart-concatenatie-overhead en hoe je elke verzending afstemt op de prepaid wallet zonder te gokken.

De gebruiker typte één bericht. De prepaid wallet debiteerde drie eenheden. Dat is geen bug — het is segmentboekhouding, en finance-teams die GSM-7 vs UCS-2 en multipart-concatenatie niet begrijpen, openen tickets tegen een factureringsmotor die precies werkt zoals ontworpen.

IOSOR behandelt elke SMS-kostenregel als reconstrueerbaar tot segmenttelling, encoding en bestemming — niet als een ondoorzichtige platformfee. Rond USD 1.000+ maandelijks platformgebruik is segmentdiscipline het verschil tussen een schone maandafstemming en een terugkerende escalatie “waarom was dit duurder”.

Waarom één SMS geen één kostenregel is

Wat de afzender ziet Wat de wallet ziet
“Ik stuurde één tekst” 1–3 gefactureerde eenheden afhankelijk van encoding en lengte
Eén emoji aan het eind toegevoegd Het hele bericht schakelt naar UCS-2
Een templatesvariabele een paar tekens langer Het bericht kruist een segmentgrens

GSM-7 vs UCS-2: waarom de tekenset de wiskunde verandert

  • GSM-7 dekt een beperkt Latijns alfabet en een kleine symbolenset; elk teken kost minder “budget” per segment
  • UCS-2 (elk teken buiten GSM-7 — emoji, de meeste niet-Latijnse schriften, sommige leestekens) dwingt het hele bericht in een bredere encoding met een lagere tekenlimiet per segment
  • Eén “onzichtbaar” teken (slim aanhalingsteken uit een document, een vinkje, een emoji) kan stilletjes het hele bericht van GSM-7 naar UCS-2 flippen

Multipart-segmentatie en concatenatie-overhead

Encoding Limiet één segment Limiet in multipart Waarom multipart kleiner is
GSM-7 160 tekens 153 tekens Concatenatieheader reserveert ruimte
UCS-2 70 tekens 67 tekens Dezelfde header, kleiner alfabetbudget

Een enkele segmentlimiet overschrijden “rondt” niet netjes af — het bericht splijt in meerdere segmenten, elk met concatenatie-overhead, en wordt dienovereenkomstig herberekend.

Waar segmenttellingen zich verbergen

  • Een composervoorbeeld toont “1 bericht” terwijl de echte encoding 2–3 gefactureerde segmenten oplevert
  • Templatesvariabelen die de lengte alleen voor sommige ontvangers over een grens duwen
  • Locale-specifieke tekens (accenten, niet-Latijnse schriften) die QA in één taal doorstaan en kosten in een andere vermenigvuldigen
  1. Schat encoding en segmenttelling vóór verzending met dezelfde regels als de wallet zal gebruiken
  2. Waarschuw — sta niet stilzwijgend toe — wanneer een templatebewerking een segmentgrens kruist
  3. Toon encoding in de composer, niet alleen tekentelling
  4. Test met echte ontvangerslocales, niet alleen de schrijftaal

Segmenttelling, encoding, bestemmingszone en eenheidsprijs — consistent of de verzending van een API-call, bulkcampagne of workshoptest kwam. Een prepaid ledger dat alleen “SMS” en een totaal zegt is een black box met een bon-omslag.

Segmenten afstemmen op de prepaid wallet

Elke debetregel moet tonen: bestemming, berichtlengte, gedetecteerde encoding, segmenttelling en eenheidstarief — geen gemengde “SMS-fee”. Als finance een wallet-debet niet naar die vijf velden kan mappen, is het ledger niet afstelbaar: men vertrouwt het op geloof.

Begin met IOSOR

Controleer je uitgaande sjabloonladingen in de IOSOR-console voordat je grote verzendingen start. Configureer API-validatieregels om ladingen te markeren die een enkel segment overschrijden of onverwacht overstappen van GSM-7 naar UCS-2-codering.

IOSOR-les

Een enkel uitgaand tekstbericht vertaalt zich zelden naar een enkel kostenoverzicht.

Was deze gids nuttig?

Gerelateerde gidsen