Mobile Clients vs SMS - Why SMS STINKS

Sending an SMS from a mobile device is usually a trivial operation. Pick a phone number, type a message, and send it. Sadly that is not the case when you programmatically send SMS messages, these messages go through a completely different path to get to their destination. He are some of the additional challenges involved:

  • SMS is an old technology originally developed in the '80s and not really improved upon over the years (Wikipedia), so the entry points are designed for short messages from handsets instead of long messages from applications.
  • SMS messages are routed through various aggregators, carriers and providers and most of these intermediaries are trying to do it as cheaply as possible - they will often times change their "routes" by time of day or day of week to get the cheapest routing cost (read that as "not the optimizing for quality of delivery" and see Wikipedia entry on unreliability).
  • Various self-governing bodies exist (MMA, CTIA, TRAI and others) that are trying to create guidelines to prevent SMS spam so the carriers don't lose money and governments don't get involved in protecting end-users from unwelcome spam. The problem is that these folks are creating so many regulatory requirements that the number of messages sent to a user to opt-in, and the length of any given message is exploding. The signal to noise ratio is actually dropping because there is as much regulatory language in your message as your own content.
  • Old technology means poor user interaction:
    • Messages are in plain text, so formatting can't be used to clarify content.
    • Messages are 160 characters or less when you subtract out routing information, character encoding (160 7-bit characters, 140 8-bit characters, or 70 16-bit characters) and regulatory content (see below)
    • Some messages can be reassembled into content longer than 160 characters... but it depends on the providers and handsets... so it is a "definite maybe" (can your emergency messages afford definite maybes?)
    • There is no structured response mechanism, so your responses will depend on a person properly typing in a response.
    • Delivery and "read" receipts aren't guaranteed on providers, so there is no real assurance of messaging.
    • Character sets are often times incompatible across carriers... try sending Chinese to a Sprint phone via an API... it can't be done!
  • SMS in many countries (including the USA) have end-user charges for receiving a message.

There is a better way to solve the problem of getting important messages to users on their mobile phones and that is why xMatters invested in providing mobile apps and push technology on three major smartphone platforms: iOS, Android and BB10. This chart shows how these mobile apps are better than SMS:

FeaturexMatters AppSMS
Multi-byte character support (e.g. Chinese, Korean, Japanese, Russian) Yes On some carriers
Long message support (longer than 160 7-bit characters, 140 8-bit characters, or 70 16-bit characters) Yes On some carriers and only on specific handsets
Rich text formatting Yes No - plain text only
Simple one touch response mechanism Yes No - start typing
Stable message routing Yes No - changes constantly at carrier whim
Per message charge for recipients No Depends on your rate plan
Delivers your message without additional regulatory content Yes No - wade through other required "noise" to read your message (see an example below)

To give you an example of extra regulatory language, see the following excerpt from the CTIA compliance document (effective Dec 1, 2013, but always changing and available here: http://wmcglobal.com/assets/ctia-mobile-commerce-compliance-handbook-v-1-3.pdf) showing the required extra messages to opt-in and the extra "Powered by..." language your SMS messages are required to have by the mobile carriers:

Also note that these guidelines aren't actually enforced across carriers. T-Mobile is requiring STOP language with every message sent. Picture this message: "Please evacuate the building. Reply STOP to cancel. Powered by xMatters." For 28 characters of message content ("Please evacuate the building") we are required to add another 42 characters of STOP messaging and brand identification (it says "xMatters" but that isn't our marketing department doing that, it is a requirement that we identify ourselves).

xMatters will continue working with carriers, providers and aggregators to lobby for the best end-user experience over SMS, but at this point the easiest to use, most reliable and cheapest solution for our clients is our mobile apps.

xMatters Reference

JDN-4401 Originally created by Doug Peete

 

Have more questions? Submit a request

0 Comments

Article is closed for comments.
Powered by Zendesk