Long tail support challenge. Can reputation be the solution?
Launching thousands of services in a long tail marketplace might not be as hard as it used to be. However supporting millions of users with these thousands of services definitely is. Technology seems not to be the limitation of telco long tail, support and monetization are.
What support is needed?
Consumers as well as small, medium and large enterprises have different support needs. For simplicity let’s focus on small and medium. Hundreds of thousands of those are available in most countries. Often IT skills are in the best case basic. No dedicated IT staff. Just a helpful colleague if any. Time and resource shortage are plenty.
Before reaping the benefit of any long tail service, people will have to learn about what is being offered: product awareness. Additionally once the product is purchased, help with configuration/customization, product training, product integration, consultancy, product questions, etc. Finally when things go wrong: rapid workarounds and bug fixes.
Traditionally telecom operators have used sales teams, help desks and support organizations to offer more basic types of support. Scaling these organizations up to provide the previously listed items is often not possible. And if it were, it would be economically inviable.
Why is long tail support different?
Google, among others, promotes a services-based marketplace inside its Google App Marketplace. Although a step in the right direction, it will not resolve all the issues.
These long tail services could be an answer for established brands and the more straight-forward support tasks like product training. However a developer that on a Sunday afternoon builds a cool app and all of a sudden is surprised that 50.000 companies downloaded it on Monday, is not able to offer any reasonable support.
What do small mom&pops support services need?
Specialization and economies of scale would be two key factors. The “lucky developer” has specialized skills around application development. However does he or she has knowledge about how to integrate a corporate single sign-on solution into it? Probably not. Also when the developer will be helping one company, he will not have time to help another one.
So our “lucky developer” will need people with additional skills and be able to increase his/her bandwidth.
Option 1: Community Support
By offering the tools on the marketplace for an online support community to build around this “lucky app”, companies can help one another and don’t repeatedly ask the developer the same type of questions. Some communities have demonstrated to be offering faster and better support then most commercial support organizations. However there is a problem here. Bug fixes can only be provided by the “lucky developer”. (S)He can choose to open source the application code but that would very likely allow others to quickly copy and extend the app and destroy all market advantage.
Option 2: Commercial Product Support
The “lucky developer” can foresee potential success and hire some external company that gets trained on the app and is able to resolve most of the bug fixes. A trusted third-party that can have an escrow with the “lucky developer” and take over development in case something happens to him or her.
However this would take time and would only take place for those apps that have a steady growth to success, not an overnight craze.
Some tools could be beneficial here. Version control to share proprietary code with authorized third-parties to let them generate patches and in case of a deployed application access to a mechanism to test and deploy an updated version. Also standardized CRM solutions and multi-channel helpdesk access can offer a unified and high-quality service even for one person support companies.
Option 3: Commercial Specialized Services
Even if a third-party company gets trained on a product, this does not take away that customers will demand specialized services that are outside of the scope of product support. Examples could be security audits, SLAs about service availability, integration support & consultancy, performance benchmarking, commercial volume discounts & pricing, marketing, legal support, etc.
By itself this can be a totally new services marketplace in which both the “lucky programmer” as well as its customers can contract these services.
Tools are completely different based on which service is offered so standardized tools are difficult. Probably tools could become SaaS offerings from third-parties.
Option 4: Reputation
Bringing together community support, commercial product support and commercial specialized services is not enough by itself. All tools will not help without one key aspect: reputation.
How can the “lucky programmer” differentiate between 50 lawyers, 350 security experts, 20 performance benchmarking firms, 30 SLA validation agencies, 120 technical support help-desks, etc.? The answer is reputation.
If a security expert has found security holes in some of the most famous Internet sites and he certifies your application then this means that your application is having a reputation of being save. The higher the reputation, probably the higher the fees the “lucky programmer” has to pay. So not everybody will be able to afford the best, especially in the beginning. But then again, sometimes companies with a top reputation might want to offer their services for free for those “lucky programmers” that are likely to get them free press.
The same is true for buyers. If you see that an SLA validation authority, that is generally trusted, is certifying that the services was up for 99,9999% in the last 24 months then you probably want to buy this service over a service that is slightly cheaper but has no reputation for reliability. Also you will want to buy bug fixing support from an organization that was able to meet a very tough SLA in the last 24 months and has all its customers raving about it.