| Customer Experience: Orange Devices Experience. Yves Maitre, SVP Mobile Multimedia & Devices, on evolving from the walled garden to the app store to the “digital coach”. Presentation from EMEA Brainstorm, November 2011 |
 |
Download presentation here.
Links here for more on New Digital Economics brainstorms, Strategy, and Technology, or call +44 (0) 207 247 5003.
Summary: Vodafone 360 was meant to be a new, social-network centred approach to managing the customer interface. Unfortunately, it was also bug-ridden and dogged by a lack of clarity of purpose. Now, its availability on Android Market and iTunes may create a strategic opportunity for Vodafone to access more customers.
NB You can download a PDF copy of this 15 page note here.
Vodafone 360, one of the currently trendy “all your social networks in one app” products, launched in 2009 to considerable publicity and enthusiasm – not least from us. However, thanks to a variety of problems at the tactical and technical levels, it has failed to achieve the scale required for a successful platform. Vodafone is now trying to resolve this, notably by integrating 360 into the Android Market and iTunes as an app in its own right.
In this note, we discuss this move, and the possibilities opened up by repackaging operator and partner products into a pure software user experience that can be distributed to the user bases of very large app stores. This, we argue, creates a horizontal service layer that reaches across devices and connectivity providers, essentially implementing the vision laid out here by Giles Corbett of Orange’s innovation group.
This may also be an innovative way of generating relevant customer data, an alternative to the extremely complex processes of data federation and database systems integration typically seen in customer-data projects. Turning Vodafone into an app may be the answer.
At the 7th Telco 2.0 Executive Brainstorm, held in London in November 2009, Vodafone’s director of new media, Bobby Rao, presented their new social network product – Vodafone 360. We were enthusiastic. Why?
Rather than trying to bar users from going to their favourite Web services, or extract a tax from Google, Vodafone was trying to improve its users’ mobile Web experience and facilitate their interactions with Facebook, YouTube and friends. The technology approach was sensible, using Web 2.0 rather than RCS clients and such things. The Linux-based handsets had a truly impressive user interface.
Vodafone was embracing developers, making use of open-source technology, and doing things like integrating carrier billing into the content and app-store elements of the service so that their upstream customers could get paid. Using the OMTP’s BONDI standard for access to device capabilities was sensible.
The applications for Vodafone 360 were all about communication of one kind or another – instant-messaging, status-updating, sharing location, photos, and other media. It was even suggested that it might grow into voice at some point.
Rather than just barricading themselves in the telco bunker, or reaching for the symptomatic relief of more handset subsidy, Vodafone was actually trying something new and interesting. And that’s always worth watching.
8 months on, it would be unfair to call Vodafone 360 a flop, or call out the Telco 2.0 Crash Investigator, but it is hard to say that it’s been a success. Perhaps, at this point, it’s more of a case for Telco 2.0 Safety Event Reporting rather than Crash Investigation. But user adoption has been slow, there has been much negative comment, and the developer community has hardly caught fire.
Vodafone’s own actions speak volumes; they rapidly downsized the space in their retail outlets that was devoted to 360 in order to make more room for iPhones. Actually, there were signs very early on that the company’s senior management might not have been fully committed – despite the huge Vodafone UK ad budget, the initial push for 360 was hardly impressive.
Negative comment piled up; there were reports of very high returns, a buggy user experience, and a number of odd decisions. For example, the photo-sharing element didn’t support Flickr, the world’s most popular photo-sharing site, because “nobody used it”. Contacts ingestion, a key feature for any social application, was heavily criticised.
“This is what racked me off the most. After getting all my contacts merged and sorted I found that at random times I would log back on to the 360 website and find either duplicated contacts appear or the list gets shorted and a load have been deleted. Now this is grass roots basics for a contacts management program. It stores them safely and accurately and 360 does not. I therefore cannot trust it with my information. It’s a good job I keep my contacts backed up in Outlook…”
There was no support for Twitter at launch – this is telling, as the process of posting a status update to Twitter can be implemented in one line of code on a Linux/Unix system like the Samsung H1s. It’s not rocket science:
Now, Vodafone is looking elsewhere.
The most tangible sign of this is the decision to integrate the appstore element of 360 with Android Market. With 90,000 application SKUs in the Market as opposed to 8,000 in 360, this is no surprise. It could also be read as an admission of defeat. Wasn’t part of the point of 360 that it would be the commercial spearhead for JIL, BONDI, LiMo, and the related telco-sponsored TLAs like WAC?
Regarding the alphabet soup, it’s worth noting that there are renewed moves towards consolidation. For example, the OMTP is now closed, with its BONDI project and its chief Tim Raby integrating into WAC, and the remaining standardisation activities being rolled into OMA. Android is essentially a mobile-optimised Linux distribution bundled with a set of Java libraries implementing access to its mobile-specific features – this is close to the original vision of OMTP. Similarly, the LiMo/BONDI combination is a mobile-optimised Linux distribution that exposes mobile-specific features in JavaScript libraries. There is clearly at least the possibility of a meeting of the minds here, and standardisation of the APIs between distributions, access software layers, and organisational TLAs (Three-Letter Acronyms).
Obviously, the prospect of adding some 90,000 new apps with a stroke of the pen is attractive. Werner Vogels, CTO of Amazon.com, considers “selection” – that is to say, choice or variety – to be one of the critical “flywheels” that drives the growth of platform businesses. That is to say, it’s a source of increasing returns to scale, as the network effect between many buyers and sellers comes into play.
The market leader, Apple’s App Store, counts some 225,000 SKUs as of 7th June, 2010. Android Market had reached 90,000 by the 11th of July; the white-label app store provider Getjar offers 60,000. As Amazon’s experience would suggest, there appear to be increasing returns to scale – Apple has so far counted 5 billion transactions through the App Store in two-and-a-half years, while Getjar reports 900 million downloads over a significantly longer period of time. In its Q210 results, Nokia reported that the Ovi Store showed 13,000 SKUs and a run rate of 1.7m downloads/day one year after launch; assuming a linear trend, we estimate that this equals 310,250,000 downloads since launch.
But the Android integration is just as important from the point of view of hardware. To the end user, mobile is all about hardware – one of the numerous lessons from Apple is the enduring centrality of shiny gadgets in any mobile marketing effort. Arguably, there are two models for success here.
If your service (including the core telco services) is going to be tied to one specific device, it is obviously vital that the device be outstanding. Close coupling between the device and the service means that you can control more of the value chain, and also that you can control the user experience more closely. It also means that the rest of the value chain – specifically the hardware and device software elements – controls you.
If the devices are subpar, or simply drowned out in the iHubbub, the service will be too. This has consequences for tactics as well as strategy. The marketing, advertising, and retail effort has to push the device as much as it does the service. The supply chain, activation, and support infrastructure must be ready. And most of all, the device has to be ready on launch day – you can’t afford a slow start.
Alternatively, you can concentrate your effort on service, software, and tariffs, and go for the largest possible range of devices. This is the Android (and also Nokia) strategy.
It permits you to hedge your bets, creates more scope for adjustment to changing circumstances, and avoids getting into a creepy clinch with any particular vendor. It also precludes the sort of close control of the user experience that the BlackBerry-like strategy provides, unless this can be done entirely in software.
These two approaches intersect with two models of go-to-market tactics:
1. The big bang!
We’ve all seen it – Steve Jobs strides onto the podium at MacWorld as the cameras click and produces the new shiny from his pocket. Big-budget videos. Publicity stunts. Basically, it’s a huge pre-planned event, backed up by an integrated media operation cued to peak at that moment and linked behind the scenes with a carefully prepared supply chain. The advantage is, of course, concentration of effort in space and time.
The disadvantage is that once the retailers fill their stocks, and the production servers are fired up, you’re committed to going through with the launch. The flop will be all the bigger for all the concentrated effort if anything goes wrong.
2. Permanent beta
This is the anti-launch; rather than trying to seize everyone’s attention, the idea is to recruit a select band of early adopters, gradually build scale, and carry out kaizen over the medium term. Google is famous for it, as are games companies in general and the open-source world. It allows a maximum of flexibility, and permits adaptation as you go along. There is a risk that the product will never catch on, but that risk is always there.
There is, to a rough approximation, a mapping between these pairs – the superstar device option tends to require a big bang, big day go-to-market plan. It’s possible to integrate the two in that you start with the beta, and move on to a full launch when it passes some project milestone; we could call that scenario the “rolling start”. However, it’s impossible to do the opposite and move from a launch to a beta.
Unfortunately, Vodafone 360 didn’t really succeed in going for either a big bang or permanent beta approach; rather than launching 360 with one superstar device (perhaps one of the top-end Androids, or even the iPhone), or else pushing it out across the board, they chose two rather specialised devices. If Vodafone made a major publicity push, it didn’t succeed in getting the public’s attention; it did, however, succeed in generating enough publicity that everyone noticed the bugs.
Integrating into Android Market has the effect of definitively plumping for a teeming bazaar strategy, going for device diversity. It also means that Vodafone 360 will have to rely on implementing its features and user experience as a software client on the device.
But this could be a major strategic opportunity.
If you can distribute 360 applications through the Android Market, you can also productise 360 itself as a software application, and then distribute it through the Market.
This would give Vodafone an access route to the global Android user base. A detail of 360 we liked originally was that it isn’t restricted to Vodafone customers – distributing it as an application on the Android Market would take this and go further. So far, the separation of access, enablers, and services – the horizontalisation of telecoms – has mostly benefited vendors, content providers, and software developers. But this doesn’t have to be true. Converting its customer-facing product into a software application would let Vodafone play at that game, too.
This is very similar, in some ways, to our view of Google’s strategy. Google is trying to extend into the middle of interactions across a wide range of markets, taking a thin layer of value between buyer and seller; Vodafone 360 could capture a similar thin layer of value from other operators, by providing a better interface for a wide range of online services.
As well as creating a Vodafone access route onto devices that don’t live on its network, 360 might also have important consequences in terms of customer data. It is well placed to capture information on how users interact with the services it talks to; it will be only more so on Android with the range of interfaces it provides for collecting social-graph and location data. In fact, it’s fairly trivial to have an Android app receive notifications when the network signal strength changes – it could even be a way of capturing real-world network quality data.
Normal
0
false
false
false
EN-GB
X-NONE
X-NONE
Operators are still struggling to get a grip on the piles of data they collect – the stereotype example is the operator with dozens of billing systems, some of which are 20 years old. Federating data across these hugely complex legacy systems-of-systems amounts to a major systems integration project as well as a significant software development and data-management challenge. There is a strong argument that it might be easier to solve this at the mobile application level, creating a new edge interface at which customer data is generated, and possibly also gaining data created by customers you don’t yet have for the core services.
After all, that’s precisely what Google did with Google Ads – rather than trying to, say, extract information from tens of thousands of websites’ server logs, they simply got their users to declare their interests as search strings and matched ads to them. So there’s a possible play for data-enriched advertising, especially as in-application ads become more common.
With this “Vodafone bridgehead” onto Android devices, there are many other opportunities. Back at the inception of 360, we noted that Vodafone was suggesting that it might eventually include a voice element. In our recent Ribbit note, we quoted one Ribbit Mobile user as saying that he wanted it to “take over the entire dialler function” of his iPhone. It is entirely possible to do this in Android. As well as providing call management, better voicemail, and integration with other social networks and contacts lists, this could use something along the lines of carrier preselection, rather as Google Voice does, to offer competing call rates.
Android devices are highly effective WLAN finders; another option would be to make use of the GAN standard and route SIP calls via Vodafone while a WLAN hotspot is available. This would make it possible to create an application that grabs the user, creates a new source of customer data, captures minutes of use, or at the very least, denies them to the enemy. We referred to Ribbit Mobile; in fact, the service could actually be implemented with Ribbit’s technology under licence.
But Vodafone could do better than that; they already have a hosted unified-comms product, Vodafone One. Just as Ribbit, being a cloud service, fits into BT’s existing sales and provisioning processes for SMBs and enterprises, so an Android-based Vodafone app would neatly fit the mobile features of Vodafone One into an effective package for distribution to individual customers. We’ve already seen that a wide variety of businesses and functions can be effectively distributed to the individual user base through app stores. Wrapping Vodafone in an app would allow them to leverage this.
There are other options in this line – self-care features could be embedded in the app, for example. Vodafone has already dabbled at this with its MyVodafone app; YouFon’s “manage your account through Facebook” is another pointer (see Figure 6, below). Or the carrier could use the app and its service back-end as the underlying technology for a range of niche MVNO propositions.
Another key capability that Vodafone could make use of is its existing pre-pay infrastructure, both the OSS and other IT resources behind the scenes and its networks of reseller agents. At the moment, prepay users need a credit card to take part in the app/content ecosystem – or at least, they need to go to the trouble of entering details on a non-keyboard device or risk having them stored on an easy-to-lose, easy-to-steal device.
But Vodafone 360 already ingests credit through the existing VF pre-pay system, so it could also pay out rewards, revenue shares, or peer-to-peer transfers through the same mechanism. And, of course, they have the M-PESA system available.
The Vodafone 360 experience demonstrates the opportunities and pitfalls of moving from a traditional telco model towards one oriented towards the Internet and based on software. Initial failures, and the recent fiasco when Vodafone decided to impose a variety of 360-branded apps on its HTC Desire users as an unannounced software update, show how difficult it can be for our organisations to adapt to these challenges.
However, we can also see how this presents an opportunity to compete on the Web majors’ and Voice 2.0 players’ own terms. If operators can develop compelling new applications and services, the vendor app store/smartphone model is a valid way of distributing them and gaining access to a wider user base. Operators have specific assets, notably their PAYG and/or Mobile Money Transfer (MMT) infrastructure, that such a move can leverage, notably by opening up the app/content store to the PAYG subscribers. At the same time, MMT operators can use this to deploy their product more widely by packaging it as an app.
Further, it seems to be a good general forecasting principle that major customer-data projects are harder, more expensive, and more complicated than expected. There is no reason to expect this to change, as the reasons are structural and rooted in the existing infrastructure and the politics and economics of privacy. As a result, it may be a good idea to seek new and additional ways of acquiring this data – Google, after all, didn’t start off by integrating a variety of legacy databases, but rather by creating a new user base. The Web 2.0 experience demonstrates that it is possible to derive useful data profiles from very low-touch customers.
The greatest opportunities appear to be in integrating such an approach with existing MMT, content, channel marketing, and Voice 2.0 ideas – using the app store paradigm to repackage the rest of your Telco 2.0 activities in the consumer and SMB sectors.
However, it is critical that operators master the tactical problems of execution in a space which is fundamentally different to traditional mobile. Customers’ ability to churn is significantly higher, and the fall-out from missteps will arrive much faster than most of us are used to.
