I would love to hear the types of customer support that are most requested. A few that come to mind include:
Those are the few that come to mind.
Thanks for the discussion, cheers!
I sell scheduling software SaaS for a niche in the medical world. I label my emails “question”, “problem”, “suggestions”, or “administrative” (anything related to paying, changing account names, etc…).
questions: 50%
problems: 17%
suggestion: 10%
administrative: 35%
Some emails are double-labeled, so that’s why sum > 100%.
I don’t differentiate between pre-sales and post-sales questions (probably should).
I also label phone calls and it’s a similar ratio.
Some of the “problems” are actually users thinking there is a problem, even though they are actually mis-using the software or expecting magical things to happen. I use the tone of the email for the label, not the actual existence of a bug.
Note that I sell to institutions and accept POs, and my users/contacts are not very computer-savvy which is why the admin label is fairly high.
To lessen the burden I have found that making the software gobsmackingly self-explanatory really helps with the “questions”. I could cut it down further with top-notch high-level overview articles of capabilities and best-practices.
Also I fix bugs ASAP when I identify them. This cuts down on the “problem” label, churn, and abandoned trials.
I feel like, as the creators, we are responsible for these misconceptions. These types of questions are also the ones I’m most concerned about because I feel like they can be avoided.
I agree. A user-friendly interface and ways to engage the customer and focusing on opportunities to educate them are going to be my key focus. I believe I will be contending with needing to educate the customer about my service and the problem itself.
Thank you for your insights!
I agree. However from my experience there is no way to eliminate these kinds of issues. No matter how good your UI/UX is, if you have enough people going through your system, there will always be some who don’t quite get it and will ask for help. There will also be some who aren’t used to figuring things out themselves and will require handholding no matter what. It’s human nature. (And it also depends on your market.)
Great question. From my perspective of supporting an on-premise application for 8 years before my SaaS app SaaS support is essentially nothing.
If you take sales questions out of the picture actual technical support will be almost entirely bugs and how-to questions. An occasional billing issue.
In fact I think with SaaS you have to go more out of your way to encourage users to chat with you from time to time just to keep some interactions with them. Install your support tools widget inside the UI (Snappy of course!), email customers beyond your trial drip sequence out at 3 months, 9 months, etc.
That’s promising!
Very interesting perspective. I was approaching customer support with the belief that fewer inquiries = better.
Your thinking, which I value given your experience, represents a new paradigm in customer support. Interestingly, it’s not new to me as a consumer but as a business I was thinking about it all wrong. I’m starting to think about customer support in two categories, positive and negative. Realistically, any customer support inquiry could have a positive or negative outcome. It’s not dependent upon the type (i.e. bugs, education).
So, the question could be redefined. How do you encourage a positive customer support experience?
Generally less support is better of course, but in a bootstrap size business usually support and sales are pretty much one thing. So that’s where you have to think about it a bit more because you get a lot of valuable insights from customers, but with SaaS there aren’t as many logical points of contact as with more traditional download software since it is so easy to self service.
The elements of positive service are still pretty much the same to me. Respond quickly, respond in an appropriate tone, go the extra step when you can, things like that.
I think the best way to encourage people to call/email even when they don’t have a dire problem is to give them a very good support experience when they do call because of a problem. Show empathy, be clear, be honest, be helpful, and fix those bugs promptly. After a while you’ll develop a reputation for being a helpful straight-shooter and people will feel they can contact you when they have a small positive thing to say.
Also, as @ian has said elsewhere don’t use a ticketing system that exposes the ticketing system to the customer. Nothing can make your customer feel like a pawn in a system more than a machine that sends cryptic passive aggressive emails like “your ticket will be closed if you don’t…”.
I also recommend getting a voice phone number and talking to your customers. You can make a personal connection with voice that you can’t with email. This too will help people feel comfortable, and you will gain insights into how people really feel about your business that you can’t really get via email.
“Nothing” being a relative term I thought I’d share my SaaS support overhead relative to number of paying customers:
Total number of phone calls (sales and support) / number of customers = 0.75
Total number of Minutes on phone (sales and support) / number of customers = 7
Total email threads (sales and support) / number of customers = 1.8
All these numbers are Per Year. Meaning I get 1.8 email threads per customer each year.
Just because I make tools that provide useful statistics doesn’t mean I want to note them 
For reference our on-premise app does about 4 tickets per customer per year (though I’m not big on averages in general). I don’t have time to break it all out but this number is off some by people who aren’t customers but had other sorts of questions and some other stuff. In any case, it’s certainly much higher than Oliver’s .75 and I would suspect the number of interactions back and forth and time spent on solving the tickets was dramatically higher. Debugging Windows IIS just takes longer than telling someone how a feature works.