A billing problem based on assumptions

My partner and I started SingleSend a little over a year ago.

Everything we knew about SMS messages was that we had a 160-character limit, so dividing the number of characters in a message by 160 and rounding up would tell us how many messages to bill for. That held true until we got a $750 bill from Twilio last month which didn’t quite match the sending statistics we saw.

My first thought was malicious actors: I immediately rotated our credentials before taking a look at the logs from Twilio which fortunately, are quite exhaustive. We found no rogue phone numbers in use, and could trace the SMS IDs back to individual campaign message details in our database.

Our Twilio bill did mention something called “segments” which led us to Twilio’s good post on the subject. The short summary is: most SMS messages use an encoding format called GSM-7 for which the 160 characters per message rule mostly holds true: however, once you introduce certain special characters, including emojis, the encoding switches to UCS-2.

Twilio has a very convenient segment calculator that helped troubleshoot.

Here are two sample SMS messages:

Hello, this is a very simple message that should fit into exactly one text. Adding a real :) somehow triples the number of segments, which isn't fun to find out

Hello, this is a very simple message that should fit into exactly one text. Adding 😭 triples the number of segments: finding that out on your bill is quite fun.

Both have 160 characters, but the second one contains 3 segments while the first has only 1. When you translate that to a 5000-member campaign, the losses weren’t pretty. That was a slightly expensive lesson to learn, but it’s interesting how assumptions like this don’t get noticed until you put in a multiplying factor.

I’ll hopefully tell a story about cloud network transfer costs sometime.