Salesforce released desk.com very recently:
Operators should be looking at how disruptive dotcoms are offering disruptive customer support. After years of investments in help desk automation, most operators are still showing basic problems. How often are you asked to introduce your phone number and when the agent picks up the first thing they ask is “What is your phone number?”. SaaS help desk solutions might change the way support can be delivered.
How many operators are linking conversations with customers in Twitter, Facebook, life chat, email and phone? Not a lot. Disruptive telecom competitors are just doing that. They go even further by given control to customers about roadmaps, service extensions, priorities on problem resolutions, etc. via Social CRM.
Siebel, Clarify, etc. have a solid base but “ease of use” and “quickly rolling out changes” are no key features. Customer support should work more like an iPhone. Each group of services should get its support app. Both an app for the customer as well as for the helpdesk agent. Customers should be able to follow the 80-20 rule. The most frequent support activities are done via self-service. Helpdesk agents get apps for the other 20-80 parts as well.
When marketing launches a new service, integration into the CRM should no longer mean support agents get an upgrade. Instead it should mean customers and support agents get another support app. Isolate the complexity of service support on the service level. Do not try to create one CRM that solves all possible scenarios. Instead have each support app customize the basic operations that are valid for the service. Service experts will get a lot less support requests if they empower others to resolve support problems. Agents and customers will enjoy the straight forward support approach. Service developers will think of support from the start and not as an add-on…
Most telecom operators are still thinking that software should be upgraded at most twice a year. Oracle RAC is the only valid database solution. RFQ’s bring innovation. If you pay higher software licenses, the software will have more features and as such will be better.
All of these myths will have to be changed in the coming 12 months if operators want to be stay on top of the game.
Upgrade twice a year
For telecom network equipment, two upgrades a year are fine. However for everything related to services that are offered to consumers or businesses, that means that operators are 180 times less competitive then their direct competition. The large dotcoms like Facebook and Google make software upgrades on a daily basis. 50% of all the files that contain Google software code change every month. Even if “a revolution” would happen and software upgrades would come every month, it would still mean a 30 times lag.
Operators need to start using cloud computing, even if they are private clouds, to deploy their back-office systems. The business needs software solutions to move at market speed. That means that if a new social networking site is hot, then it should be integrated into telecom solution offerings in days. Not in months or a year.
There are many techniques to make deployments more predictable, more frequent and more reliable. Offering extra features or integrations quickly can be done via plugins. You can have a group of early adopters, give feedback. If they don’t survive this feedback, kill them. If they do, scale up quickly.
Nothing bad about the quality of Oracle RAC but it is a very expensive solution that needs a lot of man-power to keep on running smoothly. Operators often pay a premium for services that could run equally well on cheaper or Open Source alternatives. Also NOSQL should be embraced.
If the cost of deploying a new service is millions, then only a couple of them will be deployed. By lowering hardware and software costs, innovative projects are more likely to see daylight.
RFQ’s and Innovation
It takes 3 months from idea to finalizing an RFQ document. 1,5 month to get a reply. 1,5 month to do procurement. Half a year in total. Not counting the deployment time which is likely to be another 6 months. The result is that the operator takes 12 months for any “new” system.
Now the question is if that system is really new. Because if an operator was able to define in detail what they want and how they want it, then the technology was probably quite mature to begin with. So operators spend fortunes installing yesterday’s technology 12 months late. Can anybody explain what innovation this is going to bring?
First of all operators should not organize multi-million RFQs for business or end-user solutions. These are likely to come late to market and can only be focused on mass markets.
Instead operators should focus on letting the customer decide what they want by offering a large open eco-system of partners the possibility to offer a very large list of competing services to their customers. The operator should offer open APIs to key assets (charging, numbering plans, call control, network QoS, etc.). As well as offer revenue share and extra services like common marketplaces and support 2.0 (social CRM, helpdesk as a service, etc.). This is called Telecom Platform-as-a-Service or Telco PaaS.
High licenses, more features, better
More features does not mean better. Most people want simplicity, not a long list of features. Easy of use comes at a premium price. Look at Apple’s stock price if you don’t believe it.
It is better to have basic systems that are extremely easy to use with open APIs and plug-ins. A feature by feature comparison will make you choose the most expensive one. However it is hard to put as a feature that the system needs to be easy to use.
In telecom, there is a natural tendency to make things hard. In Web 2.0 the tendency is the opposite. You can see the difference between Nokia and Apple. The Nokia phone would win every feature on feature comparison but the iPhone is winning the market battle…
Instead of organizing an RFP, let end-users and employees play around with early betas or proof-of-concepts. No training, no documentation. Let’s see which solution makes them more productive, the feature rich or the more straight forward. Just ask open APIs and a plugin-mechanism and you will be set…
Operators have an addiction to use RFQ processes. The problems with those processes are:
- They take a long time.
- They are not useful when technology is not well understood.
- They are only applicable to solutions whereby there are multiple providers.
Basically an RFQ will always bring you yesterday’s technology. After integrating this technology, when you launch you will be working with the day-before-yesterday’s technology. Google and others are working on tomorrow’s technology. Launching an innovative service via an RFQ process is as such almost impossible.
If you want to launch innovative, and new revenue generating, services that bring you back into the game, then the first thing that you need to accept is that RFQ’s are not your answer. So what is the alternative?
Innovation is about trying and accepting failure as a natural step towards success. You need to do everything to quickly detect failure so you do not spend too much effort on such solutions. How can you do this?
Forget asking marketing experts or even doing market studies, etc. Do you know any expert that would have predicted the success of Facebook?
The answer is to form small teams, called tiger teams. 1 functional/sales expert and 5 technical experts is a nice size. These teams should be isolated from the rest of the organization. Ideally the teams are mixed with members from partners or suppliers that know about a specific domain.
Additionally the tiger teams should have access to some innovation framework that helps them use some of the internal assets without having to do real deep integrations.
Finally the tiger teams should have access to part of your website,e.g. labs.operatorname.com, where they can launch their creations and get immediate feedback from beta users.
Operators should invest in these teams as would a VC. You get a little bit of money in the first round. Just enough to get me a prototype in 1 to 3 months. Afterwards we look for 1 to 2 months to see if there are beta users that like the solution. If not, we kill it.
If the solution is interesting for end-users or businesses then the next round of spending should come. However ideally operators start working together with other operators that are not competing and jointly invest. This way, your tiger team might not have given any result this month but the tiger team of your neighbouring operator might. By jointly investing, the cost to get the first commercial version is a lot lower.
The tiger team should not switch off the beta and start working on version 1.0. Instead it should use a social CRM to get feedback from early adopters. The roadmap should be steered by the community of early adopters. The service should with their guidance go from alpha to 1.0 in a maximum of 6 months.
As soon as the service is live, then it should be extended to all the other operators that also invested in it. Via Cloud Computing, it would be possible that this service is only installed in one place and offered to multiple operators with a minimum integration. Partners could even take over all costs of operations in exchange of a revenue share.
Once version 1.0 is reached, it is time to focus on offering open APIs and plugins so the community can start extending the solution and not necessarly the operators.
Telecom operators have always focused on two aspects: ARPU and time-to-market. In the latest technology craze – Cloud Computing – a lot of telecom operators are seeing a new golden grail. Those that can see further than SaaS marketplaces and moving their hosting to IaaS are only the happy few. Since Cloud Computing = SaaS + PaaS + IaaS, it is normal that operators start talking about Telco PaaS. However Telco PaaS is a lot more than combining telco assets with an IT PaaS.
IT PaaS are aimed at quickly launching applications. The IT grail is to launch thousands of applications to find the one that everybody likes and become an overnight millionair. Telecom operators might be easily fooled that opening their telecom assets to IT PaaS developers will bring that one application that will turn the telecom sector around: “The Killer App”.
Unfortunately a telecom application is more than an SDK+app server in the Cloud that can do VoIP. The reason why companies pay a plus to telecom operators is “trust”. “Trust” that you can pick up the phone and call somebody. “Trust” that if something is not working that you can call their call center. “Trust” that tomorrow they will offer you the service.
All this “Trust” has to do with the way operators have their backoffice systems and processes set-up. Having thousands of developers creating applications that mix telecom with SaaS might give some nice innovation. However telecom operators are not prepared to handle thousands of end-users that find bugs in a long list of applications and start calling call-centers massively. End-user expectations are different for telecom applications then for IT applications. This definitely has to do with the price they pay for them.
What should a Telco PaaS offer?
More than a fixed feature set, the most important changes for an operator that wants to offer a Telco PaaS might be internal. Operators will need a large shift in thinking to be able to accept some of the new realities:
- Telco PaaS services need to be launched in weeks not years.
- Telco PaaS services will be buggy, unstable and fail.
- Telco PaaS services can not be supported via a call center.
- There are no Telco PaaS standards and there are likely not to be any until it is too late.
- Telecom can not be greedy
Launching in weeks instead of years
If IT PaaS is bringing something then it is speed of development. Telco PaaS needs the same type of speed. In practice this means that REST and JSON should be the operator’s vocabulary, not SIP and CDRs. Telco Assets need to be exposed to non-telco programmers. Developer communities need to be created. Marketplaces that allow developers to sell their creations by the click of a button and not to worry about complex charging and billing.
Unstability, bugs and failure
Not every IT programmer is a genius. There are probably quite a few geniuses. Instead you need to expect that people will do things incorrectly, by error but also on purpose. Application virtualization and sandboxing are key to make sure “mistakes” don’t bring down the whole platform. On the other hand customers need to be segmented. There are customers that can see further than the bugs and see the potential. These are called visionaries or early adopters. It is critical that operators allow these early adopters to play around with buggy services. However it is equally important that the majority of users know that the sandbox might contain buggy apps and that the call center is not the place they can find help.
No support via the call center
All sandbox applications can not be supported via a call center. Agents will not know anything about these thousands of apps but neither should they. The only one that knows is the one that developed the service. He or she should get the right tools to quickly understand which bugs or feature requests are important, e.g. via a social CRM. The operator should monitor those promising apps that are ready to graduate the sandbox. They should be place in an incubation program. Incubation will see if the applications can go mainstream and will professionalize support, availability and reliability.
No Telco PaaS standards
In the dotcom world the first one that creates a solution, creates the standard. In Telco PaaS this will be the same. If we do not know how users will use a Telco PaaS, how can we expect that standardization bodies will define the correct standards. However in disruptive innovation, unlike technology evolution, first movers have an ever lasting advantage.
If you have a monopoly, you can be greedy. No competitor will offer anybody a better deal. However in Cloud Computing, greediness will kill your best innovation. It is better to get a small percentage, signup or usage fee per application when you have thousands of applications then to get nothing at all. Many cents can make billions. Think Adwords…
The IT cloud has taken shape. The next step is to offer a mobile cloud. How will it be different and what should a telco offer? For clarity, mobile cloud applications are combinations between mobile apps and cloud computing and telecom backoffice services, not iPhone or Android apps.
Mobile screens of all colours and sizes…
Where the PC worlds only has a handful of web browsers, the mobile world is completely different. Old mobiles live together with the latest smartphones. Applications can be native or web-based. Screens can go up to 11 inches (28cm) on tablets and even if we consider television screens to 50 inches (1.27m). We can even find mobile applications without screens (M2M) or via very limited character entries (SMS).
Although HTML 5 is bringing a good potential stardard, there are still quite some differences between different mobile browsers. So it will probably take some years before a reliable standard is omni-present.
In the mean time operators will have to offer solutions on their mobile cloud. Applications will have to be available on a wide set of platforms. Any help an operator can bring to developers will be highly appreciated.
Mobile testing nightmare
Having to test an html5 application on hundreds of mobiles is a nightmare. Some companies already offer partial solutions. However providing a solution via mobile hardware virtualization and automated testing would help developers bring apps to market quickly. Testing could be paid for by minute (instead of hours in the IT cloud). Mobile makers and testing software companies could get a revenue share for every developer that uses their virtualized solution. This would release the operator from having to do all the mobile OS virtualization and sensor testbeds themselves. It would be similar to having third-parties selling access to their Amazon AMIs but instead they would be for a Nokia Symbian or iPhone 4.
Mobiles have sensors
The latest mobiles have a long list of sensors (GPS, accerelometer, etc.). Mobile clouds should offer developers help in using these sensors and automating testing. You don’t want to physically move a mobile abroad to test if you get a roaming event, would you? Push notifications to the mobile have to be supported in a uniform way accross different platforms.
Latency and network connectivity can be a nightmare
Content caching on the mobile device is key. HTML5 offers an off-line key-value store but unfortunately not all mobiles support it so custom solutions are necessary.
Advertisment support is key
Offering a ready-made integration with major mobile advertisement solutions is important. Some applications can not be charged for, so advertisement is the only means of income. Inline content sales should be supported and hopefully at more competitive rates than the App Store’s 30% revenue cut.
Telecom assets should be the differentiator
All of the above can be offered by IT and dotcoms. Integration with unique telecom assets is a must. Sending an SMS is no longer a unique asset. Neither is location. They have to be real assets: micro-payments via telecom billing, custom numbering plans, zero-cost call forwarding, voice transcription, quality of service, etc.
Become the Elastic Beanstalk of the mobile cloud, not the Google App Engine
The Amazon Elastic Beanstalk is a service that allows java developers to deploy their applications and instantly benefit from auto-scaling, elastic loadbalancing, etc. However in contrast to Google App Engine, there is no one way of doing things. Developers have the liberty to swap out Amazon’s initial configuration by customized configurations.
Mobile to Cloud and Telco connectors
The mobile app, tablet app, TV app, M2M app should be seamingly integrated with cloud applications as well as telecom services. Having single sign-on via OpenID or getting data from the cloud via oAuth are basics. Setting up a conference call, managing call forwarding, voice transcription, etc. are others.
Selling the mobile cloud via a telco marketplace
Mobile cloud applications are combinations between mobile apps/M2M/SMS/Calls/TV Apps/…, cloud computing and telecom backoffice services. Programmers should be able to add them to a telco marketplace and sell them to different customer segments (consumers, soho, small/medium/large enterprises, M2M, etc.). However offen mobile cloud applications should be given away for free and programmers should get a revenue share on telco assets that are used, e.g. calls made, SMS sent, etc.
Mobile Social Networking
Adding social networking concepts are key. Operators know who you call most often. This information can be key when combined with cloud social networks. As long as privacy and opt-in are used, then users should only see benefits.
The long tail mobile cloud is nearby…
The long tail mobile cloud is nearby and operators can be the key players in it. However they will need to suppress their urges to be greedy. Revenue shares should be inline with the dotcom and IT industry. So should individual mobile cloud application pricing.
Cloud speed in time-to-market is necessary. Operators should not try to build things themselves. Instead they should partner with dotcoms and IT/network providers in real partnerships.
Finally the rules are changing. Old rules can no longer apply. Users need to be able to choose between multiple competing mobile cloud apps. No longer can the operator’s marketing department decide what will be a hit. The user community is the only one with this power. Social CRMs and other long tail support solutions can be used to avoid massive call center calls.
In a previous post I shared that I was looking for the container for long tail post-sales support.
Today I would like to present a draft proposal. Feedback is very welcome. The idea is to simplify support to a 0 to 5 stars model:
0 stars: No support.
1 star: Best-effort / community support
2 stars: Basic 8×5 SLA with no penalties and web/email support, daily scheduled maintenance windows possible.
3 stars: Basic 8×5 SLA with limited penalties and phone/web/email support, nightly scheduled maintenance windows possible.
4 stars: Advanced 24×7 SLA with significant penalties, phone/web/email support, and limited off-peak (e.g. weekend nights) scheduled maintenance windows
5 stars: Mission critical 24×7 SLA with high penalties, on-site support and no scheduled maintenance windows
Additionally the operator would be measuring both the availability of the service, the responsiveness of the support, and the buyer’s satisfaction rates hence not only the “theoretical SLA” is available to potential buyers but the last 12-months of actual performance as well.
By having a simple star system, small and medium enterprises would immediately be able to compare a 1 star with a 5 star support. Afterwards within each star level there might parameters that can differ like the amount of penalties, the 8×5 time zone, the nature and limits of the schedule maintenance windows, etc. So there is still flexibility and potential to differentiate through support.
Having a standard support offering would be one step closer for buyers to be able to understand what they are buying and for operators to be assured that companies offer a standardized high-quality service.
Standardization bodies could even make contract templates, certification programs, etc. to make sure post-sales support is uniform and easily understandable.
Telruptive is changing focus…
The Top Blogs
Want to reproduce a Telruptive post?
- #KlausStraub CIO @BMW is still showing customer-driven future cars at @tmforumorg @uber @TeslaMotors @google going to eat their lunch 11 months ago
- See my new posts on LinkedIn telruptive.com/2015/11/24/see… 1 year ago
- "Ethereum + IoT = smart contracts on connected devices" by @telruptive @mectors @ethereum @ubuntu on @LinkedIn linkedin.com/pulse/ethereum… 1 year ago
- RT @Agent_Analytics: "The State of #BigData" with Maarten Ectors @telruptive for my #Data Blog! #datascience #InternetOfThings #IoT https:… 1 year ago
- The EU should focus on wealth creation telruptive.com/2015/07/06/the… 1 year ago
- November 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- March 2014
- December 2013
- November 2013
- September 2013
- July 2013
- June 2013
- May 2013
- April 2013
- March 2013
- February 2013
- January 2013
- December 2012
- November 2012
- October 2012
- August 2012
- July 2012
- June 2012
- May 2012
- April 2012
- March 2012
- February 2012
- January 2012
- December 2011
- November 2011
- October 2011
- September 2011
- August 2011
- July 2011
- June 2011
- May 2011
- April 2011
- March 2011
- February 2011
- January 2011
- December 2010
- November 2010
- October 2010
- September 2010
All the contents of the Blog, EXCEPT FOR COMMENTS AND QUOTED MATERIAL, constitute the opinion of the Author, and the Author alone; they do not represent the views and opinions of the Author’s employers, supervisors, nor do they represent the view of organizations, businesses or institutions the Author is a part of.
The Author is not responsible for the content of any comments made by the Commenter(s).
While we have made every attempt to ensure that the information contained in this Blog has been obtained from reliable sources, the Author is not responsible for any errors or omissions, or for the results obtained from the use of this information. All information in this Blog is provided "as is", with no guarantee of completeness, accuracy, timeliness or of the results obtained from the use of this information, and without warranty of any kind.