SMS as a Product?

In case you were wondering, the first ever SMS simply said ‘Merry Christmas’.

It was sent in December 1992 by Neil Papworth, an engineer working for Sema Group, over the Vodafone GSM network in the UK.

The subsequent adoption of SMS as a universal platform for mobile communication was a classic example of Marc Andreesen’s famous maxim that:

The first SMS gateways for mobile networks weren’t intended for customers at all. They were entirely for the benefit of engineers (to test connectivity) and telcos (to notify customers about voicemails) and they only worked over the same network.

But unexpected demand from the first generation of mobile phone customers wanting to ‘text’ each other obliged telcos to implement network interoperability and manufacturers to embed SMS as a service for customers as well as engineers.

At first, SMS was very much a British, then a European phenomenon. As late as 2004, Jack Dorsey had never heard of SMS. When he became aware of the technology, it inspired him to conceive a 1-to-many SMS service that worked across the internet. The concept quickly evolved into a company called ‘Twitter.’

These days it’s not uncommon for firms to use SMS as a channel (primarily for marketing communications) but how many have embraced SMS as a product?

The answer, it seems, is very few. SMS has historically been overlooked as a product platform in favour of native and web apps.

Ever the pioneers, some gambling companies offer SMS betting services (often powered by this Irish technology) but even these are designed to enable ‘last minute’ trackside bets rather than function as product substitutes.

This failure to embrace SMS is perplexing as, on the face of it, SMS is ideal for reaching and serving customers.

As an embedded app on all mobile devices, it has an extremely broad reach and requires no onboarding. Its text-only interaction model is accessible and familiar to virtually everyone. 

Furthermore, it’s cheap to build on and support and requires next to no design or UX investment beyond the definition of user commands and the relevant automated responses.

What’s not to love?

SMS at Level

At Level, we’ve always prioritised ease of use, speed and digital inclusion as product principles.

As a result, we chose to fully support SMS as a product option for customers who wish to use our On-Demand Pay and Personal Financial Management features. Getting a salary advance from your employer has traditionally been slow, undignified, and unpredictable and we wanted to deliver a service that felt exactly the opposite: reliable, private and blisteringly fast:

Just text us a number and receive that amount in your account. In less than a minute.

Part of the appeal of building products over SMS is the efficiency of development.

In terms of engineering, it’s commonplace to integrate APIs from an established communication platform provider (Level use Twilio) to configure the messaging logic at speed and at a cost per message that will work for a startup.

Whilst SMS communications are cheap, they are not free so the cost-per-message must be factored into the costs of running the overall service.

With no UI or visual design overhead, the UX challenges are language-based and decisions need to be made about tone of voice and fault tolerance. In many ways, building products over SMS is closer to designing for voice than for conventional interfaces such as native apps.

Level’s SMS services are triggered by user-initiated commands which are kept to the minimum number of possible characters to reduce input effort.

Designers need to bear in mind that a number of commands are (still) reserved by the telcos for test purposes so you need to get creative about your choice of words. ‘Advance’ and ‘Send’ are both taken so we opted for ‘Get’ instead.

Even when optimising for brevity there are still design decisions to be made regarding tone. Too brief and the response can seem cold and functional, too friendly (‘Hi Paul, how much would you like to withdraw?’) and you increase the risk of a conversational response that is unlikely to be recognised.

This latter use case is where fault tolerance comes into play.

The challenge is determining the number of response variations your service can (and should) recognise. The most basic implementation must still cater for capitalised and non-capitalised versions of commands (ie ‘GET’, ‘get’ and even ‘Get’) so its advisable to keep your choice of words as simple as possible to derisk the likelihood of variation.

There’s a lot of trial and error in this regard. The best method is to analyse the message logs of user responses, identify any that were not expected or recognised, and build out your message bank to accommodate them.

Emojis

One design route we explored is the use of emojis as commands instead of text. Inspired by Irish fintech startup Plynk (sadly now defunct) we investigated replacing withdrawal allowance requests with emoji equivalents. Emoji commands are easy to implement and have a novelty factor that makes them disproportionately impactful in product demos

In reality, we found them to be less effective than expected for banal reasons that retrospectively should have been obvious.

There’s no emoji equivalent for a financial value such as £100, at least not one that everyone recognises, and trying to establish a brand new lexicon defeated the objective; which was to be intuitive.

In the end, only the ‘waving hand’ emoji (all 6 skin tones) was retained as a core user command within our portfolio.

Summary

Getting instant access to your earned income in response to a single emoji is a great sales gimmick but has no practical role in an SMS-driven service.

Initial Response

As soon as version 1.0 was ready, we began strongly promoting our SMS product as THE simplest and most accessible way to get paid early and manage monthly cashflow.

Despite seemingly obvious advantages in terms of speed and ease of use, we were surprised to see that Level’s initial users preferred to forego SMS in favour of the web and native apps to access their pay on demand.

Only a hard core of ‘super-users’ regularly engaged with the SMS product.

This may be a result of habit (ie people incline towards more established interaction paradigms) or it may be that the web and native apps simply provide more ‘reassuring tactility’ when requesting and receiving money.

In short, SMS might just feel ‘too easy’ and most people prefer a transactional experience that feels more substantive.

Further research will hopefully establish the real ‘why’ behind the ‘what’ of these puzzling engagement stats.

We also encountered a number of unexpected obstacles to engagement.

The first is the recent increase in the use of SMS by criminal gangs for fraudulent purposes. Fake delivery updates from courier companies and account updates from Amazon proliferated during the pandemic.

This inevitably led to a decline in trust in SMS overall and a reluctance to engage with messages from companies (as opposed to known contacts) in this channel.

The second is the language barrier. As a text-based service, it goes without saying that users must have a good grasp of English; more so than with native apps whose familiar design patterns make them easier to navigate.

You and I could probably find our way around Spotify or Amazon’s apps in Portuguese without necessarily being able to read the labelling. But with SMS we’d be lost.

Some of Level’s end-users, especially those in the ‘gig economy’ sector, were less than comfortable with English text commands so failed to engage with the SMS product as a result.

Where We Are Now

Subsequent Level clients have been quicker to recognise the value proposition of SMS as a standalone service. In fact, the majority of users currently being onboarded are given the option to choose between downloading Level from the App Store or using Level entirely over SMS.

The best fit for the SMS product tends to be companies looking to expedite payments to their employees between weekly or monthly salary cycles.

The ease of onboarding (employees can be signed up with consent by Level administrators) combined with the simplicity of the interaction model make On Demand Pay via SMS appealing to a distributed workforce where English is often a second or third language.

Early trials have been encouraging. Is this the ideal use for establishing SMS as a payment product? Only time will tell.

Pros and Cons

Pros of using SMS:

Broadest reach in terms of accessibility, all mobile phone users have SMS as an embedded app on their phones

Next to no UX or design challenges: all mobile phone users know how to use SMS

Very cheap to develop and support – text only so no design or native engineering

Very secure – all SMS is encoded and accessible behind device biometric or code locks

Very quick and reliable – runs over cellular network rather so can be used outside of wifi range or when internet connectivity is poor

Cons of using SMS:

Surprisingly, many users prefer using a native app when given the choice; possibly out of habit or due to the reassuring tactility of the user experience

Fear of fraud constrains use – fake SMS messages have proliferated in the past couple of years making many people wary of the authenticity of SMS transactions

Fault tolerance is a challenge – only correct spelling and syntax can function as responses and likelihood of variations is high

Language barrier – not everyone reads English so well

Can be confusing to customers who treat it as a human-to-human interaction and don’t realise they are interacting with automated responses

Doesn’t work on the web, only on mobile phones