 |
Whether your product is an open-source script, a Web application or a downloadable product, you will need to provide some form of technical support. This article explores the subject based on my experience of supporting our company’s product, Perch, a small content management system (CMS) that we sell as a download for people to install in their own hosting space. Our support has been a key factor in the success of this product, not just because users love responsive support, but because we have used what we have learned from users to improve the product.
Don’t Underestimate The Importance Of Support
As Eran Galperin says in “You’re Pricing It Wrong: Software Pricing Demystified� on Smashing Magazine:
“A commercial product that comes with support will often win over customers who want that assurance that someone will be on the other end of the line should they need it.”
Support can be a key selling point, a reason for a person to choose your product over the competition. In our case with Perch, the competition is often free software, so including unlimited support with a license is a big part of why someone might choose us over a competitor. Even for products aimed at technologically literate users, knowing that someone is on hand to answer questions or fix bugs can influence the decision to buy or sign up.
Don’t Underestimate The Time This Will Take
Users will always need support. You could have a bulletproof product and the most excellent tutorials and documentation, and someone will find a way to break it or just not read the information staring them in the face. Later in this article, I’ll explain some ways to minimize support requests and the time spent in dealing with them. But you should expect to offer support and build it into the price of your product.
Your support systems should also help you track the amount of time being taken up by support, so that you can plan for future requirements. If you are a small company whose product developers are supporting the product at present, knowing the amount of time each license or user requires for support on average will enable you to project when you might need to hire additional support staff.
Methods Of Providing Technical Support
When launching your product, decide how you will support it. Depending on the product and the people using it, you might offer some or all of the following types of support:
- Phone,
- Email,
- Social media,
- Ticketing system,
- Real-time chat.
Phone
Supporting users by phone is time-consuming, but for some types of products, it can reassure potential buyers, particularly if they are not Internet-savvy or if the product handles sensitive information (for example, financial or health data). Users might trust the product more if they know they can speak to a real person. You can take phone support further by offering a remote-desktop feature to help customers right on their computer.
We chose not to offer phone support at Perch, because the support requests we get generally require us to look at a customer’s config file, diagnostic report or template code. So, an initial phone conversation would simply raise the cost of supporting customers, because we’d have to ask them to send this information by email or some other way.
If you do provide phone support, clearly state when it is available, including time-zone information. Also, keep track of the time you spend on this and the issues that customers raise so that you can combine it with the information that you collect via email or your online help desk.
Image source: Opensourceway.
A lot of companies start with email support. Simply publish an email address, and answer queries as they come in. The advantages are that you don’t need any additional software, and everyone uses email. However, it gets tricky if you are not the only person supporting the product. If all of the support staff logs into the same mailbox, two people could very easily answer the same query, or a request could get ignored because everyone thinks someone else is dealing with it.
Email is also less than ideal for tracking requests over time and for working out the amount of time you spend dealing with them. You also need to be quite disciplined at filing away “closed� requests before your inbox descends into chaos.
If email is your predominant support mechanism, then consider setting up template responses to common requests, much as you would use canned responses in a help desk system (as I’ll describe below). Don’t forget to keep improving, adding to and correcting these responses as your website or product changes. Inadvertently giving out old advice is easy when these templates get out of date.
Social Media
Support via social media has become so important that many large companies are far more responsive on Twitter than via traditional means. Social media should be a part of your support system, but it shouldn’t be the only way that you help people. Being able to quickly respond to someone who is having a problem or has a question about your product is incredibly powerful. We have set up searches in our Twitter clients, so as soon as someone mentions Perch, we can respond. If a person mentions that they are trying out our demo, we simply say, “Let us know if you have any questions!� and we leave it at that. It is important that you not appear to hound potential customers; just give them a way to ask informally about anything on their mind.
If you have staff dedicated to support on Twitter, make sure they are empowered to help people. Many large companies have dedicated Twitter support personnel who only seem able to direct people to answers on the company website, which is often more frustrating than helpful! T-Mobile in the UK handles Twitter support very well via its @TMobileUKhelp account. Its support personnel is able to deal with most of the things that the phone-support operators handle, once the customer has verified their identity via direct message.
Small companies can do social media really well, often better than large companies. If a customer is using Twitter to vent their frustration, a couple of quick and helpful messages can turn them from “I’m so annoyed� to “Wow! Support for this product is amazing!� People are generally very understanding about problems as long as they can get help quickly.
A lot of support requests are hard to deal with on Twitter, though. For example, at Perch, many questions require us to see the user’s code or to ask them to try something. In these cases, you need to be able to direct them to another channel, whether a ticketing system or even an email address. Long discussions over Twitter tend not to be very helpful; so, unless I can answer the query in one or two messages, I point the user to our ticketing system or forum, where I can pick up the conversation and provide better information.
Ticketing System
I would suggest that anyone with a commercial product use some kind of ticketing system. This support system can often be combined with the methods listed above. For example, many systems can turn incoming emails into tickets, or can log phone sessions in a useful format, or have an interface where users can submit tickets directly.
Ticketing systems make the process of providing support easier when multiple staff members are involved, because you can see whether a request is being responded to and who is working on it. They also make it far easier to keep track of the support requests coming in and how much time they are taking up.
To use a real-world case study, when we launched Perch just over two years ago, we started using a hosted software-as-a-service system called Tender. Tender is a fairly lightweight system that allows users to submit tickets that are either public (visible and answerable by anyone, not just support staff) or private (visible only to support staff).
We were happy with Tender, except for a couple of issues. First, we didn’t want our ticketing system to function as a forum, so we set up a separate forum elsewhere. But this meant that people had to look in two places for answers: the forum and the ticketing system. Our documentation was also located elsewhere. Secondly, because anyone could view and respond to support queries, we often saw customers themselves replying to tickets submitted by other customers; often the advice was helpful, but sometimes it was incorrect or confusing, and customers couldn’t tell the difference between official responses and responses from well-meaning customers. There wasn’t a way to stop this from happening other than to make all tickets private.
It became obvious that Tender, while a good system, just didn’t suit the model we wanted to use for support. This, it turns out, is key when selecting a support system — far more important than the feature list. When looking for a support system, decide first how you want to support your customers, then assess each system against that model to see whether it fits.
Having decided that our initial choice of Tender wasn’t quite working out, we made a list of what we wanted in a support system:
- A system with tickets and public forums all in one place (plus, the ability to publish documentation on the same system would be ideal);
- Excellent support for multiple people responding to issues;
- A system that can handle HTML and code examples being posted by customers and by us as responses;
- Statistics to enable us to track tickets, response times and so on.
We started to research, and we asked on Twitter which support systems people liked. Zendesk quickly rose to the top of the list, and were it not for a long-standing issue with code formatting, we would probably have used Zendesk. I really liked the integration of social media in the product; however, while this was a nice to have, the problem with the code snippets was a deal-breaker.
We then looked at Assistly. It is another feature-rich system, but it felt a little too oriented around email and self-service for what we wanted. It felt a little impersonal in some ways, and our decision came down to it just not fitting our model and how we wanted Perch support to look and feel.
Finally we were pointed to HelpSpot. HelpSpot doesn’t have as many features “on paper� as the other two systems we looked at, but, crucially, it supports the combination of forums, tickets and documentation that we were looking for, thus enabling us to support customers the way we wanted. After trialling version 3 of the product, which was still in beta, we decided to move our tickets, forums and documentation to a self-hosted installation of HelpSpot.
All of the systems we looked at are good systems with excellent features. Ultimately, it came down to which best suited our model for providing support. Having figured that out before testing the systems in trial, we were able to choose more easily between them, and we are still happy with our choice a few months after having made the switch.
Real-Time Chat
Real-time chat-based support is a feature of some ticketing systems, and is also available as a standalone service (as with Olark). We do use this with Perch, although primarily for pre-sales queries rather than for actual support. Like Twitter, it can be a really good way to quickly answer a question, but for longer answers and code samples, dealing with people in the main support area is much easier.
Real-time support on websites can be helpful for companies that offer a service. With Olark, you can see exactly where someone is on your website as you are talking to them, so guiding someone through a potentially confusing process would be simple. It does, however, require that someone be available to provide this support should users come to rely on it. With a ticketing system, people expect some delay in getting a reply.
How To Reduce Support Requests And Time Spent Dealing With Them
You will never eliminate support requests completely, but you can do a lot to minimize them and to reduce the time you take in dealing with them.
Design Support Requests Out of Your Product
With Perch, we actively try to see support requests as an indication that something needs improvement or clarification in the product or related support material. By tracking requests and seeing where patterns emerge that show people running into problems in certain places, we are able to prevent the problem from occurring or provide better support material.
For example, before logging into your Perch admin account on your own website, you need to go to your account on the Perch website and specify the domain where Perch is installed. You can actually set two domains — the live and test ones — but before you can use Perch, you need to set at least one of these.
In the past, if you hadn’t set a domain in your account, then when logging in you got a message saying, “Sorry, your license key isn’t valid for this domain.�
People who didn’t fully read their email invoice might have missed the bit about setting up domains and so would have been confused when they saw this message, and thus submitted a support ticket. In an update to Perch, we changed this process so that if an administrator hadn’t yet entered any content, we could detect that they were a new user who just needed to configure their domains and so prompted them to do so (giving them the domain that they needed to register in their account). Support tickets were no longer submitted for this issue.
Designing support requests out of the product as much as possible obviously benefits us, because the less support we need to provide per license, the more profitable our product is. But it also gives our customers a better first experience with Perch. Being confused and needing support before even logging in isn’t a great first impression.
Build Debugging or Diagnostic Information Into the Product
Perch is a product that people download and install in their own hosting space. As you can imagine, we are now experts in the many bizarre ways that shared hosting providers configure PHP! We needed a way to get information from not very technical users about the environment in which they were running Perch. To do this, we created a diagnostics report that gives us a lot of information about the server that Perch is running on, which apps are installed, what their path to Perch is, and so on. The report, coupled with the user’s query, often gives us enough information to answer the support request right away.
Building in some diagnostic information that users can find and send to you could save a lot of back and forth, especially if your product or app is self-hosted and can be deployed in a variety of systems.
Add Features to the Product
If many of the people requesting support are asking about how to do something that your product doesn’t currently do, then it would be worth thinking about how you might accommodate this as a feature. While your ideas about what your product is and is not might be pretty fixed, you need to have some flexibility. In our case, Perch is “a really little CMS,� designed for small websites. When we launched, we thought that people wouldn’t need features such as undo, create drafts, edit drafts and previewing. It soon became apparent through support that our users very much wanted these features, and so we found a way to add them without bloating the software. Use your support requests to help guide development. Once it becomes obvious that someone is asking for something that Perch doesn’t do, we will often ask them, “How do you see this working?�
Provide a Range of Support Material
People learn how to use apps in a variety of ways. I like to read documentation and play around with code. For many people — especially visual learners — actually seeing things happen is much more helpful.
We were getting support requests from people who were obviously confused by our documentation. But we also heard people say how good our documentation was! What was going on? Blaming the first group for not understanding the documentation would be tempting — but once you decide to blame the user, you miss an opportunity to help people in different ways.
To help visual learners, we started a series of video tutorials. Currently, these videos just deal with the basics of using the product, but they have made a huge difference to the number of people we have to handhold through the website-building process. Frequently, we will point someone to the tutorial and then not hear from them again until we see the first post on their newly launched website. In the past, we might have seen a number of tickets from them during that process. The lesson here is to provide material in different formats and for different levels of users: bare documentation is important for technical users and for those who like to read quickly and get on with it; step-by-step examples and videos will help others.
Use a Support System That Lets You Create Template Answers
Often we need to ask people who request support for additional information, such as the diagnostics report mentioned above. HelpSpot lets us store these answers and punch them in as responses in one click, saving us time on the initial interaction. If you can reduce the time spent saying the same things, then you will have more time to dedicate to solving problems and working on the product.
Image source: Opensourceway.
How to Phase Out Support for Old Versions of a Product
If you sell desktop, phone or self-hosted Web software, rather than software as a service, you might need to consider what to do about supporting old versions of your product?
Traditional software companies tend to give users sufficient warning that support for an old product will end on a particular date. Security patches are often made available past that date if flaws are found in the old product, but no other fixes or changes are made. For example, Microsoft’s mainstream support for Windows XP Professional ended in 2009, although “Extended� support (which includes security patches) will continue until 2014.
The most important thing is to be fair to customers and give them plenty of notice of the end of a product version’s life. Your company needs to make decisions about the status of old versions far in advance of doing anything about it, and let customers know when support for an old version might end or be limited to critical security issues.
Some Final Thoughts
A question we are often asked at Perch is, “Is the support a nightmare?� It is all too easy for software developers to view support as a necessary evil, a part of the job to deal with as quickly as possible or even to outsource. If you approach support in this way, then you are missing out on a chance to make a real difference with people. You are also missing out on product improvements that you could have made by listening carefully to customer requests.
I firmly believe that software developers should provide their own support — perhaps not all of the support, if the product is popular or gets a lot of non-technical requests on the front line, but certainly some of it. It’s only by seeing the pain points firsthand and helping users through them that you can start figuring out how to solve them — and solving problems should be what we software developers do best.
Further Reading
- “Seven Steps to Remarkable Customer Service,� Joel on Software
- “On Scaling Customer Service in a Startup,� David Noel
- “How to Use Twitter for Customer Service,� Mashable
(al)
© Rachel Andrew for Smashing Magazine, 2011.