Show Notes
In this episode of Startups For The Rest Of Us, Rob and Mike talk about switching from enterprise to the SMB market, staying small indefinitely, dealing with raises, and take more listener questions.
Items mentioned in this episode:
Transcript
Rob [00:00]: In this episode of ‘Startups for The Rest of Us,’ Mike and I discussed switching from enterprise to the SMB market, staying small, and definitely dealing with employee raises and more listener questions. This is Startups for The Rest of Us episode 330.
Rob [00:23]: Welcome to ‘Startups for The Rest of Us,’ the podcast that helps developers, designers, and entrepreneurs be awesome at building, launching, and growing software products, whether you built your first product or you’re just thinking about it.
I’m Rob.
Mike [00:33]: And I’m Mike.
Rob [00:33]: And we’re here to share our experiences to help you avoid the same mistakes we’ve made. What’s the word this week, sir?
Mike [00:37]: Well, I don’t feel like I’ve made a ton of progress this past week basically because I’ve been dealing with taxes, but I did manage to convert a couple of more of my preorders in the paid subscriptions and added another customer on top of that to Blueticks. So, things are progressing I think like any other product launch ever. Like, they’re never quite as fast as you’d like but they are moving forward. So, it’s good to see.
Rob [00:58]: Yeah. Well, I mean, it’s not really a product launch, right? It’s just more of a product – it’s a customer development in the early. I’d say it’s like a prelaunch, right, early access maybe.
Mike [01:07]: Yeah. Yeah, that’s probably a more accurate description because I haven’t really gone through like a major – like a launch to a list or anything like that. I’m still kind of working through issues as I onboard people and trying to iron out the rough edges and stuff because there are certainly some of those that I’m trying to make sure that people aren’t running into or when they do that it’s lessened to some degree either through KB articles or through onboarding emails and stuff like that.
Rob [01:31]: Yeah, nice to develop that stuff at this point. So, if we bring the ‘Startups for The Rest of Us’ drinking game back, remember a couple of years ago? Should we do that every time you say that you added two more customers?
Mike [01:43]: I don’t know, it depends on what the rules are I guess.
Rob [01:46]: Right, right. [?] on my end also got my taxes out, so I am notorious for filing, what is it, extensions and wind up getting everything into my accountant in like late April or may and then he gets it out in June or July and it’s become a pain in the butt. So this year, I got everything done super early and I’m hoping to have everything filed on time. But I’m curious, you mentioned you didn’t get a ton of progress this week because of taxes. My taxes since everything is in zero and we share a bookkeeper actually, right.
I have two business plus you’re my shared business with MicroConf, but since tax is zero and the bookkeeper had done. I mean, my Drip and [Newmor?] group taxes literally took me less than 30 minutes a piece because I basically give my – my accountant already has access to it and I just kind of give him some heads up about different things. And then my personal stuff took a little more because it’s all piece of paper all over the place and you get all these W2s, but it probably took me less than two hours. So literally, maybe three hours to get everything done. Did it take you more than that and why?
Mike [02:45]: So on the academy stuff, there was some things that were classified wrong because of the – basically because of PayPal and selling things in Europe. So whenever something goes through our accounting software, it ends up creating three or four different transactions for the same ones because it does transferred from Euros to US Dollars and then back and forth. And then there’s an additional charge and if those aren’t classified correctly and mashed up correctly, then there are certain numbers that are off. And there were numbers that were off and I had to go through and find them, so.
Rob [03:19]: Boo, that’s no good.
Mike [03:20]: Yeah. I kind of got a system at this point for figuring it out but then on my own business taxes, there are some things that were misclassified the previous year because we were going to try in different revenue and we couldn’t do that because of when we sold tickets to MicroConf because we did it in the previous years. And then years passed, we didn’t do that in, I think, 2015. My accounting software is in zero as well, and there’s things in there that were not fixed the previous year. So like the numbers were way off and I honestly still don’t know how to fix them. I sent it over to my CPA eventually and just said, “Look, this is what these are. I know why it’s that way and I just don’t know how to fix it.”
Rob [03:59]: Got it. But how much did all that take you? Was it like a day?
Mike [03:59]: It was probably two, something like that.
Rob [04:05]: Really? That’s insane.
Mike [04:06]: Well, it’s just like finding the transactions that are wrong. And it’s like sometimes are not as easy to find as they should be. I honestly wasted too much time on certain piece. I mean, it’s not like it was two full days but it was like kind of hanging over me for that two days or so.
Rob [04:23]: That’s the thing I found, man, is as much as I’ve been able to hire people to help out with stuff like this, because I have a CPA and I have legal counsel and I have a bookkeeper and yet taxes still take several hours to get done. And when Drip was still independent, I had like a remote executive assistant/ops person. She was doing a bunch of ops work but I still found that there was hours a week that I was sitting there and not marketing, not looking at features or working with customers, but I was just doing stuff HR payroll, even though again, I had an ops person who was doing that, I was still involved in it. And that’s – I don’t know, man.
I think it’s a hard thing I found getting passed no matter how much I hire, no matter how much I find good people to do the things. The stuff slips through and you wind up doing stuff that isn’t necessarily fun. And that’s, I mean to be honest, post acquisition, I really enjoyed – I don’t have to do any HR now, and I don’t have to do – the only reason I’m doing taxes for Drip is because it existed last year until July, right? So we had to file for that but I’m actually kind of looking forward to things simplifying because the overhead me admin work around running a business is just, I don’t know, man, it’s probably my least favorite part of the whole deal.
Mike [05:34]: Yeah. I mean, the other thing that has kind of factored into it which isn’t directly related to it is that like my wife is looking to potentially acquire a fitness studio that is in our town. And so I’ve had to do like got through a lot of paperwork and tax things and stuff to look at, is it a good deal, is it something that she wants to go through with, is there actually a business there. So that kind of factor some of that time in there, which I don’t know how much time that actually was because it wasn’t like I was tracking the time. But I kind of lump it into that process.
Rob [06:04]: Very good. Anything else going on with you?
Mike [06:06]: No, not really. I mean I’ve got a few more demo schedule and going to be going through those over the next week or so but I’m starting to shift my focus over to like really detailing what my customer acquisition funnel looks like and why or not some of the automation behind it. So, taking somebody from, “Hey, they’re on my email list,” and then moving them over into like a survey and then getting the answers from that and then kind of picking and choosing who I’m onboarding and in what order. And then kind of wiring everything up to help automate that process a little bit.
Rob [06:33]: Nice. It’s good to start thinking of that stuff at this point. All right. So we have a lot of listener questions today, some really good ones. And then we’re getting a little bit behind. Some of these are from, well, this one’s from October of last year. So good old four-five months ago, and there may even be some that are older than this. So, apologies on that but I wanted to work through some of them so people aren’t waiting so long.
This one is from Daniel Cao and he says, “I’m an avid listener. Thanks for being so generous with your knowledge. We have an enterprise level SaaS product that we successful sell for $5,000 a month. However, each sale takes six to nine months and it’s a slow process. We can adapt the product to be suitable for SMB sized business, so that’s small to medium businesses, but they seem to only be able to bear $200 to $300 per month as a price point. We really want to pursue the SMB market but we see it’s 20 times as much work for the same end result financially. Are we insane? Should we just take the enterprise? Or is there something magical that happens when you go for the higher volume of small value customers. Many things.”
Mike [07:36]: I think the question whether you go in that, the direction of the SMB market and try to position your product there really depends a lot on what your longer term goals are for the business and whether that’s – a market that’s even really viable. I mean, if it’s taking you 20 times as much work for the exact same revenue, that alone should say no don’t do it. And I don’t know if there’s any way to kind of slice that or position it in a way that it doesn’t make it like that. I mean, you can always – like over time, you can generally drive the cost of a business down. And it sounds to me like this is one of those situations where the upfront cost of making it or fitting the products into the SMB market is going to be quite substantial.
But if you’re making $5,000 a month from each customer that you bring on, then yeah, it sounds like that’s a reasonably good way to position it and you could potentially like support yourselves while you transition the products. Is it worth doing that? I don’t know. I mean, I would take a look at that and say, “Well, how much lower can you really drive the prices? Are you going to be able to maintain the same level of support with those SMB customers? And dependent on the complexity of the product, you may or may not be able to. It sounds to me like my inclination just kind of a glance based on the 20x number. Is it you probably don’t want to go in that direction just because I think it will be very difficult to drop the acquisition cost by that much to support the work level that it takes to get those customers onboard.
There’s also the fact that some types of products just they seem like they would be a good fit for the SMB market but they just aren’t. Those customers as you said, they don’t want to pay as much as an enterprise customer. And the reality is that they don’t really need it that much. They may think that they do or they want to be in a position where, “Hey, we’re sort of a big company,” and they feel like they’re important but the reality is that, they’re not in the same situation as those enterprise customers and they just will not buy it or not buy it at the levels that you want them to. And at that point, it becomes a losing proposition.
Rob [09:30]: Yeah. In almost all cases, you want to get your prices up higher even if the sales process takes a long time. And the answer to the six to nine-month sales cycle is to just have more and more of those enterprises in the pipeline so that you’re constantly closing them, right. So if you only have five in your pipeline and you all started them today, then yeah, it’s going to be six to nine months until you close those five. But if you five that come in your pipeline today and five tomorrow and five the next day and five, then starting six to nine months from now, you’re just going to be closing a few them basically every day or every week or whatever.
And that’s where you want to get. Based on the information you’ve said, I don’t think there’s any way I would try to do a lower price offering at this point. The only reason I would consider doing lower price is if you’re in innovator’s dilemma situation where someone else is building a simpler, lower-cost version and they’re taking your customers from you. And someday you may have to do that if you become a big cumbersome entity like the Marketos and the HubSpots. Not that I’m such that cumbersome but Infusionsoft, Eloqua. I mean, basically, we’ve innovated Drip innovator dilemma them from underneath, simpler, lower cost, easier to use. But you’re not saying that here. You’re saying, “Should you go there so that you cut down on these lead times?”
I’ve never heard of an approach where you try to go cheap and go for volume because trying to get that volume is it’s a pain. It’s so much work. It’s harder to support. You’re going to need a lot more features because you’re going to have this broader swath of people having 10,000 customers versus having 500 or 200 customers. It’s the whole different ball game. So, if you look at how Jason Lim can talk and he’s kind of B2B SaaS, one of the experts in the world, his whole thing is start cheap or start as expensive as you can but you’re not a brand name so you got to start cheap and then work your way up. And you’re talking about going the opposite direction.
And I would almost not even consider this out of hand. Obviously, you never want to say never and there are exceptions to this. But I would guess it’s probably 1 in 500 businesses that should actually do what you’re suggesting. And so I’d say odds are pretty heavily against trying to go for SMBs. I think the last part of your question was, is there something magical that happens when you go after this market and the answer is not. It’s still a ton of work and it’s just a lot more customers to try to sell and support. So thanks for your question, Daniel, hope that helps.
Next question is from Rob at onlinetravelmap.com. And he says, “Hi, Rob and Mike. Thanks for making such a great resource. I’m working my way through the Blank and Dorf book, ‘The Startup Owner’s Manual.’ And I’m on the customer discovery part of customer development. They say to create three things that I’m having a hard time seeing other entrepreneurs create. First is an influence map, second is a customer archetype, and the third is a day in the life of. Did you create these for your businesses? And if so, how? I ask because it seems like more info than people would want to contribute.”
So for those who haven’t read ‘The Startup Owner’s Manual,’ Steve Blank is a guy who come up with the concept of customer development and later a student of his era agrees borrowed customer development as well as some of his other concepts and developed the Lean Startup. So Steve Blank has founded and/or been a venture capitalist. He’s founded a number of companies. He took several of them public. He had a bunch of axis. I mean, this guy knows what he’s doing. He’s been an entrepreneur in the trenches.
So in this book, ‘The Startup Owner’s Manual,’ they talked about different things. It’s like don’t create a business plan but create these influence map and the customer archetype and a day in the life and that kind of stuff. So, I guess and now that we know what that is, did you create these for your businesses and if so, how? You want to kick this off, Mike?
Mike [12:59]: Sure. I probably didn’t sit down and go through like those specific concepts like the way that he would’ve recommended and say, if he’s got templates and stuff like that, I’d certainly didn’t use them. I mean, I did write down people who I thought would be good influences or people that I could leverage to get to more customers. And I also wrote down some conceptual stuff about like who is the type of person who would use this, are they paying for it, or are they just using it and their boss is paying for it and stuff like that. I did not really go through a day in a life of but I thought about how the product itself would be use.
So, I did to some extent I would say did do these things but I probably didn’t document it to the nines when I was going through and writing it all out. The other thing is I didn’t plan these things in advance because – or at least not so far in advance that it turned out to be useless because it would’ve been based on pure assumptions. So, essentially what I did was before I really started to go down the path of building it, I thought about who it was that could help me and wrote down a list of names. And then I also thought about the people that I was having conversations with when I was going through validations and saying, “Okay. Is it possible or is it going to be difficult for me to get in front of more of those types of people?” So I used that to kind of identify what marketing channels to use.
But again, like of the life of, I didn’t really think too much about that just because I was focused more on how is somebody going to use this as opposed to if it’s consultant use or a freelancer, what does their day look like? I know that they get pulled in all sort of different directions and quite frankly, the best position for them to be in is to not really be in my product that’s doing other things. It’s supposed to work in the background for them.
Rob [14:37]: Yeah, and for me, no I’ve absolutely never created these things but I create my own versions of them. I just think what is the value proposition, what is it going to take to get this many people to the site, this many people to the funnel to grow this fast, what are the possible channels for that. I didn’t draw an influence map but I definitely had a list of folks who I thought could be – could help me out in some way, affiliates, that kind of stuff. But I mean, this is a bulleted list and a Google Doc, right. I just told that I had the HitTail marketing game plan and then I had the Drip one. It was all the marketing ideas that came up as I went through it.
Customer archetypes, you know, again, I didn’t do ‘The Startup Owner’s Manual’ but I wrote out, who do I think like the top three possible customers for these apps are, where are they, and you just kind of build this out, just research it and then forgot how you can advertise on those place. Or is it more organic, are they going to Quora? Then maybe I should answer questions on Quora, that kind of stuff. A day in a life, never done it. I know a little bit about it. I don’t know how that would be helpful for me. But the thing is, the problem is I do think the stuff is helpful for beginners but it’s like it just gets too deep.
You get this 600-page book like the ‘The Startup Owner’s Manual’ and they have this whole section on TAM and SAM, right, it’s like total addressable market and served the addressable market and target marketing, blah, blah, blah. And it’s like you have to go to think about those things but I think people just spend way too much time looking at this stuff. I mean, especially if you’re bootstrapping, the TAM doesn’t matter. The total addressable market does not matter for trying to build a $10,000 a month business.
It matters if you’re trying to raise funding because they need to know it’s a $100 million marketing and you need to prove that. So, so much of this is not relevant towards bootstrappers. I mean, you can grow a seven-figure business and never want to do any of these things. But with that said, I think the issue is that they have you thinking through based on all of these key resource hypothesis and the customer relationships hypothesis. I think thinking through them once is probably good but when you think about bootstrapping a business, it’s like, am I building something people want? How do I get there quickly and then how do I let people know about it?
Those are the three questions I ask and that’s what – the day we launched Drip, I had a 12-page Google Doc which is a bunch of bullets and notes and thoughts and just every podcast that I heard that gave me ideas that I thought could work I put on there. And by the end, I have this big list of tactics that I was then able to develop into a strategy and to leverage that and figure out what works and what doesn’t. And then from there you go to a spreadsheet. There’s a whole other system down there but these are theoretical and they’re business model planning. And Steve Blank is an academic. He did launch several startups but he’s a professor now.
And so he thinks in terms of these broad frameworks and often these broad frameworks are pretty high level and are pretty MBA type stuff. And in my experience, MBA type stuff does not tend to help you when you’re actually having wherever meet the road. It tends to help you really well if you’re raising funding, if you want to do a pitch, if you want to talk about, but nuts and bolts of actually getting customers is just a whole different story. I’d be really careful with spending a ton of time on these things you’re talking about, but I do think it’s helpful to do these extremely thin and quick versions of each of them and try to think through what are the questions that they’re trying to have me think through because I do think there’s benefit there.
Mike [17:36]: I think the important thing to bring up here at this point is that the reason why it’s helpful when you’re looking at going out for funding is that it forces you to think about things that you probably haven’t put a whole lot of time and effort into or that consideration, so that if you get into a situation where VC or an angel investor ask you a detailed question about something like this, then you’ll have an answer off the top of your head because you have looked at that specific question before and you won’t have to um and uh over it and come up with something on the spot. You’ve already thought about it in advance. That’s where it’s helpful.
It’s not helpful in terms of implementing your business and actually doing anything, because I think that what you’ll find is that, you can put together this plan and do all this stuff in advance, but things are going to change as soon as you start talking to customers and that’s really where – that’s where all the other things that Rob just talked about and moving quickly and having those lose spreadsheets and Google Docs that you work from, that’s the most important at that point. When you’re talking to VCs, they just want you to know that you have done your homework and really thought in depth about these things. And if you can answer some obscure question, then they’re more likely to fund you because of that because you can answer that obscure question.
Rob [18:46]: Right, and I mean, it comes back this quote that I say a lot which is about how I prefer to build businesses instead of slide decks, right, and this comes back to all the stuff we’ll probably look really good in the slide deck when you’re raising funding but it just doesn’t question how much. It’s really worth in the long term in terms of actually when we’re meeting the road. So I hope that helps, Rob.
For our next question, it comes from Liam Elliott and he says, “Hey, guys. First of all, I love this show. I want to pick a startup to run with but I’ll be in university for at least two and a half years starting in September. Is it possible for me to plan for growth as a one-man show? I want to avoid having to make the difficult decision of business or school somewhere down the road. Do you have any advice or war stories about the consequences of resisting natural growth in order to maintain availability for another area of life such as work or school during a predetermined period?”
Mike [19:38]: I feel like there’s a kind of a false assumption here that everything is going to be successful, and that growth is going to become very quickly and very easily and you’re going to have to make a decision down the road of, “Oh, do I stay in school or do I go with this business and do that instead?” I think if you look at widely publicized examples of people doing exactly that, you end up looking at people like Bill Gates or Steve Jobs. And those come to mind when you look at that stuff, but I don’t think that there’s too many other examples that do.
So, it kind of skews your view of what really happens when you’re trying to build something. I think that if you’re going to a university and you’ve still got two and half years ahead of you, then I would use that time to essentially build a business and practice with a lot of things where there’s marketing or a product development or doing anything related to customer development in order to put yourself in a position where when you get out into the real world and you have to actually start paying bills as opposed to taking classes all the time and not having to worry about that stuff. Then you’re in a better position to be able to grow the business.
From my own personal experience, I only know of one person who was going to college and ended up building a successful business while he was in college, and the end result of it was that he was one class short of getting his degree in photography and decided [?] I don’t care because he realized that his business was making more than enough money that he didn’t have to worry about it. But he had also started this business back in high school and he’d been running it since he was, I think, 17 or 18. And by the time he was 21-22, I mean, the business was making close to 7 figures and this was back in the shareware days and there was not a ton of competition. So ti was a very different environment at that point. And he still runs the business today but he also runs a couple of others as well.
So I can’t think of too many examples that really fit that mold of where somebody’s going to college and they build a very successful business and then they have to choose, do I want to grow this thing even more at the expense of quitting school.
Rob [21:34]: Yeah. I think that’s a good point. I think the odds of it happening are pretty slim. I think I’d be less worried about it growing and having you to decide and more worried about it just being a time suck, right, because even if it’s not growing, it can still be a huge time suck that you’re investing a bunch of time in. I think one thing to think about is like this is perfect for kind of the start small stay small approach which is the book I wrote in six-seven years ago. And it’s where you look for really small niches, right. You look for have [?] website just hold a few thousand a month. I had an in-voice that sold several thousand a month but very small, very self-contained markets, almost no competition. I had a few others ahead.
There were some e-books in different markets and they were just so small. I mean, they were literally between 500 and 5,00 a month each. And there was very little work to be done on a month-to-month basis and they were never going to grow to be $10,000, $20,000, $30,000-businesses. But that’s the like the perfect, I can imagine a better business to have while I’m going to school. Not much work, no danger of growing, not a competition so I don’t really have to fight it off. So that’s probably where I would think of going down more of this micro approaches like having whatever your talent is. I don’t know if it’s WordPress, plug-ins, or Photoshop add-ons or a Shopify app.
I mean, there’s these little tiny markets you can get into where it isn’t a ton of work and it generates a bit of money but you’re not endanger of this thing growing even if it grows to as big as it can be. It’s still only a few grand a month. So it’s an interesting thought experiment and I appreciate the question, Liam. I hope that’s helpful.
The next question is from a guy Louis and he says, “Hey, guys. You’ve responded to a number of my questions in the past and I appreciate that. I have another one. How do each of you approach scaling support? I heard Jordan [Gaul?] mentioned a StatusPage.io runs 10,000 customers, 1,600 of which are paid. They bring in 2.4 million AOR yet they only have one full-time equivalent support role. My business is growing via channel partners who while currently taking up a lot of my time, are helping me streamline support so I’m ready in the future to take on more. Currently, I use videos, flowcharts, and manuals, plus an online ticketing system, but I wanted to know what else I could consider to help reduce common questions and problems. What are your thoughts?”
So one clarification here is the StatusPage.io thing with 10,000 customers and one support person is a little bit of a – I don’t know. Maybe –
Mike [23:51]: Edge case.
Rob [23:52]: It’s an edge case, that’s a good way to put it. Because think about how simple – I mean I used – we used to have StatusPage.io replaced for it. It’s a simple app. There’s not much fare, so there’s not much to support. An app I own years ago was HitTail. It was a simple app. We had one part-time support person even though we had – I’m trying to think of how many thousands of customers we had. It’s just there wasn’t that much to do when you just get set up and then things run on autopilot. It’s very different. It depends on what your app is but you look at an app like Drip or an app like direction Bluetick has headed, Bidsketch, these are much more complicated apps, a lot of moving parts, a lot of things to get configured, a lot of things to think about, dozens, 50, 100 different screens of background process. I mean, there’s just a ton of things to know.
It’s just apples to oranges, right. There’s a reason that in StatusPages that one reasons can support 1,600 paid whereas in an app like Drip, maybe that’s five people that need to do the same thing. So, that’s not your question, I realize, but I wouldn’t try to think that every app can have that ratio. But back to your actual question of he says he uses videos, flowcharts, and manuals, plus online ticketing system. I’m assuming that a Help Scout or Zendesk, he’s wondering what else he can do to reduce common questions and problems. Go.
Mike [25:00]: Yeah. There’s only so much that you can do and I think that there was an attendee talk last year by a Ben Orenstein who talked about how he tried all these different things and he was watching from people’s shoulders as they were going through his app and he’s like, “Oh, they didn’t realize that they needed to do this. So let me put some text around that.” And he went to the next person and watched them and they didn’t see the text. He’s like, “Oh, well, maybe I need to make the button bigger.”
And he made it bigger and it still didn’t matter. And he tried all these different things and the reality is that there’s so much variation between customers that it’s very difficult to do one thing or even sometimes a combination of things inside of your app that will completely eliminate all support questions or problems that come up with that one particular feature. And if you would extrapolate that across the entire app, there’s no way to eliminate them all especially in any sort of application that has a level of complexity to it, above like a static HTML web page. And even that, you’re probably going to get questions about.
So there’s a lot of things that you can do. It sounds to me like you’re doing a lot of the things that I would probably tend towards. I would take a look at your support tickets and see if you can classify them or categorize them in such a way that you were able to identify the places where you are getting a lot of questions about and see if there’s ways to either put some wizards in or streamline the user experience so that maybe it’s a multistep process or something along those lines.
I’ve also seen apps that are out there that you can kind of integrate into your application that allow you to have a help page on the specific page of your application that points you directly to the KB articles that are relevant directly to that one page. But even with that, you still have to educate people that that’s where they can go for help on that particular page. So, there’s always going to be places where people overlook stuff and there’s literally nothing you can do to stop that.
Rob [26:49]: Yup. I mean, it’s blocking and tackling, I think, right? I think you get something. You’re going to have something, some in-app help, having a chat widget can be nice although you’re going to need more people if you offer that kind of real-time support. And certainly videos, flowcharts, and by manuals, I’m assuming you mean online knowledge base not a big 300-pound paper thing that you ship to someone like in the old days. I mean, our KB has been super, super helpful and people search that all the time. They want to find the answer right away. They typically want. It depends on your audience but they typically want to find an answer without emailing support because they know it’s going to take a while to get a response. So the more you can build that out, the better you are. So I don’t know if any magics over bullets here. I just think the more info you can get out there in a searchable fashion, the better off you’re going to be.
One hack that we do use, maybe this is something that I can throw out, is I went in. RKB runs on WordPress, and I hacked it since I still know a little bit of PHP. And I wired it up so that any time a question or anything’s typed into the box and we don’t have a result for it, we pop it into, in essence we send an email into an inbox. And then we have someone go through those once a week. And there’s a bunch of junk and there’s a bunch of stuff that we’re never going to do if we found people phrasing things differently, obvious repeated searches that we should build. So we wind up building KB articles based on basically people not finding information and we found that over time that the amount of searches that aren’t being found are the ratios reduced. So, that’s one clever hack but that’s not individually going to scale your support up, but everything – it sounds like you’re on the right track at this point.
And I think for our last question of the day, we’re going to take it from Dave. And he’s asking about raises and when to give raises and how do deal with them. He says, “We have 12 employees and every 6 months we evaluate them, have one-on-one meetings and give them raises. My employees are great and I don’t have any qualms in that area. We’ve been lucky enough that our employees like us and stick with us but this creates a small problem which is that after an employee has been with us for one and a half to two years, they’ve received several considerable raises. For example, my lead developer who started with us less than two years ago with 18 bucks an hour is now up to $31 an hour. That’s the biggest jump. But there are others who are heading in that direction. For that amount, I could almost squeeze in another developer which we badly need.
Now the company has grown and the employees are now more experienced and more valuable, but still it feels difficult to just by paying the same guy that used to pay 18 bucks an hour, $31 an hour. It isn’t a large a company and it’s not the type of place where people jump to upper levels of management and start adding values in ways they weren’t before. Actually, most people are doing what they did two years ago, fix bugs, add features, etc. At the same time, now that we’ve set this pace of raises, I wonder what the expectations are and what would be the reaction if I all of a sudden we said, ‘Sorry but you’ve reached your limit.’ In short, how do you deal with raises? How is it tied into the growth of the company? What do you think is fair”
Mike [29:36]: So I’ve never been in a position where I effectively doubled somebody’s salary over the course of a year and a half or two years. I think that that is asking for trouble in many ways, but it’s also hard to go back and change things if you feel like you’ve made a mistake in that particular situation. I think when you get to a certain point, you also have to probably let people know where the business is at and what your priorities are moving forward. And to kind of that point what I would say is go take a look – we’ll post this in the show notes but I would go take a look at [?] profit-sharing program that they put together. And it sounds to me like that might be an appropriate way to go where you’re not necessarily guarantying somebody that they’re going to get a particular raise, but at the same time, you’re encouraging them to work smarter and do things that are going to increase the profitability of the company without directly giving them money regardless of whether the business does well or not.
So, as the business owner, and this is an odd thing about entrepreneurship is that as a the business owner, you are the person who’s undertaking the vast majority of the risk. And if you can do a profit-sharing of some kind where you essentially shift some of that risk back to the employees to some extent, I mean, obviously, it’s like you want to pay them a fair salary but instead of giving them exponential raises every year which you can instead do is say, “Okay. We’ll give you a small raise and we’re going to implement this profit-sharing that allows people to get a much larger upside than they would otherwise in a way that is not guaranteed.” So I think that that’s probably the direction that I would go with something like this.
Rob [31:08]: Yeah, that was going to be my first suggestion is to not make it raises but to make it somehow based on profit in essence. You can’t base it on revenue either, right, because if you guys are growing then there’s not going to be a ton of profit, but if you can share in that then everybody shares in the upside. The other thing – I mean, I think this should be a cautionary tale for people listening. Obviously, I think giving someone a raise in two years from 18 to 31 is, unless they were drastically into market is just way too fast the pace and you have set an expectation now with these folks. So I think the answer, if you haven’t done that, it’s like don’t do that. You can give a raise every year, it’s typical. People tend to I think expect that. And I think that’s a good thing and if they’re solid that that’s fair. But going above and beyond has repercussions. There’s a reason that people don’t often give hefty raises every six months.
The other thing I would think about is what is market rate in essence, like where this person lives based on where their location is. What is market rate for what they’re doing? And if they’re over-market substantially, say, Marcus, 25, and they’re at 31 then have a conversation with them and let them know like, “Look, I know that market rate, you’re over-market rate, we really value but we just can’t continue to bump you up at this pace if it’s only one person who’s way over-market. And there are salary surveys and such. If people are still under-market, then perhaps you can just slow down the pace and just say, “Hey guys, we’ve grown to the point now where we need to do. We’re not going to raise every six months or we’re not even going to evaluate you every six months. We’re going to do it every year instead and you can slow the pace down there.”
I mean, there are options here and none of them are super easy because of the expectation that you’ve set, but I think that you’re asking the right question and definitely thinking about it well because then I think if you were to be flippant and just suddenly change policy, I do think that you’re going to need to have some conversations for sure. And I like what Mike said. I think I like the profit sharing idea just because it then becomes relative to the company’s success.
Mike [32:55]: I think the most important part of all that moving forward though is being a little bit more transparent about not just the company’s finances. And you obviously don’t have to share absolutely everything but let people know, “Hey, this is where the business is. This is the goals that we’re trying to achieve and the reason we don’t want to give you a massive raise moving forward or this year is because we need to grow the business. We need to hire support people. We need to do all these things. So we need to allocate the business resources which in this case is money.”
And then you can introduce the profit sharing, but it starts with those conversations. If you don’t have those conversations, you just drop it on people, then I think you’re probably going to start introducing more problems than anything else. I mean, you have to have those preliminary discussions first and set expectations around what the schedule going forward for raises is and have some preliminary discussions just to kind of float the idea.
I learned a long time ago that I took some leadership classes back in college and one of the things that they recommended was that, if you’re going to a group of people and you want to get their support on something, never walk in the door and just drop the idea on the group because what will happen is the people will shoot it down and there’s always a couple of people who are going to shoot it down because they’re not going to be happy with it. And everyone else doesn’t know which side to go on because they haven’t really heard about it before, so they don’t have all the facts.
And if you do that in this case like this, you’re going to just run into problems. So, float the idea to people. Talk to them a little bit about it beforehand. Get their input and you can actually – if it’s a small enough group with only 12 people, you could probably do that with every single person and just say, “Hey, let’s just keep this between us because I want to float the idea behind. What do you think?” And then everybody feels like they at least got some sort of a say in it or communicated with you about it.
Rob [34:34]: Good. Really good strategy there. So that’s actually how I approach the Drip acquisition with our employees. I went to everybody one by one. It was very time-consuming to have it, because I pretty much cover 30 to 60 minutes per team member. And there were some that were in person, some remote. Some of the conversations were different than others. And it was time-consuming but in retrospect, it was exactly the right way to do it because if I got everybody together, people don’t want to speak up. They don’t want to ask questions. But when you’re doing it one on one, that’s just so much easier. And again, it’s way more time-consuming but there are certain issues that I think warrant that in talking about an acquisition or employee pay, I think are probably two issues that do warrant it.
Mike [35:13]: Well, thanks for listening, everyone. If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from ‘We’re Outta Control’ by MoOt used under creative comments. You can subscribe to us in iTunes by searching for ‘startups’ and visit startupsfortherestofus.com for a full transcript of each episode.
Thanks for listening and we’ll see you next time.
Episode 267 | How to Structure Your SaaS Support Team
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.
