Best practice in SMS information services

26 Jan 2009 - 4:24pm
7 years ago
2 replies
558 reads
Fredrik Matheson

Eight years ago I worked for a company that sold sms services – ringtones,
icons, downloads of all kinds and chat.
My suggestions might be out of date, but we made terrific amounts of money,
so some of them might still hold.

1) Best practice in designing an SMS information service

Yep, you've got the best practice format right there. Use italics/bold/color
differences to illustrate what part of the sentence is instruction and what
part they should actually send. I'd suggest using bold or italic rather than
caps for the codes. Typing in caps is a pain (even on the iPhone) and people
*will* take your instructions literally.

If your target audience is familiar with sms services, they'll need minimal
instruction. "Send *weather* <your city> to 1234" will do just fine for

If you can, get a good CPA (content provider access) shortcode (that "1234"
number you're using). Try to get a decent number (2121 is easier to remember
than 2391, for example). Send people a free vCard with your shortcode (if
that's kosher) so they have you in their phonebook. If you're in the US, you
could always find a nice word acronym: 3287 is "ebus", etc. Those codes
don't work very well in Norway (and in most of Europe, I believe) so I never
had the chance to play around with them.

2) Common errors

People misspell stuff all the time, and sometimes their T9 dictionary turns
a minor mistype into a completely different word. Try misspelling your codes
with T9 and regular keyboards and add those words as aliases. Also, go
through the log each morning to see what kinds of errors happened in the
previous 24 hours, and add those as aliases as well. If a user-entered code
makes no sense at all, you can call the user (you have their number,
remember?) and ask them what they were up to :-)

Complex sequences are hard to perform. Consider creating a guide that people
can use when typing in a code. Checking bus schedules via SMS is *not* a
great experience, but if the alternative is ignorance, it'll do. Print
stickers, single or folded cards or even a z-map-type fold out poster
showing how to do it. If you're doing this for a public transportation
company, have them place stickers on the backs of seats with instructions on
how to send the message.

If you're dealing with bus services, etc then make sure you're forgiving
about time input. Accept 5, 5pm, 1700, 17, 17:00 and even "five" if you are
able. Also, make the syntax as easy as you can (it will never be easy-peasy,
no matter what you do). If the user doesn't add a time, make a guess and
give them the next five (or however many you can fit into the message).
Separate entries (departure times, etc) with carriage returns (lines).

Choose service names (weather, bus, etc) wisely. "Bus from central station
to main street at 5 pm" is what I'd recommend but I'd make sure it worked
with "Bus central station main street 5" as well. You'll have to spend a lot
of time figuring out what works from you from your logs. That means learning
at some regular expressions and perhaps a database tool, or you can chop
things up in Excel. In any case, pay close attention to what's happening.

3) Craft well-made, context-appropriate error messages

If people mess up the service name, tell them

You typed "qeayjrr" but we couldn't figure out what that meant. For a list
of our services, please reply with the word "Help" in your message" (or
something along those lines).

If people mess up the syntax, first try to parse it on your end, and if you
can't send them a response akin to

Are you looking for the bus schedule? <!-- new line -->
Send: <!-- new line -->
Bus from <your location> to <where you want to go> at <time> <!-- new
line -->
to 2121. This help message was free of charge.

That's right: make sure that help messages don't cost the user a dime.
They'll have to pay for the next message, but that's not (exclusively) your

4) Similar web services that have been adapted to SMS

Any sort of information-request or entertainment service will work, provided
there are no workable alternatives. iPhones, Blackberries and Palm Pre's
aside, most people are using handsets that support SMS well and the web
rather badly. Bus times are much easier to view in a rich application, but
SMS is incredibly robust. Note that shortcodes will usually work only for
local users, as your phone sends all SMS messages to a carrier-driven
gateway that handles all the local shortcodes. I can't easily use Dutch SMS
services, for example.

We've had SMS services running in Norway since the middle of the nineties.
Content provider access (i.e. you can charge a user to receive a message)
came in 1999, so there's been quite a bit of experimentation. I'd suggest
getting in touch with some of the companies here and other places in Europe
and Asia to collect further best practices.

Please do be aware that the most popular services are the less constructive
ones. One of the guys I worked with literally made millions selling speed
trap alerts to his subscribers. Bus services are a nice idea but they're a
lot like command-line interfaces (with a lousy and pay-per help command to
boot). I never saw huge take-up of that service, and in recent years,
real-time electronic timetables have come up at well-used bus stops. Plus,
there's the iPhone app, which geolocates you to suggest what's moving

A huge hit, of course, was white pages lookup (by name, address and phone
number – the last one was a killer).

Lastly, since the interface/command-line is such an annoyance, subscriptions
are often a good idea. Prepend or append some subscription command to
services like weather, traffic, etc so people don't have to send-to-receive
every time, if that's suitable for them.

Let me and the list know how it all works out.

- Fredrik

Syndicate content Get the feed