IOSOR

IOSOR Viden

SMS-segmentregnskab: derfor er én besked ikke én udgiftspost

Prisguide: GSM-7 vs UCS-2, multipart-konkatenationsoverhead og hvordan du afstemmer hver forsendelse med den forudbetalte pung uden gæt.

Brugeren skrev én besked. Den forudbetalte pung debiterede tre enheder. Det er ikke en fejl — det er segmentregnskab, og finance-teams der ikke forstår GSM-7 vs UCS-2 og multipart-konkatering åbner tickets mod en billing-motor der fungerer præcis som designet.

IOSOR behandler hver SMS-udgiftspost som rekonstruerbar til segmentantal, encoding og destination — ikke som et uigennemsigtigt platformgebyr. Nær USD 1.000+ månedlig platformbrug er segmentdisciplin forskellen mellem en ren månedsafstemning og en gentagen eskalering “hvorfor kostede det mere”.

Derfor er én SMS ikke én udgiftspost

Hvad afsenderen ser Hvad pungen ser
“Jeg sendte én tekst” 1–3 fakturerede enheder afhængigt af encoding og længde
Én emoji tilføjet til sidst Hele beskeden skifter til UCS-2
En skabelonvariabel et par tegn længere Beskeden krydser en segmentgrænse

GSM-7 vs UCS-2: derfor ændrer tegnsættet matematikken

  • GSM-7 dækker et begrænset latinsk alfabet og et lille symbolsæt; hvert tegn koster mindre “budget” pr. segment
  • UCS-2 (ethvert tegn uden for GSM-7 — emoji, de fleste ikke-latinske skrifter, noget tegnsætning) tvinger hele beskeden ind i en bredere encoding med lavere tegngrænse pr. segment
  • Ét “usynligt” tegn (smart anførselstegn fra et dokument, et flueben, en emoji) kan stille vende hele beskeden fra GSM-7 til UCS-2

Multipart-segmentering og konkatenationsoverhead

Encoding Grænse for ét segment Grænse i multipart Hvorfor multipart er mindre
GSM-7 160 tegn 153 tegn Konkatenationsheaderen reserverer plads
UCS-2 70 tegn 67 tegn Samme header, mindre alfabetbudget

At krydse grænsen for ét segment “afrunder” ikke elegant — beskeden deles i flere segmenter, hver med konkatenationsoverhead, og genfaktureres tilsvarende.

Hvor segmentantal gemmer sig

  • En composer-forhåndsvisning viser “1 besked” mens den reelle encoding giver 2–3 fakturerede segmenter
  • Skabelonvariabler der skubber længden over en grænse kun for nogle modtagere
  • Locale-specifikke tegn (accenter, ikke-latinske skrifter) der klarer QA på ét sprog og multiplicerer omkostning på et andet

Hver debetlinje bør vise: destination, beskedlængde, registreret encoding, segmentantal og enhedstakst — ikke et blandet “SMS-gebyr”. Hvis finance ikke kan mappe en pungdebet til de fem felter, er ledgeret ikke afstemmeligt — man stoler på det i tro.

  1. Estimér encoding og segmentantal før afsendelse med de samme regler som pungen vil fakturere efter
  2. Advar — tillad ikke stille — når en skabelonredigering krydser en segmentgrænse
  3. Vis encoding i composeren, ikke kun tegnantal
  4. Test med rigtige modtagerlocales, ikke kun forfattersproget

Røde flag

  • Composer eller API-svar rapporterer beskedantal i stedet for segmentantal
  • Ingen synlighed for hvilken encoding en specifik afsendelse brugte
  • Support siger “encodingproblemer er sjældne, bare rolig”
  • Ledgerlinjer der ikke kan spores tilbage til længde, encoding og destination
  • Bulk-forsendelser faktureret som flad estimat, først afstemt ved månedsafslutning

Start med IOSOR

Gennemse dine udgående skabelon-payloads i IOSOR-konsollen, før du udløser store udsendelser. Konfigurer API-valideringsporte til at markere enhver payload, der overstiger et enkelt segment eller uventet skifter fra GSM-7 til UCS-2-kodning.

IOSOR-pointe

En enkelt udgående tekstbesked oversætter sjældent til en enkelt udgiftslinje.

Var denne guide nyttig?

Relaterede vejledninger