IOSOR

IOSOR Znalosti

Účetnictví SMS segmentů: proč jedna zpráva není jedna výdajová řádka

Cenový průvodce: GSM-7 vs UCS-2, režie multipart konkatenace a jak sladit každou odesílku s předplacenou peněženkou bez tipování.

Uživatel napsal jednu zprávu. Předplacená peněženka odepsala tři jednotky. To není bug — je to účetnictví segmentů a finance týmy, které nerozumí GSM-7 vs UCS-2 ani multipart konkatenaci, otevírají tickety proti billing enginu, který funguje přesně podle návrhu.

IOSOR bere každou výdajovou řádku SMS jako rekonstruovatelnou až k počtu segmentů, kódování a destinaci — ne jako neprůhledný poplatek platformy. Blízko USD 1 000+ měsíčního použití platformy je disciplína segmentů rozdíl mezi čistou měsíční rekonciliací a opakovanou eskalací „proč to stálo víc“.

Proč jedna SMS není jedna výdajová řádka

Co vidí odesílatel Co vidí peněženka
„Poslal jsem jeden text“ 1–3 účtované jednotky podle kódování a délky
Na konec přidáno emoji Celá zpráva přepne na UCS-2
Proměnná šablony o pár znaků delší Zpráva překročí hranici segmentu

GSM-7 vs UCS-2: proč znaková sada mění matematiku

  • GSM-7 pokrývá omezenou latinku a malou sadu symbolů; každý znak stojí méně „rozpočtu“ na segment
  • UCS-2 (jakýkoli znak mimo GSM-7 — emoji, většina nelatinských písem, některá interpunkce) tlačí celou zprávu do širšího kódování s nižším limitem znaků na segment
  • Jeden „neviditelný“ znak (chytré uvozovky z dokumentu, fajfka, emoji) může tiše překlopit celou zprávu z GSM-7 na UCS-2

Multipart segmentace a režie konkatenace

Kódování Limit jednoho segmentu Limit v multipart Proč je multipart menší
GSM-7 160 znaků 153 znaků Hlavička konkatenace rezervuje místo
UCS-2 70 znaků 67 znaků Stejná hlavička, menší abecední rozpočet

Překročení limitu jednoho segmentu se „nezaokrouhlí“ elegantně — zpráva se rozdělí na více segmentů, každý s režií konkatenace, a odpovídajícím způsobem se přefakturuje.

Kde se skrývají počty segmentů

  • Náhled v composeru ukáže „1 zpráva“, zatímco reálné kódování dá 2–3 účtované segmenty
  • Proměnné šablony, které tlačí délku přes hranici jen u části příjemců
  • Znaky specifické pro locale (diakritika, nelatinská písma), které projdou QA v jednom jazyce a znásobí náklad v jiném

Každá debetní řádka by měla ukazovat: destinaci, délku zprávy, detekované kódování, počet segmentů a jednotkovou sazbu — ne smíšený „SMS poplatek“. Pokud finance neumí namapovat debet peněženky na těchto pět polí, ledger není sladitelný — věří se mu vírou.

  1. Odhadněte kódování a počet segmentů před odesláním podle stejných pravidel, podle kterých bude peněženka účtovat
  2. Varujte — netolerujte tiše — když úprava šablony překročí hranici segmentu
  3. Zobrazte kódování v composeru, nejen počet znaků
  4. Testujte na reálných locale příjemců, nejen v jazyce authoringu

Počet segmentů, kódování, zóna destinace a jednotková cena — konzistentně ať odesílka přišla z API volání, bulk kampaně nebo workshop testu. Prepaid ledger, který říká jen „SMS“ a součet, je černá skříňka s obalem účtenky.

Červené vlajky

  • Composer nebo odpověď API hlásí počet zpráv místo segmentů
  • Není vidět, které kódování použila konkrétní odesílka
  • Support říká „problémy s kódováním jsou vzácné, nebojte se“
  • Řádky ledgeru, které nelze vysledovat k délce, kódování a destinaci
  • Bulk odesílky účtované jako plochý odhad, sladěné až na konci měsíce

Začněte s IOSOR

Zkontrolujte šablony odchozích zpráv v konzoli IOSOR před spuštěním hromadného rozesílání. Nastavte validaci API tak, aby zachytila každý text, který přesáhne jednu část nebo nečekaně přepne z kódování GSM-7 na UCS-2.

Shrnutí IOSOR

Jediná odchozí textová zpráva málokdy odpovídá jedné položce v nákladech.

Byl tento průvodce užitečný?

Související průvodci