Does Tech Support Count? Can Good Service Sell in the 21st Century?
Future Customer Support Tactics
The trend seems clear that MadCap is going towards the Tech Support angle for their business model. It’s an interesting angle of attack for smaller companies to chip away at the market dominance of large public corporations by using a cost center to do so.
Quoted from MadCap Software Selected as Finalist in 14th Annual AeA High Tech Awards: Financial News - Yahoo! Finance
…said Kevin Carroll, executive director, AeA San Diego Council. “Not only has MadCap built a top-flight engineering team to deliver ground-breaking advances in content authoring software; it also has bucked the outsourcing trend and instead established a local technical support team to provide the superior service that fosters customer adoption and loyalty."
The question is, will this create a better user experience, and therefore, a better product? MadCap’s CEO thinks so:
“We’ve made it our mission to deliver the ultimate customer experience through next-generation content solutions and a locally based, highly experienced support team that understands our users’ needs. It is a great honor to be recognized as a 2007 AeA High Tech Award finalist for our success in delivering on that goal,” said Anthony Olivier, MadCap CEO.
In my previous article, I’ve been posting about what feeds this situation. Well crafted communication cuts down on direct support calls, yet there are methods that creative technical support engineers can use to multipy their efforts.
Sarah said it best in her Information Age article, and I really could not improve on her concept in my quote of her:
I think it’s helpful to look at communication dimensions:
- Traditional technical writing is one-to-many. One person/team writes, many people consume it.
- Wikis are many-to-many. Many people write; many people use the information.
- Mailing lists are many-to-one. Many people respond to one persons’ question
- Technical support is one-to-one. One person calls; one person responds.
Technical support is the most expensive option; it’s also often the most relevant. Technical writing is more efficient (because the answer to the question is provided just once), but also less personal and therefore less relevant.
I think it could also be expressed as another hierarchy:
Technical Writing using Web 2.0
One to many, results returned allow focus on trouble spots.
Tech Support using Web 2.0 - one to many, many to many (peer)
This could be expressed as dedicated tech support within forums, independent tech projects seeking out troublespots, beta testing, etc.
It could also include a dynamic of the technical support reviewing the feedback from the Web 2.0 technical writing effort and problem solving ‘live’ updates to the documentation which are pushed out to the product.
Having docs updated live as a call reduction method for Tech Support as the product rolled out would be optimal. This was the concept of having both a server-based help file and ‘Airplane Help’ at eHelp during the X3 to X5 stage.
Tech Support moderated / monitored Peer Support
HATT, Adobe ACE users, MadCap Forums - many to many (peer).
I’m not sure what level of tech support involvement occurs with other companies outside of MadCap (I see them posting on the HATT regularly) but a lot of corporate policy forbids posting on user groups without specific necessity.
Here’s a Cluetrain real-world example of how positive this can be:
If you could hook up a meter to the forum and measure good will, the needle reading for Shuttle By United at take-off was way over on the negative side. Luggage was being lost (three times for one passenger). Passenger loading was chaotic. Customers were unhappy.
Then one United worker (one of those “owners” United’s ads talked about so much at the time) jumped in and simply started to help out. The response was remarkable. Here are a few examples:
“Good to see someone at United interested!” (etc etc etc 6 more example quotes)
This kind of conversation moved the meter all the way over to the positive side, just because one company guy took on the burden of talking with customers and trying to solve their problems. One guy.
Can providing better service actually win customers over?
It’s too early to tell, however the tactical advantage lies immediately with the larger company holding more resources; if they have an unlimited budget it would be a simple thing to just start pouring money into the technical support division.
That’s where the public part of the public corporation comes into conflict with the strategic part. If a product is not seen as core content to the public corporation, resources are scarce. The effect on the working managers themselves is to husband those resources carefully, showing the best bang for the buck and becoming risk averse to new technology adoption.
In a nutshell, public companies have an inherent talent for carving their costs with Technical Support being the most popular area to reduce through outsourcing. This leads to Cluetrain-predicted results, as burned users vent online and even go unanswered in the corporation’s own forums.
Theory - Risk averse behavior leads to less innovation
This could show its face in features - take a risk on new features which are complex, and you’ll have to support them if they don’t work out just right. Keeping things simple and maintaining a status quo gives resource managers a mark of safety; risk too much and you could lose your job if the strategy fails.
Posted by Charles in Technical Support |
