At most companies, customer and technical support are the least resourced, least important and least respected functions. How else can you explain why so many large companies treat their customers – their paying customers mind you – like something that should be scrapped off the bottom of their shoes?
Whether it’s voicemail hell and 45 minute wait times or “knowledgebases” with 250,000 pages that tell you exactly nothing or “self-help” online forums where unanswered pleas outrun useful information 100:1, the message is as clear as a slap in the face: screw you, buddy, go away. I for one as a microISV/startup hope these companies go right on treating customers like dirt – because they’re minting new customers for me and mine.
Put another way, the design, delivery and infrastructure of your customer and technical support can be a key strategic competitive advantage for your startup or ISV against your traditional ISV competitors. In this post I’m going to cover five key ways of turning your startup/microISVs tech and customer support into a factory assembly line where disgruntled and upset customers go in at one end and (mostly) come out the other, singing your virtues and bothering their coworkers with this neat app they just have to see. Done right, and the software systems and procedures you put in place become an awesome leverage point: single solutions solve multiple problems and improve multiple things. This is a good thing when you live in the startup world.
1. You’ve got to have a system.
If you go to this page at Wikipedia, you’ll find over 100 bug/issue tracking open source, desktop and web based software solutions. This tells us:
- There is no one “best” bug/defect tracking application: there’s only a very wide range of approaches catering to different kinds of organizations and situations.
- Developing a bug tracking application as your startup or microISV’s product is probably not a good idea. :)
- You can spend way too much time on this very easily.
While I’m sure there are many other good defect tracking packages out there, there’s only two I recommend to microISVs and startups: FogBugz and HelpSpot.
This isn’t the place for product reviews, and there are certainly other apps worth considering. But these two defect tracking/customer support apps meet the key criteria for startups and microISVs:
- Comprehensive: All customer support requests – whether their from your web site, via your application, email, phone, or even snail mail need to go in to, and be accessible and analyzable from, one interface.
- Lightweight: The programmers behind Fogbugz and Helpspot have sweated down the number of clicks, steps, hoops and hurdles you and more importantly your customers have to jump through.
- Respect the Customer: Way too many “help” system are there to serve internal company politics, an obsessive need to collect customer data, or are actually designed to resemble the migration path of salmon – struggle upstream against every obstacle until you die at the end. This is not what you want.
- Looks count: Especially if you’re going to be using an app day in and day out. The interface has to be attractive, professional, easy to navigate and logical – kind of like your startup should be! It needs to wear well, not refusing to shed it’s database roots and not being a slave to whatever set of colors are in fashion this week.
- Prioritizes by Pain: Specifically, the system should help you identify not only where your code broke, but how frequently, under what configurations and how painfully for the user. While most bug tracking systems prioritize by severity, what really matters in my opinion is how much user pain does that bug generate. Put another way, if you have 3 hours and only 3 hours to devote to bug fixing today, fix the bug that causes the most pain to the most people – even if that bug is not as severe as bug that crashes the app or OS of one user out of a thousand. That may sound coldhearted, but that’s business. Your system needs to let you identify and quantify Customer Pain.
- The Least amount of User Effort: Speaking of customers, the reality is that seldom can users provide any information that’s actually useful in determining what broke your code, and you will be one frustrated developer if you hope your experience will be different. The reasons are many – but the solution is to do everything you can to automate collecting the data you need about each defect, once your customer approves sending you that information.
- Robust: I really, really like open source software and totally appreciate the contributions so many programmers better than I have made that I use on a daily basis. That said, I don’t trust my business and don’t want to spend endless hours trying to fixing bugs (oops, contributing to the community) in “free” software. I want someone somewhere I can call (Skype works well for this) and scream at, “I paid you good money for this piece of crap, fix it yesterday!!” (like most doctors of software, I make a lousy patient :)). Seriously, I trust people who think like me: Make great product. Collect much money selling great product. By tropical island.
2. Human in box. Handle with care.
Providing support people rave about is not about fixing bugs or explaining functionality: it’s about people. In other words, if you fix only the technical issue, you’re only half done: you need to fix the relationship with that person. That usually can be done to great effect by acting like a person, treating the customer with the problem as someone with a problem you share, not as if they are the problem, and acknowledging the favor they have done for you by reporting this defect in the first place. Favor? Yes – favor: because for every bug report that’s not about actual breaking code, there’s a good five people who will hold their tongue and either stew silently or just abandon your app.
The people who are reporting bugs should at the very least be paid in a bit of respect: they’re helping you improve your product, improve your sales and reduce the stress in your life. Treat them nicely. If being nice for the sake of being nice is too Bambi-like for your non-vegatarian tastes, let’s look at the issue from a social Darwinian dog-eat-dog point of view.
Pissed off customers are promiscuous customers – they spread their unhappiness, anger, contempt and scorn for you and your software far and wide. And now with a social network under practically every Internet-laden tree, those seeds of discontentment will find plenty of places to germinate as those angry customers desperate for something to talk about find something to talk about alright – you.
Since you can’t willy nilly shoot the SOB’s who are going to badmouth your software because they have a problem that everyone else using your app seems to have avoided, the next best business dog-eat-dog sort of thing is treat them with just enough respect and consideration to keep their yapping tongues still – positivity kill them with kindness and understanding! May the Bambi-people are on to something…
3. Some things you don’t want to do
- Act unprofessionally. You will be tempted to respond in kind when a customer dumps abuse on your product, on you and maybe your ancestors. Don’t. Yes, I know you will feel better, but don’t. Whether its a phone call, email, bug report or blog, you will come to regret fighting fire with fire. At best, you will lose a customer. At worse you will hang a stinking Internet Albatross around your neck that every Google search for the next hundred years will find.
- Agree to fix the defect. Wait a minute, shouldn’t you fix any and all defects in your app? Yes – but at a time, place and manner of your choosing. Agreeing to fix “the bug” sets an expectation you may for good business reasons not meet – and that becomes a bigger problem than the original defect.
- Agree to add a feature. Feature requests usually come in via the same routes as bug reports – but they are very different. While you should definitely encourage and welcome feature requests, you need to think long and hard about which new features will be implemented when – if at all.
- Just fix the damn bug! Fixing the bug is certainly a good first step – but it’s only a first step. Allocating the time to eliminate the source of the bug is highly useful, it’s called leverage, as we’ll see in the next section.
- Expect to solve every single customer problem. I have some bad news for you. It won’t happen. Not in this life or the the next. There will always be bugs that defy logic, gravity and your best efforts and remain unsolved. There will always be customers who think their $24.95 bought them hours of entertaining spleen venting at your expense and who don’t want you to solve the bug, but suffer. That’s just the way the business world works – get over it, grovel, give them their money back and get them out of your life as fast as you can.
4. Do what the big banks do. Leverage.
You may have heard this week and last about a few problems on Wall Street – an institution here, an insurance giant there and suddenly the guys who wear suits worth what you make in a quarter are sweating fear like convicted murderers talking their last walk in the Big House for a date with the Hot Seat. Before these guys – who used to offer you financial advice – got into a little liquidity problem, these guys had the concept of leverage down cold.
Now I’m not sure how this works, being a programmer, but I’m told a sound bank leverages each dollar of assets by loaning out ten dollars. The Wall Street banks and things that look like banks like insurance companies pushed this leverage thing way past 10:1 – they danced on the burning tightrope to the tune of 30:1 or more. Don’t do that. Instead, leverage each and every customer support request – either those generated automatically by your app or by customers who email just as you’re about to knock off for the day – by looking at each as two tasks to do, not one.
The first task is to acknowledge that the customer has a legitimate complaint, and that you will address it. The second, is find out what the hell went wrong and fix it before you get even more reports. That second to do is more than just fixing the code – it means putting in place a test or two at least so you know that bug can’t happen again. It means more than just rearranging controls on the screen – it means taking the time to get actual customers to give you feedback on your user interface – if only that one screen. It means not just adding more words to your help file – it means asking yourself if that’s really the right way in this day and age to help your users and get out of your comfort zone and create your first 30 second screencast.
Unlike the Wall Street wizards now getting into Uncle Sam’s trillion dollar breadline, your leveraging will pay sound financial returns in the form of fewer support calls, more happy customers and more prospective customers in the future. It’s a sound investment.
5. Now leverage the leverage.
No, I’m not talking about financial derivatives- those semi-magical financial instruments that no one actually understands except bipolar geniuses – I’m talking about investing the time needed in practices and processes to repeatedly and reliably convert those sludgy customer complaints into shiny, customer-attracting objects. Let’s look at three:
- Automated Software Testing: Startups and microISVs blow off functional tests, integration tests let alone do Test Driven Development or Behavior Driven Development. I know I did. But the more tests you have the fewer bugs your customers find. Every time you fix your code write a test or two so that bug stays dead. Call it I Hate Tests, but I Hate Bugs More Development. Just remember the fewer bugs you have, the fewer irate customers you will have to deal with. As these tests accumulate, as you start getting addicted to seeing the Green Good rather than the Red Bad light go on over your code, as you dip your foot in TDD pool next time you add a small feature, you will find that Testing is a startups best friend: far more reliable than a VC and far more likely to leave you in control and make you money.
- Show, don’t write: For conceptual defects, for places where users just don’t get it, which do you think is more effective: 5 pages more of documentation that no one is going to read or a 30 second video showing exactly what to do? While that first video may take you five hours to create, the second will take you two hours and the third 45 minutes. Creating adequate screencasts (we’re not talking Star Wars here, but YouTube) can be come an easy way to explain your app in multiple settings. The more of these you do, the easier they get, the less time they take, the better they get and the more you can use them as marketing vehicles.
- Convert boos into cheers: Here’s a simple trick to turn a customer complaint into a customer advocate for your software: after you resolve the issue, wait a week, then send them an email or ecard: Dear X, Just wanted to check in with you now that it’s been a week. How’s it going? Any questions or suggestions? Thanks, You. Just this much – nothing heavyhanded, complicated or marketing-like. We’re small companies – we can and should! – act like people, not big corporations.
This post was written for Avangate by special arrangement. But I’d say the same thing anywhere anyway.
