IOSOR

IOSOR Guias

Contabilidade de segmentos SMS: por que uma mensagem não é uma única linha de gasto

Guia de pricing: GSM-7 vs UCS-2, overhead de concatenação multipart e como reconciliar cada envio com a carteira pré-paga sem adivinhar.

O utilizador escreveu uma mensagem. A carteira pré-paga debitou três unidades. Isso não é um bug — é contabilidade de segmentos, e as equipas de finanças que não entendem GSM-7 vs UCS-2 nem concatenação multipart abrem tickets contra um motor de faturação que funciona exatamente como foi desenhado.

O IOSOR trata cada linha de gasto SMS como reconstruível até contagem de segmentos, encoding e destino — não como uma taxa opaca de plataforma. Perto de USD 1.000+ de uso mensal de plataforma, a disciplina de segmentos é a diferença entre uma reconciliação mensal limpa e uma escalada recorrente de “porque custou mais”.

Por que um SMS não é uma única linha de gasto

O que o remetente vê O que a carteira vê
“Enviei um texto” 1–3 unidades faturadas conforme encoding e comprimento
Um emoji adicionado no fim A mensagem inteira muda para UCS-2
Uma variável de template alguns caracteres mais longa A mensagem cruza um limite de segmento

GSM-7 vs UCS-2: por que o conjunto de caracteres muda a matemática

  • GSM-7 cobre um alfabeto latino limitado e um conjunto pequeno de símbolos; cada carácter consome menos “orçamento” por segmento
  • UCS-2 (qualquer carácter fora de GSM-7 — emoji, a maioria das escritas não latinas, alguma pontuação) força a mensagem inteira para um encoding mais largo com limite menor por segmento
  • Um carácter “invisível” (aspas tipográficas coladas de um documento, um checkmark, um emoji) pode inverter em silêncio a mensagem inteira de GSM-7 para UCS-2

Segmentação multipart e overhead de concatenação

Encoding Limite de um segmento Limite em multipart Por que multipart é menor
GSM-7 160 car. 153 car. O cabeçalho de concatenação reserva espaço
UCS-2 70 car. 67 car. O mesmo cabeçalho, orçamento de alfabeto menor

Cruzar o limite de um único segmento não “arredonda” com elegância — a mensagem divide-se em vários segmentos, cada um com overhead de concatenação, e é refaturada em conformidade.

Onde se escondem as contagens de segmentos

  • Uma pré-visualização do compositor mostra “1 mensagem” enquanto o encoding real produz 2–3 segmentos faturados
  • Variáveis de template que empurram o comprimento além do limite só para alguns destinatários
  • Caracteres específicos de locale (acentos, escritas não latinas) que passam QA numa língua e multiplicam o custo noutra

Cada linha de débito deve mostrar: destino, comprimento da mensagem, encoding detetado, contagem de segmentos e taxa unitária — não uma “taxa SMS” misturada. Se as finanças não conseguem mapear um débito da carteira a esses cinco campos, o ledger não é reconciliável: confia-se nele por fé.

Sinais de alerta

  • Compositor ou resposta API a reportar contagem de mensagens em vez de segmentos
  • Sem visibilidade de que encoding foi usado num envio concreto
  • O suporte diz “problemas de encoding são raros, não se preocupe”
  • Linhas de ledger que não se conseguem rastrear até comprimento, encoding e destino
  • Envios bulk faturados como estimativa plana e reconciliados só no fim do mês

Comece com a IOSOR

Reveja os payloads dos seus modelos de envio na consola do IOSOR antes de disparar grandes lotes. Configure validações na API para sinalizar qualquer mensagem que exceda um único segmento ou mude inesperadamente de GSM-7 para codificação UCS-2.

Conclusão IOSOR

Uma única mensagem de texto enviada raramente se traduz numa única linha de custo.

Este guia foi útil?

Guias relacionados