IOSOR

IOSOR Guías

Contabilidad de segmentos SMS: por qué un mensaje no es una sola línea de gasto

Guía de precios: GSM-7 vs UCS-2, overhead de concatenación multipart y cómo conciliar cada envío con la billetera prepaga sin adivinar.

El usuario escribió un mensaje. La billetera prepaga debitó tres unidades. Eso no es un bug: es contabilidad de segmentos, y los equipos de finanzas que no entienden GSM-7 vs UCS-2 ni la concatenación multipart abren tickets contra un motor de facturación que funciona exactamente como está diseñado.

IOSOR trata cada línea de gasto SMS como reconstruible hasta conteo de segmentos, encoding y destino — no como una tarifa opaca de plataforma. Cerca de USD 1.000+ de uso mensual de plataforma, la disciplina de segmentos es la diferencia entre una conciliación limpia y una escalada recurrente de “por qué costó más”.

Por qué un SMS no es una sola línea de gasto

Lo que ve el remitente Lo que ve la billetera
“Envié un texto” 1–3 unidades facturadas según encoding y longitud
Se añadió un emoji al final Todo el mensaje pasa a UCS-2
Una variable de plantilla unos caracteres más larga El mensaje cruza un límite de segmento

GSM-7 vs UCS-2: por qué el juego de caracteres cambia la matemática

  • GSM-7 cubre un alfabeto latino limitado y un conjunto pequeño de símbolos; cada carácter consume menos “presupuesto” por segmento
  • UCS-2 (cualquier carácter fuera de GSM-7 — emoji, la mayoría de escrituras no latinas, cierta puntuación) fuerza todo el mensaje a un encoding más ancho con menor límite por segmento
  • Un carácter “invisible” (comilla tipográfica pegada de un documento, un checkmark, un emoji) puede cambiar en silencio todo el mensaje de GSM-7 a UCS-2

Segmentación multipart y overhead de concatenación

Encoding Límite de un segmento Límite en multipart Por qué multipart es menor
GSM-7 160 chars 153 chars La cabecera de concatenación reserva espacio
UCS-2 70 chars 67 chars Misma cabecera, menor presupuesto de alfabeto

Cruzar el límite de un solo segmento no “redondea” con elegancia: el mensaje se parte en varios segmentos, cada uno con overhead de concatenación, y se refactura en consecuencia.

Dónde se esconden los conteos de segmentos

  • Una vista previa del compositor muestra “1 mensaje” mientras el encoding real produce 2–3 segmentos facturados
  • Variables de plantilla que empujan la longitud sobre el límite solo para algunos destinatarios
  • Caracteres específicos de locale (acentos, escrituras no latinas) que pasan QA en un idioma y multiplican el coste en otro
  1. Estime encoding y conteo de segmentos antes del envío, con las mismas reglas que usará la billetera
  2. Avise — no permita en silencio — cuando una edición de plantilla cruza un límite de segmento
  3. Muestre el encoding en el compositor, no solo el conteo de caracteres
  4. Pruebe con locales reales de destinatario, no solo con el idioma de autoría

Conciliar segmentos con la billetera prepaga

Cada línea de débito debe mostrar: destino, longitud del mensaje, encoding detectado, conteo de segmentos y tarifa unitaria — no una “tarifa SMS” mezclada. Si finanzas no puede mapear un débito a esos cinco campos, el ledger no es conciliable: se confía por fe.

Comience con IOSOR

Revisa las cargas útiles de tus plantillas salientes en la consola de IOSOR antes de activar grandes envíos. Configura puertas de validación en la interfaz de programación para marcar cualquier carga que supere un único segmento o cambie de forma imprevista la codificación GSM-7 a UCS-2.

Conclusión IOSOR

Un solo mensaje de texto saliente rara vez se traduce en una única línea de gasto.

¿Fue útil esta guía?

Guías relacionadas