Archive

Posts Tagged ‘social CRM’

Telecom customer support 2.0

February 6, 2012 Leave a comment

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…

Changing from Telco Grade to Web 2.0 Grade by fighting telecom myths

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.

Oracle RAC

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 should act like VCs when it comes to innovation

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.

Telco PaaS is not Telco Assets and PaaS

April 11, 2011 2 comments

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:

  1. Telco PaaS services need to be launched in weeks not years.
  2. Telco PaaS services will be buggy, unstable and fail.
  3. Telco PaaS services can not be supported via a call center.
  4. There are no Telco PaaS standards and there are likely not to be any until it is too late.
  5. 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.

Telecom Greediness

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 container for long tail post-sales support – part 2

February 25, 2011 1 comment

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.

%d bloggers like this: