Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike speak from their first hand experiences about how to structure a SaaS support team as well as the tools they use.
Items mentioned in this episode:
Transcript
Rob: In this episode of Startups for the Rest of Us you are about to hear, Mike and I discuss how to structure your SaaS support team. This is Startups for the Rest of Us, episode two hundred sixty seven.
Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at launching software products, whether you’ve built your first product or you’re just thinking about it. I’m Rob–
Mike: And I’m Mike.
Rob: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, Mike?
Mike: You know, as you read the intro I totally thought you were going to mess it up.
Rob: Yeah? That was from memory too. I didn’t even read the doc this time, unlike at MicroConf Europe when I was trying to intro the conference and froze in the middle of the intro, and you had to pick it up. That was a moment.
Mike: Yeah, that was rather interesting. I thought about singing a song or something like that but I couldn’t come up with anything good on the spot.
Rob: You bailed me out. So, what’s going on with you?
Mike: I talked a little bit about it last week, about taking pre-orders for the product I’m working on it. I’m up to ten pre-orders at the moment, and I’ve got some more that are going through the decision making process, and the a few more that need to be scheduled. But I’m thinking about breaking some ground on the code right now, and working out exactly what the timeline is going to look like and whether or not everything is going to make it because that’s still a little bit in flux but things are looking good so far.
Rob: Congratulations, man.
Mike: Yeah, I want to do – in parallel – some testing with some paid advertising to pull in some cold leads, and do a little bit of experimention to figure out what that marketing plan is going to look like post-launch, but I think I have a good handle on exactly what people are looking for and how to position it.
Rob: One piece of advice I’d give is get that landing page up now. Even if you’re not going to run ads to it, eventually you’re going to mention the domain name here on the show, people are just going to start talking about it, it might show up on Twitter, and you want to be able to send them somewhere and have them be able to enter their email. So, if you don’t already have that up I would do that before I touched any code.
Mike: Yeah, that’s definitely on my list of things to do. I’ve been–I wouldn’t say pushing off, but it’s just been a lower priority just because of all of the other things that are going on. So yeah, I recognize that I’ve got to get that done. Even the people that I’ve given a demo to have looked it over there and said, “Hey, there’s no landing page or anything here!” There is a place where they can pre-order, but there isn’t really any content there.
Rob: Right. Have you already created mockups, and you feel like the folks who have pre-ordered know what they’ve pre-ordered, like it’s very locked down?
Mike: Yeah, I spent probably twenty to twenty five hours working out the mockups and building the entire UX for the application, and the demo process that I went through with these ten people who have pre-ordered–I spent anywhere from 25-30 minutes is on the really low end, but the vast majority of them were 45-50 to 60 minutes. I think the longest one was about 2 to 2 1/2 hours; walking through exactly what it looked like, how it would work, answering any questions that they had, working through different scenarios and things like that so everyone who has pre-ordered I believe has a pretty good idea of exactly what it is that they’re getting.
Rob: Very cool, so you’re just itching to get into the code, aren’t you?
Mike: Yeah, and that’s something that I’ve been holding back on.
Rob: Yeah, it’s always a good idea to fight that urge as long as possible.
Mike: Right.
Rob: Because once you get into the code you become hyper focused. I’m not saying you, just in general, developers, we get sucked in.
Mike: Yeah, tunnel vision is really what it comes down to.
Rob: Yeah, there you go. So, I have a couple of things, one is, if you’re listening to this and you didn’t know that I have another podcast that I record with my wife, I wanted to tell you about it. Episode 45 of our podcast “Zen Founder” seems to be catching some people’s eye. It’s about getting your spouse on-board with your startup aspirations. I saw you had recommended it to someone via email, and some other people were emailing and tweeting about it. So if you haven’t checked out Zen Founder, it’s in iTunes obviously, ZenFounder.com. You might want to start with episode 45 because it seems to have resonated with a lot of folks in the boot strapper space. The other thing I wanted to mention is, if you’re not connecting with Mike and I at Twitter, come check us out. I’m @RobWalling and Mike is @SingleFounder.
Mike: So, what are we talking about this week?
Rob: Today I wanted to talk about how to structure a support team. I think we’re going to focus mostly on SaaS. This would probably apply to any type of downloadable software, membership sites, info products. They all have similar issues, and I really want us to speak from experience. I’ve been making it up as I go along for sure. There are experts in this space, Sarah Hatter has built her career on being a SaaS support expert, and spoken at MicroConf a few times. So she has a lot to say about the mindset and how to organize a team, and replies, and how you should handle things. Today we’re going to talk a lot about structure, first hand experience, and the tools that we use to get the job done. I think we’re going to break this up into a couple of areas. The first is email, because that’s where a lot of your support is going to come through. The second, third and fourth are going to be shorter; talking about knowledge bases, live chat and potentially phone/Skype if you end up doing that.
So, to dive into email — it’s interesting because years ago when I had small info products and downloadable software, I was doing all support via Gmail. I basically had a number of email addresses piping into G-Mail, and of course you can then “send as” when you replied and that actually worked. If you’re one person doing support, it’s not totally sustainable, it doesn’t scale that well to not have tickets, and not be able to make notes, and all of that stuff, but I think it’s the best way to get started right off the bat if you have just a small, simple product and you just want to, kind of, do it. But you’re going to want to transition out of that when you hit any type of a scale and move into a system like Help Scout or Groove. From Gmail, there was no Help Scout and Groove when I transitioned, and I moved into Fogbugz which I stayed with for many years. We used it both for issue tracking and for support and, frankly, we outgrew it and it became a little long in the tooth. They haven’t updated it with a ton of new stuff, and so now we actually do use Help Scout and we really, really like it. So, this is how we support my email marketing app, Drip. Help Scout has a lot of advantages over other tools that I’ve used in the past. Basically there are a ton of keyboard shortcuts that you can use, almost like the G-mail keyboard shortcuts. You can do an “A” for “Reply All”, “R” for “Reply”, you can add a note with “N”, you can set Status using “S”, you can almost not use your mouse and use the app. So it’s a lot faster than other tools I’ve used. Another cool thing is it has this email interface, so when you get notified–if you pick something up on your phone that you got an issue sent to you, you can reply directly to that issue, that email right on your phone, or from Gmail, and the reply will go directly to the customer. Or, if you put–there are some fancy keywords you can add; so you can put @note, just the @ sign and then note, and you can attach a note to it, then reply again and put @assign and assign it to someone on your team. It allows you to do stuff without ever having to log into a web app, which I found is hugely productive for me if I’m on the go.
Then it’s fast and there’s a really nice plugin you can build. I think it took us an hour or two — we’ll reference this a little later – but in essence on the side of Help Scout issues, we can see the customer, and we see their gravitar, and we can see if they are paid, or trialing, or if they’re not a customer at all. We can see how many months they’ve paid, what plan they’re on, and their past support tickets. I’m sure there are other systems that can do similar things, but we’ve really enjoyed using Help Scout for the past six months. How about you, Mike, what tools have you used for support?
Mike: Well, kind of, like you, I started out just using Gmail, and right now I still run everything through FogBugz. It’s fast, it’s easy to have everything dumped all into one place, and I don’t really have to worry about it. I don’t get enough support tickets for most things anyway. I maybe get a handful a month, so it’s not really worth going down the road of building this full blown support system. It’s a manageable level, so I don’t really worry too much about it.
Rob: Yeah, very cool. Let’s talk now about these three stages that I’ve defined here. In essence, think about email support when you first launch as Stage 1, and then within three to six months you want to get to Stage 2 – that we’ll define in a second – and then after that Stage 3. So, Stage 1 is the founder, or founders, are doing all of the support. This is really where you need to start, because at this point you don’t have enough information to be able to train anyone else to do support, and your contact with your customers early on is invaluable because you’re going to be getting so much new information and so many new questions all of the time that, A. you’re going to want to improve the product quickly, B. you’re an upstart so you want to be able to respond instantly. When we had just launched Drip, I was responding to everything within 20-30 minutes. Every ticket you’re just getting back to people. Literally we would get a ticket and build the feature, or add the check box they needed, and get back to them within two hours. That’s how you have to be in the early days, in my opinion, of running a SaaS app or software product, is super responsive because that’s one of your main advantages over one of these big companies, it’s your speed of doing it and your knowledge. Since you’re not a front line person at some big company, you can offer in depth advice and you really know how your product works at this point. So I think there is a lot of value in the founders doing email support for the first, let’s say, 3-6 months.
Mike: The other advantage of doing all of that support yourself early on is that you get a sense of where people are struggling with your product or service. So especially if you start seeing the same types of things over and over it allows you to not only build some training collateral that you can hand off to somebody for tier 1 support later on, but it gives you an idea of where the hurdles are that people are running into, so you can either tweak the product itself, or the service, or you can educate the person who is going to be taking over the support later on, or you can just educate your users a little bit better, and your on boarding material. So, there are a bunch of different advantages to doing that support yourself upfront. I see people trying to just take that and say, “Oh, I don’t want to do support” and they try to hand it off to someone else, and that’s really hard to do just because the fact is you need some of that information. It’s harder to get it from someone else than when you hear that stuff firsthand, because then you get this broad view that is unfiltered from these customers, versus when you hear it through a support rep, because the blinders are on a little bit so to speak. Not that they’re hiding information, but they don’t necessarily relay all of the correlations between the different conversations to you.
Rob: I totally agree. Having that directly line with your customers is big, especially early on. You start to build relationships with folks, and they learn to trust your app, and trust you, and think of the whole experience as being a good one. You need to do that early on in your apps life cycle because you’re trying to build this brand in the early days.
Mike: Just what you said there about the entire experience though, that also relates to how you’re going to do business with them in the future. I think that’s an important piece of this, is that when you’re able to get back to them very quickly and you take care of them, down the road if they start running into problems, they’re not just going to throw up their hands, walk away and go sign up for something else. They’re going to come back and talk to you, especially if you’re either not meeting their needs or if something goes wrong — they’re going to be more willing to cut you a little bit of slack if things start to go wrong. And they’re having problems with the support rep, or maybe there are things going on that are just wrecking their productivity–they’re going to be more willing to come back to you because you’ve done the right thing in the past than they are to just walk away and go find something else.
Rob: Right, and the other reason you want to do support in these early days is that you have no process yet. You don’t have frequently asked questions. You may have made up a few and put them on your website, but you haven’t received enough questions and had to think hard about the answers and created some canned responses, and to know the struggles people are having to be able to train a support person. So, in essence, if you did bring someone in this early on, you could say, “Alright, go play with the app, and then answer the questions the best you can. Anything you can’t answer refer to me”. In a sense they’d assign it to you, but you’d be getting a lot of stuff assigned to you, and at that point I believe wholeheartedly in the value of just being on the front lines for all of the other reasons we mentioned as well as this one.
Then at a cretain point you’re going to want get to Stage 2, because as a founder you can’t spend all of your time supporting the app, and handling front line support. You’re going to involved to some extent, but as the requests become a little more repetitive and you do start to develop a process in your canned responses, and you’re seeing the same questions over and over, you want to move into Stage 2, which as I said tends to be about 90 days in. It depends on how fast you’re scaling up. If you’re still at 20 customers 90 days in then maybe you don’t need to move away from it. But if you hit 75-100-150 customers, you do need to start thinking about getting out of the support role. Here is what Stage 2 involves; it’s basically hiring someone to handle your Tier 1 support. By Tier 1, that’s your front lines. That’s the person who handles every single email that comes in, and either answers them or assigns it to the appropriate person. At that point the founder will probably handle all other issues. At this point you have all of this knowledge so you can create your docs, your training screen casts for the basic recurring issues, and then anything that your front line person doesn’t know how to handle they can assign to you and typically what I was doing was then trying to train that Tier 1 support person by not responding directly to the customer but by giving the support person the knowledge so that they could respond, and either put it into a Google doc or just putting it in the reply so that that person is now trained on how to handle that issue moving forward.
There are a couple of different types of Tier 1 support people. In the old days when I had some small info products, I really didn’t have much of a budget, I did hire really low cost VA’s, let’s say 3 to 7 dollars an hour, often in the Philippines or India, and they were handling stuff. As I’ve been able to level up and build apps that generate more revenue, as well as require a higher level of support, I’ve been able to hire higher caliber, more knowledgeable — some people even with a little bit of technical skill, like help desk level skills, maybe not programmers, but people who know what FTP is, and can explain things to folks. If you get that second kind of person — you know we have Andy doing Drip support and Micropreneur Academy support and that kind of stuff — he is willing and able to learn new things and teach himself, so when we did launch Drip – I had been telling him about it, and I was intending to create a bunch of docs for him – he said, “Just give me a login. I’m going to log in, I’ll look through the KB that you have, I’m going to play around with it, and anything that I need help with I’ll let you know”. That’s obviously the highest caliber support person you’re going to find, but you can certainly start out at a lower level where you really are just handing people canned responses. Even if they’re just handling 50-60-70% of the support and others are still coming through to you, it’s still a worthwhile investment until you’re able to level up.
Mike: And that level of support person is going to take time to cultivate. I mean you said yourself that he had started more on HitTail, and then you transitioned him over to Drip, and by the time he got to that point he just said, “Hey, give me the stuff”. That level of effort on his part is also partly a factor of how you have treated him as a contractor for you. So, that translates over to that new product so that you don’t have to train someone from scratch. Obviously there is training that needs to be done because it’s a new product, but you don’t have to train him on how to behave toward the customers. You don’t have to reset – or set – his expectations about how he should be answering questions. All of that knowledge carries over. It’s not the product knowledge, it’s the “how do you do business?” knowledge, and that’s also very important.
Rob: I agree, and that’s something else to communicate. We have a very customer-centric approach to support where we try to go out of our way and do everything we can to help them, and our refund policy is very liberal as well. So folks want refunds – and unless it’s some crazy thing where they’re asking for the last six months to be refunded – every once in a while we do get those, but other than that, when in doubt lean toward doing what the customer is asking for. And instilling that in the support person; you can’t give them the rules for everything. At a certain point there are judgment calls that need to be made, and if you don’t want to be making those judgment calls every time then you need to start instilling some cultural things, or strategies, rather than just the tactics of how to respond to each individual ticket.
SoSstage 3 of handling email support comes a little later, and I think this timeline depends on your growth but it’s definitely going to be when you start hitting multiple hundreds of customers. This is when, as as founder, you don’t even want to be handling all of the tier 2 stuff anymore. You’re still going to have your tier 1 support person. They might be remote. They might work with you. The odds are they’re going to be remote, because that’s the way you’re going to find someone at a reasonable cost who is still high quality. That tier 1 person is going to be doing the repetitive work; answering frequently asked questions, triaging things.
Then tier 2 spiders out. Instead of it just being you, you, kind of, have five roles that I’ve defined. A founder may need to handle more than one of these, but the five support requests and questions that we see coming through are : developer oriented ones, where they just get too technical for someone who is not into code to be able to answer. So that’s the first kind. The second kind is consolation/advice. And this could be pre-sales, it might be while they’re trialing, or it might be when they’re a customer.This is when someone really needs help understand concepts rather than how to use the specifics of your app. I’ll dive into that in a little bit. The third type is billing questions, asking for refunds, exception, the stuff where someone doesn’t want to make a monetary call. Your tier 1 person may not feel comfortable doing that. Your fourth is product questions, often feature requests and that kind of stuff, and then there is this “Other” bucket that I’ve shoved a bunch of other stuff into like partnership and such.
Let’s take a look quickly at number 1, which is “developer”. If you are the developer, as the founder, you will probably need to be this tier 2 role as well. With Drip, when Derek and I launched it, we pretty quickly realized that there are a portion of the tickets that come through that are just too technical or complex for a tier 1 support person, or even a non-technical founder, frankly. In the early days this developer will obviously be a founder or a true developer, but we realized after we launched Drip, that Derek was not going to be able to actually get anything done if he had to handle all of the tickets that were coming through to the developer support role. Because it can wind up being a quarter or a third of a person’s time in a given week, depending on how many customers you have. So, we hired someone as a developer/support person, so they do handle the tier 2 support. If you’ve interacted with Ian at all, in our support que, that’s who handles that.
Mike: Now I have a question for you about this. When you have Ian doing that does he do any actual development too, or is just a developer who is doing developer level support?
Rob: No, he is spending most of his time building features for the product. He is a Rails developer, and then as support requests are escalated to him he flips over and handles them. But actually less of his time is spent responding to support requests, but he does have that in depth developer knowledge.
Mike: So I’m a little confused. It sounds like you hired someone to shift the responsibility for the tickets off of Derek, but then this other person is spending most of their time doing development. I’m a little confused about how that works. It sounds like you just shifted a problem from one person to another.
Rob: Right, when I said Derek was not going to get anything done that may be an exaggeration. He was spending a quarter to a third of his time responding to tickets, and so development — he’s the lead developer. He handles everything that goes live – all of the deployments – so constantly having him pulled off in the middle of the day, he was really struggling to get the big features built. So we did hire someone else who is not the lead developer. He was, kind of, a Junior when we hired him and now he’s worked up to a mid-level, because he’s worked with us over the past year plus. But then a quarter to a third of his time spent doing it is just a better use of time, because Derek is focused on the big, meaty things, and we can move faster – when all the poll requests Derek has to handle, and that’s his distraction.
Mike: Got it, so you’re really just shifting where those interrupting requests end up.
Rob: Exactly, and overall it makes us more efficient. We get more done. And as we add other developers – assuming your developers handling support requests can continue to handle those – then other people are freed up and they don’t need to handle support requests. It’s not like it Round Robin’s. I feel like that could spell trouble if you’re interrupting a lot of developers all at once. I also think that some developers are good at switching. and others it’s a lot more of a struggle for them. And we happen to have found someone who is pretty good at it. So I think if you do find an avid developer and he’s struggling to do the switches -I’m not good at it actually. When I used to write code I had a real tough time switching into support mode, so I quickly knew that it wasn’t something that I was going to be able to do, so keep that in mind. It’s not something everyone can do.
All right. So our next type of tier 2 question, is this “consolation or advice?”. This almost comes down to customer success. It’s helping them be successful with your product – not necessarily about the nuts and bolts of it – but as an example, with HitTail, we used to get questions about, “How should I do SEO? Does SEO work? Here is my site, do you have any advice for me?” With Drip we often get, “How should I structure my tags?” or email marketing questions, “Are my open rates reasonable? Am I doing something wrong?” It’s like architecture and marketing, structure and advice. Sometimes we will jump on a call if it’s short and it’s an easy question to answer. Other times we’ll answer via email. We do have consultants that we refer people out to if we feel like it’s really exotic, or something where they need a lot of time to help. But being able to offer this kind of expertise quickly and give a few sentences of guidance, we found to be absolutely invaluable. And again, it sets you apart from these larger companies. You email an AWeber or a Constant Contact and they have tier 1 support, but they’re not necessarily knowledgeable on how to structure things, so you don’t expect them to help you out on this front. And as a small company this can be one of your competitive advantages, being able to give very quick consolations or advice for free via a support que.
Mike: So early on I assume that you were probably doing most of these in order to help offload the interrupting nature of those types of requests to Derek. What are you doing at this point? Is there someone that you have dedicated to that type of thing right now?
Rob: Absolutely. I was doing that for the first 18 months at least, maybe two years, and it was super helpful. And it helped me develop my knowledge of all of the markets and how they work differently, and it expanded my knowledge of email marketing and marketing automation and all of that kind of stuff with these different spaces that people are using Drip for. Then about six months ago we hired Anna, who is head of customer success, and she handles these now. It’s going really well. If people are trialing your product they are basically wondering if it’s going to work for them, and if they need help and you aren’t able to give it to them the odds are pretty high that they’re not going to convert. And if you do help them–it’s like you said, it’s that early experience, they learn to trust you as an expert and if your advice works out for them then they become customers. I don’t know that I’ll say life long customers but they become loyal customers because they know that you can help them out in the future if you run into this type of stuff. I think this is probably overlooked in a lot of support qeues, or support structures, but being able to offer this is really quite valuable.
Mike: So, the third one you have here is billing. How do you currently handle billing requests that end up geting escalated to tier 2? I think there are two different things to address here. One is how you handle it versus how it can generically be handled. Maybe we tackle those two things differently.
Rob: Sure, billing is in essence — tier 2 stuff is pretty much passed up to me, because often your tier 1 person won’t feel comfortable making monetary decisions. I will often give tier 1 support the flexibility to make the decision up to a certain dollar amount. You could say, “If it’s 50 or 100 bucks no problem. Don’t even both me with it.” And they may not make all of the decisions exactly like you would, but it’s just not worth your time to handle twenty requests if they’re going to make the same decision with eighteen or nineteen of them. It’s just not worth it. So when billing stuff comes to me then I have to make a decision, and often times I’ll involve other people on the team and get their opinion on how we should handle it, because sometimes there are tricky ones of someone asking for a refund of a bunch of months. There are just anomalies that come up where you have to make a decision and there is no clear path.
Mike: Yeah, some of those there is no right answer and it depends more on what will make the other person happy without disrupting things too much internally, both in terms of your cash flow — because the last thing you want to do is go back and refund like an entire year, especially if the person has been using it for at least part of that time. But yeah, there are always situations where someone needs a refund for a very specific reason, and those tend to be more cut and dry, versus the time where someone asked for a six month or twelve month refund because things have been ongoing. And hopefully you knew about those to begin with, but there are those occasion times that come up where something was going seriously wrong and you had no idea and now suddenly it’s a big issue and fiasco that you have to suddenly be dropped in the middle of without any knowledge of what was going on before.
Rob: The fourth category of tier 2 requests are really around the product. And these are mostly feature requests, maybe bug fixes. But really if it’s a bug the developers are typically just going to jump on it. I think if it’s a super low priority bug, only impacting a small amount of people and it’s not any type of showstopper — like let’s say a misspelling, something not catastrophic – then it’s going to go in the qeue and they’re going to handle it. But it’s feature requests that, kind of, need to be escalated because those always need prioritization. When feature requests come through you want to figure out a bucket that you can put them in. And you can either assign them to a made up person, if that’s how you want to do it. For us, in Help Scout, they get assigned to me and put into “pending”, so there’s a list of all of these pending tickets that don’t show up as active that I need to respond to them, but every so often I go through and make decisions of which ones to put into the issue tracker – which we use a Code Tree over Get Hub issues – or I get the team’s involvement, and I’ll often run through a bunch and make decisions and then ask the rest of the team based on what they’ve been hearing, because they’re dealing with a lot of customers as well and they might have the sense of urgency of certain ones.
In an ideal world, when you get passed a feature request you’d have some context for it. Because not all feature requests are created equal. If a customer is paying you $50 a month versus $1,500 a month, you may need to rate that feature request from the $1,500 a month customer higher. Or if it’s someone that you know really knows the space, and their advice is actually going to help your product grow – we’ve had a ton of those. You get someone like Brennan Dunn or Ruben Gomez using your product and they make a suggestion, that has a lot of weight to it because they know product, and they know email marketing in terms of Drip and when they make suggestions these are ones I really listen to because my guess is these are things that are actually going to be applicable to other people. That’s probably a whole other episode to record, about how to prioritize feature requests. But I think the point here is when they come through support you want to have a pretty systematized way to deal with them, because you are going to get a lot of them. We get several per day. You can constantly being manually copying those into some Google Doc or into some other system. They do need to sit somewhere, and you need to figure out a way to batch them.
Then our last category of tier 2 support is just miscellaneous, or other. You’re going to get these requests especially as you grow, for partnerships, integrations, someone is putting together a packet for entrepreneurs or marketers and they want a discount code, they might need a sandbox or test account, they want to interview someone, they want a quote for a [blog pop?]. I mean, there is just stuff that just comes through. And what you’ll find is that as you grow you start getting more of certain kinds and you’ll want to start either automating them or teaching tier 1 how to make the decision. The example of needing a sandbox or test account, you’re probably not going to build that from day one because it’s quite a bit of time, and so over time it’s been escalated to tier 2 every time, and then I take a look at what they’re doing a make a decision. But recently we’ve realized that we’re getting enough of these requests now that we are going to put something in place with a special URL we can provide for people that have a 90 day sandbox account. This makes it a lot easier for us to handle and it’s not a manual process every time. I think partnerships, any of these, really, could be done that way. You could send them a link to a specific form that goes into a Google spreadsheet and you could handle that in batches, instead of handling each one individually. It’s probably going to be worth it at some point for these kinds of partnership requests or interview requests or that type of stuff.
Mike: It seems like these other requests are the ones that tend to take the longest because you don’t have a canned answer for them, and you have to evaluate every single one of them not only individually but also in the context of the other requests that you’ve received in the past that were even remotely similar, and try to maintain some sort of consistent approach to them. But then in addition to that you also have to take into account the growth of your app or product and making sure that you are doing things in a way that is consistent with what your future plans are for it. So all of those things said, it makes it difficult in some cases just to even estimate how long it’s going to take to address some of these, because some of them take a lot of back and forth as well.
Rob: Okay, so moving on from email support, there are, kind of, three other categories that we’ll cover pretty quickly here because it looks like we’re running out of time. I broke them down into like having a KB or some type of self service support, perhaps using live chat and then finally phone and Skype. Let’s look at KB’s really quickly. We were talking offline before we started recording and I was mentioning how surprised I am at how many people use our KB, and how many people really do want self serve, and they don’t just want to send an email in. They either want the answer immediately, or I don’t know what it is. You had some other theories.
Mike: Mine was that because your audience is somewhat technical they view their time as being valuable, and if they’re working on a problem they don’t necessarily want to do the context switching of moving away, sending off an email to support, moving away and then coming back two or three hours later or however long it takes to get an answer that tells them exactly how to do it. Then they have to slot their time in to come back to whatever it is that they were working on. Essentially they’re in a time period where they say, “Hey, I’ve got got an hour or two to work on this” and they just want to get it done and over with, as oppose to working on it a little bit and then having to sit it down and walk away and then come back to it and do something else in the meantime. Honestly, it’s distracting to have to do that, so when you’re in that situation it’s a lot easier and it feels better to say, “Okay, I’m going to dig through the docs a little bit to see if I can find the answer to this”, instead of just going straight to support.
Rob: Totally, and KB can be used in tandem with your email support obviously. We tend to try to answer questions directly and not just refer people off to KB articles because I hate that. If you email a big company and they just send you a KB link, often times I’ll find it’s a massive article and I can’t find my answer in there, or it’s the wrong answer. So if someone would have just answered me like a human then it would have worked out better. So we air heavily on the side of actually responding to someone, but it’s only when they ask something like, “How do I set up this integration?” and we have step by step that answers exactly what they want. Then we’ll be like, “Hey, we created a KB and here is all of the screenshots and everything. Look them over.” So KB’s are cool for both your own support team to be familiar with as well as external customers. In terms of setting up a KB there are a bunch of options. I have a few that I recommend to people. Help Juice, that’s a shout out to [Amyl Hassrick?]. He has helpjuice.com and I know some folks who use it and are happy with it. Desk and Zendesk which, I think if you’re using them for support they have KB’s built in. I’m not a huge fan of having a KB built into your support software because it’s just one more reason you can’t switch away if you decide you don’t like it. Then, you can use what we do on Drip which is just a WordPress plus a support theme. There is one called [Know How?], there are a bunch of others. If you search for it you can do that. Then you have to work with WordPress and deal with it’s anomalies, and themes breaking, and that kind of stuff so it’s not nearly as easy to maintain as a SaaS approach like Help Juice. But then you aren’t paying the monthly fee and you can customize it as much as you want since you’re in control.
Let’s talk about live chat really quickly. If you’re going to use live chat for support, then you’re going to want to put it “in app” only. If you put it on your marketing site, you’re going to get a lot of sales questions, and that’s a whole other discussion of whether or not you want to do that. But if you’re going to use it for support you put it in your app, and I would even consider only activating it for trial users if you can. That’s something we’re entertaining the idea of these days. We’ve done some “in app” live chat stuff with Drip and have had mixed results in terms of how well it works. Often times you just need time to research something, or you get a question that you need to talk to a developer, or you just can’t answer everything so it’s not actually the most efficient even though it seems like it should be. But there are a number of solutions for this; Olark, Zopim. I’ve heard that Intercoms live chat that what they’ve added is not actually live chat. It, kind of, pings you, but it doesn’t show if people are online, it doesn’t work the way you think live chat should work. I haven’t used it personally, but I’ve heard negative reviews about it but Olark and Zopim are the players that I’ve heard a lot about for this type of support.
Mike: Yeah, I’ve never used chat support before. Inside Communifier where we host the Micropreneur Academy there is a chat system there, and I’ve used that to some extent, but it almost feels like there are much better solutions out there for chat and a lot of things just come in through email. Some people just prefer email over the chats. A chat is one where unless you’re there all the time it can be difficult to do that. So I can definitely see where Intercom might fall down if it doesn’t work the way people think a traditional chat system would work.
Rob: And lastly, talking about phone or Skype or something like that. I think if you’re a single founder and you’re just launching a product on the side then this is not something you want to do. I tried it early on with DotNet Invoice and it was incredibly time consuming. It also depends on the type of customers you’re dealing with. Certain customers you can jump on the phone and it’s a piece of cake, and then others are just really tough to explain things to. You’re trying to explain what a screen looks like, or how to click here, and you can’t give screen shots. And if they’re really non-technical you can’t get them to join a screen share to show them, so stuff can become pretty cumbersome and really kill a lot of your time. It’s also interruptive if you’re taking in-bound calls.
The successful companies I’m seeing do this on a smaller scale – you know, when you have a team of five or something – is to have you initiate the call. You can either give them your number or you can call them directly, or you can set up a [?] and try to do something later in that day, or the next day. It depends on how urgent this issue is, for sure. Sometimes it really is the best route if you have a customer – there are certain customers that you know., and you trust, and you know if they have an issue that it’s not some crazy thing where they’re going to waste a bunch of your time, that they really need help now and sometimes that’s just the best way to do it. And then other times you’ll get a customer who you’re not sure about, and you’re a little concerned that maybe they’re going to try to get you on the phone for 30-45 minutes. Those are the ones you have to make a judgment call about when you do it. If you want to do screen sharing, join.me is a decent example. Certainly if you have something like GoToMeeting and you’re paying for that already. It’s a no-brainer. We found that Skype has mixed results. Some people just don’t use Skype so they don’t have a user name. You have to add them and then they have to accept. There is just more to it than that, but there are definitely options for doing this and sometimes it just is the best option for handling more complex issues.
Mike: Yeah, in terms of tools there are a bunch of different systems out there for screen sharing. Join Me is one. Another one — again, these are tools, and the specifics of the one that you choose are going to be heavily dependent upon how you need to interact with them. So whether it’s you need to show your own screen or you need to share a screen and maybe control their screen, all of those things factor into which tool you use but as you said, Join Me is one of them, Copilot from Fog Creek is another one. Then there is also WebEx and GoToMeeting, and both WebEx and GoToMeeting. Both WebEx and GoToMeeting, on the surface they look like you have to pay for them, but they both have free accounts that you can sign up for. It’s somewhat limited, I think on WebEx you can get a free account and you’re limited to three participants, but after the trial period is over I don’t think that you can request control of the other person’s screen. I think up until that trial period is over you can hand off control, but once the trial period is over you won’t be able to do that.
One of the things that we came up with just before the podcast episode was the idea of treating some of the people you’re onboarding differently based on whether or not they’re currently in a trial, versus when they have been a customer for a long time. Because obviously those people who are just signing on to your service are going to have a much higher likelihood of churning if they are not familiar with who you are, or what you’re doing, and they’re not ingrained in the product. So we discussed this a little bit, we don’t really have any experience there, but if anyone out there is listening to this and you have tried doing this before we’d love to hear from you. Just send an email to us at questions@startupsfortherestofus.com we’d love to hear you’re story and we’ll share it on the air with people.
I think that about wraps us up. If you have a question for us you can call it in to our voicemail number at 1-888-801-9690 or you an email it to us at questions@startupsfortherestofus.com. Our theme music is an exerpt from “We’re out of Control” MOoT used under Creative Commons. Subscribe to us on iTunes by searching Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.
