We’re occasionally asked how we ensure the quality of our SMS routes. The answer can be quite detailed with numerous avenues and procedures at different stages and times.
In this blog I’ll guide you through how we test and validate a new bulk SMS route.
But the first question that arises is, “does the quality vary?”
As you’ll read below, the answer is a resounding “yes”
…massively.
Stage 1. One message, One Handset
The first stage is to send a single message to a single phone, it sounds incredibly daft but if we can’t do this then we can stop wasting our time or least contact the supplier and get them to sort themselves out.
Can this really go wrong: if the supplier hasn’t configured the account properly, has provided you with the wrong user name and/ or password, has locked the route to a wrong IP address, or provided you with inaccurate API documentation then yes, it can go wrong.
Stage 2. Multiple Messages
Now we send 6 messages, one to a handset on each UK network. They should all arrive at approximately the same time or at least seconds of each other. The message should be the same on all the phones and the header/ originator should be the same.
What can go wrong here: In the past we have seen messages delivered to all but one phone, we have seen SMS headers scrambled on certain networks, characters changed in the SMS message body, and even routes that can’t deliver to Nokia handsets.
Stage 3. Character Encoding
Now it starts to get tricky, we send the complete GSM character set to each of the 6 phones. Some say this isn’t possible. But that’s a lie, its depends on which routes they use, which networks you send through. For example, one of Vodafone’s cheaper routes doesn’t process the “|” (pipe) symbol, but you can route through O2 to a Vodafone handset successfully with this symbol.
So we check through the character set to ensure they come through accurately on each phone, sometimes some Greek symbols and other lesser used characters will be replaced, sometimes the message isn’t delivered at all, but at worst, the message isn’t delivered but the supplier returns a delivery receipt saying it was delivered.
This can happen because the supplier or network isn’t able to process a particular character, they simply fail the message, but systems can get confused and think it was delivered.
If we get a good result on this test then we stop here and wait a week.
Stage 4. Repetition
Repeat stages 1 to 3 again. We like to double check things don’t change.
Stage 5. Integration
If all is looking good then we’ll start the integration process. This means configuring our live platform to send a limited volume of real messages.
We’ll send a regular stream of messages for a few weeks but monitor very very closely. We look at delivery rates, latency, we’ll do occasional checks to the in-house test phones.
We’ll always allow this test to cross over a month end because we need to see a bill for the messages. We need to see our records of messages correlates with theirs. We like to see they are able to raise an invoice promptly and accurately. We want to ensure we can access relevant technically competent staff in a very short time frame, that means they have to answer the phone and emails and resolve any issues quickly. It’s not just about the messages, we look for solid, reliable, consistent suppliers, and this can only be proved over time.
Stage 6. We’re Live!
Increase the volume of SMS through the route.
But we’ll only do this if everything above is satisfied to our exacting standards, and even then we continue to monitor on a regular basis. But regular monitoring is a subject for another blog post…
