How to Make Sure USSD Services Spread Like a Wild Fire? Continued.
Take the most out of this amazing technology — USSD — and avoid potential pitfalls. A long and heated discussion on LinkedIn about obstacles to a faster uptake of USSD, has yielded the following list of potential and fake “issues”. Let’s continue assessing them.
3. “Sloppy interface”
Assessment: MINIMAL
Resolution:
1) Use it as an entry point to other “picturesque” interfaces
2) Text interface works fine on any phone
3) Easier to work with (“Google chose text vs. banners”)
4. “No standardization”
Assessment: MINIMAL
Resolution:
1) USSD is defined by GSM standards
2) USSD gateways (centers) are usually connected through a standard protocol like SMPP
3) USSD services and applications are often supplied with USSD center
How to Make Sure USSD Services Spread Like a Wild Fire?
Well, take the most out of this amazing technology and avoid potential pitfalls. A long and heated discussion on LinkedIn about obstacles to a faster uptake of USSD, has yielded the following list of potentially hard and easy issues:
1. “Difficult to remember USSD codes”
Assessment: MINIMAL
Resolution:
1) Use a single point of entry for all services, like *111#
2) Send a Help SMS with all codes upon the first access of *111# or when selecting “Help”
3) Don’t use *–# numbers, use real numbers (contact us to learn how) Read more
USSD Services from All Over the World
Dozens of people from all around the world discussed the future of USSD. They shared their stories about services implemented using USSD.
- USSD is used “for prepaid top up because many people prefer punching in while seeing on the screen rather than going through an IVR.” (Jean Cerien, CEO at COMM4U; Paulo Correia, Telecommunications Consultant; Niranjan Srinivasan, Ericsson – Design & Planning – IN & VAS)
- “USSD is very popular for a number of core and killer services like: Read more
Textual Interface of USSD: Is It an Obstacle?
My question to everyone is: What stops you from using USSD services?
On 10/9/08 8:30 AM, Srinivas Miriyala wrote:
——————–
It is primarily the interface and experience compared to other
technolgies available on the hadnset such as wap/xhtml browser, ODP or
even rich clients. The rich interface will have a strong correlation to
the usage (e.g Apple iPhone usage of google search etc)
=============
My opinion is this:
I would agree with you but for the following facts:
iPhone has a tiny distribution as compared to Nokia, for example (remember we have 3 billion mobile phones on the planet Earth. How many iPhones have been sold? Less than a million?).
WAP configuration is a task impossible for majority of users.
Interface richness should correspond to the task at hand. There is
no need for extravagance to display one’s balance (look at Chrome, for
example, to continue with comparisons).
=============
But in general the question is valid:
Is Textual Nature of USSD a Hindrance to Its Uptake? What do you think?
(BUT don’t forget, USSD can also initiate (send an SMS with a link) a WAP session!)
Network Resources and USSD
And again there is the resource overload argument.
“USSD uses SS7 resources in the network and simply speaking they are the same SS7 resources used for call handling (fast channel) so the main issue is to sacrifice the valuable call signaling resources”
IF ANYONE HAS EVIDENCE OF SOME KIND OF THE RESOURCE PROBLEM WITH USSD PLEASE LET ME KNOW, either as an answer to this question on LinkedIn, or as a response to this post.
Although many people mention this — “USSD ties up valuable resources of the network” — I yet struggle to understand WHAT THE ISSUE IS and where is evidence? Or is it some sort of myth or unjustified fear that does not exist in reality like a worry that you will be hit by a meteorite. It can happen theoretically! But it does not happen in one’s lifetime.
Charging for USSD
Continuing to comment on LinkedIn answers to my question: What Stops You From Using USSD Services?
Cem Koca (BSS Practice Lead, Middle East, Mediterranean and Africa, Hewlett Packard) says that for a USSD “service … you cannot charge directly but [only] indirectly via the provided services (SMS, IVR call, MMS etc).” It is correct. However, if an operator really wants to charge for USSD, it is possible to do so (to adjust the billing system). The question is — why bother? Just send a help SMS and charge for it.
About USSD – 3 / Question on LinkedIn / Continued
On Thursday 2 weeks ago I have posted the following question on LinkedIn:
What stops you from using USSD services?
I have gathered 10 13 15 answers by Monday Thursday Monday (Novosibirsk time). Of which two three four people (who were prompted, and have received an explanation) said they are not familiar with USSD, even though the question is posted in Telecommunications section of LinkedIn’s Q+A. It will be (with the latest stats) – 27% of answers.
I will prepare a more elaborate answer to Murad Mamedov’s comments about protocols and USSD and about signaling overload and USSD.
In this post I wanted to pay attention to Gaurav Jandwani (Business Head at leading e-commerce company) and Bhupesh Sehgal (Head – Value Added Services at Lifetree Convergence Ltd.) commenting about “complexity in accessing USSD” and transactional nature of USSD (vs. store+forward nature of SMS).
Good points, thank you! Seems to me, however, that “complexity” of accessing USSD for consumers is nothing more than a novelty of the concept (“difficulty of remembering if * comes first or #”, “cryptic string of nos with “#” and”*” as part of the string – I find it cumbersome to remember”). With time the difficulty will be gone. For instance, in Russia, balance check is routinely done through USSD (*100#) so even my old folks can do it now (unlike SMS!).
As to the differences in comparision to SMS, design of a USSD service eliminates the store-vs-display problem: SMS is included as an option, therefore all vital info like cricket scores are sent to one’s phone as SMS also. However, access to the service, instead of tapping 3 times for C, then tapping 3 times R, then tapping 3 times I, not speaking of all the manipulations one has to do to initiate a new SMS and send it, and then delete the corresponding “Received OK” message if any, is done by a simple 5-symbol phone call to a USSD number (*111#, for example). That’s, by the way, how most of our end-user services are designed: SMS are sent with a help message in the beginning of a USSD session, and all vital information like show times for a particular movie theater are sent via SMS, of course (yes, we have a popular movie show-times USSD service!).
As to another comment about complex pricing – this can be taken care of by the design of the service and corresponding VAS platform.
LinkedIn About USSD – Part 1
On Thursday last week I have posted the following question on LinkedIn:
What stops you from using USSD services?
I have gathered 10 answers by Monday. Of which two people (who were prompted to do so) said they are not familiar with USSD, although the question was posted in Telecommunications section of LinkedIn’s Q+A. It is 20% of answers.
By itself the fact that a fifth of professionals in Telco business are not familiar with USSD explains quite a bit. Jean Cerien, Murad Mamedov, and Menno Bot mention inadequate exposure as an important reason for the weak adoption of USSD services.
Neeraj Kumar (Technical Consultant, System Architect: 3G UMTS, WCDMA, IMS, Femto Cell) finds the following reasons:
- Yet another application with a sloppy interface. I would rather prefer a GPRS based mobile applet of my favourite internet Instant Messenger.
- cost of using is also relatively more compared to GPRS based applications.
- a killer service based on USSD is yet to be seen, or at least i’m not aware of it.
Let’s discuss these arguments. “Sloppy interface.” A USSD service (as shown in the example here) can be displayed aligned at the center (but usually it is aligned to the left) and long messages could wrap to the next line. There are no graphics, that’s true. But I would not call the interface sloppy. I would even say it is simpler and cleaner, alike Google text ads.
There are a whole bunch of problems related to user experience with GPRS. Shall I start listing them?
Here we go:
1) GPRS settings are hard to configure;
2) Switching to GPRS vs. WAP profiling (WAP gateway vs. HTTP) is not obvious but in Russia it is a matter of paying 40 times more for traffic (if using WAP gateway);
3) Does not work in all roaming situations;
4) Requires a data plan (US);
But what is more important: USSD is not a substitute to GPRS and beautiful interfaces — USSD is a complimentary technology (as it is also explained by the next post’s Figure about SMS+USSD) which can be used as a gateway to call a WAP site via GPRS.
As to advantages of USSD, it works on any GSM phone. No single adjustment is necessary.
Cost. It depends on who is paying for it. It can be set so that it costs nothing to the user, the application provider bears all the cost. This cannot be said about GPRS. A user always pays for data transmission.
“I’m not aware of killer service based on USSD”. True: there are few, depending on the network. In Russia we enjoy MTS balance inquiries (*100#), operator portals (*111#), and games (*224#).
In fact, the killer application is now being developed. If interested in beta testing, let me know. It will be a global, operator-independent initiative which uses USSD as initiating technology.
Atisha Banjare (Territory Manager – Postpaid) rightfully adds to the list of objections that USSD services unlike SMS cannot be shared — a feature which is so common with social networking. In defense of USSD, I can only add that it is easier to initiate USSD in comparison to SMS. Also USSD is usually used in conjecture with SMS, thus it is a good idea to combine USSD and SMS by simply adding a menu item “Share” or “Get an SMS link” which can be initiated from a USSD dialogue to either automatically send an SMS to the inputted mobile number, or to get an SMS onto one’s own mobile phone.
Tommy Bertling at Swisscom (Switzerland) Ltd:
“…not very user friendly and will not work properly in roaming as there is no agreement which codes must work in a network”
Tommy, along with Jean Cerien (CEO at COMM4U), Gerard Byrne (CEO, Experience IT), Menno Bot (Chief Technical Architect at Nokia Siemens Networks (Saudi-Arabia)), complains about codes which are too difficult to memorize and use.
Originally, Supplementary Services Data was designed for use where supplementary services such as call forwarding or multiparty calls were needed. For instance, a call-forwarding option for all incoming calls can be activated by: **21*«destination number»#
However, USSD commercial services are obviously not designed with such complicated combinations in mind. The 3 digits like *111# is your only passport to, say, our service which takes it from there in the form of an interactive dialogue. Seems to me like the easiest possible route to information.
Roaming and USSD. Actually, there is an agreement about USSD support in roaming:
Messages from handsets to the numbers 100-149 always route to the home network. This means that if you are roaming in another network, dialing a USSD number from 100 to 149 on your phone will always route to the application on your home network. If you are used to accessing a particular service in your home network, then you will also be able to access it from another country. USSD codes other than within 100 and 150 are routed at discretion of a guest network.
(to be continued…)
