Show Notes
The guys talk about how they are scaling up their awesome customer service without adding headcount and their journey from email customer support, to chat support, and back to email support. They also discuss how to deal with informational silos and if they should transition Honeybadger to an invite-only luxury brand.
Links:IntercomHelp ScoutHoneybadgerFull Transcript:Announcer:
Never forget that you have the tools to build a life on your own terms. Forget the haters. This is Founder Quest.
Josh:
So our topic is customer support.
Starr:
And how how it was maybe murdering us-
Josh:
Eating us alive.
Starr:
Eating us alive, devouring our souls. Maybe we might be doing to fix that. Our old system, the system we've had for years and years. We've been using Intercom. And Intercom put this little widget on your website. It looks a lot like a live chat widget, and just encourages people to enter in whatever problems they have and then you reply to them and they can see it right in the website, or they can get an email or whatever. And we really liked this when we set it up. Years ago, we thought it was really cool because we got a ton more interaction with our customers and were really enjoying that and everything. So why are we looking to change this? What was going on?
Josh:
The way Intercom works in the in-app widget is it really is a chat system. So it's basically live chat, right? From a user's perspective, you assume that someone's going to reply immediately if they're there. And I think it'll say when people are offline or something then it'll let you email. But really for in our day to day it was kind of like whenever a support request comes in, we're thinking, okay, there's someone sitting there waiting for a response so we need to drop everything and answer it right now.
Starr:
Yeah. We would get people just saying, "Hey, what's up?"
Josh:
Yeah, "Hi."
Starr:
And it's six hours later, "Hello. Hello, customer."
Josh:
Yeah, actually, the one offs were kind of ... I might actually miss those a little bit just because someone just says, "Hey." And then I'd often just reply with some emoji waving symbol or, "Yo." In the beginning, like you said, that was really good because it put us ... When we were first figuring out a lot of things, we were first figuring out who our customers are. I think one of the reasons we really liked it was that it put us in much closer contact with people on a real time basis so we could chat back and forth and just be ...
Josh:
It was a little bit more informal and we could just talk to people. And I think we talked about that in the past on this show. How that was good for getting customer feedback and getting to know people. But what we found lately as we've grown and scaled is that it's begun to cause a lot of interruptions, and I guess I would say anxiety in our day to day support process. The way our support process works alongside all the other things we do. And that's probably, we're going to go into that. But basically we didn't have a support process really, which doesn't help.
Starr:
Yeah, because when you know that somebody thinks your support system just being this live chat thing. Then there's a lot of pressure for you to respond to things super quickly. And that can be good sometimes. Sometimes you get some really awesome wins because you're able to fix somebody's problem right away and all that. But sometimes you get bogged down in these super intense support questions, and it's really distracting to, at any moment you could be pulled into one of these lengthy discussions of a thing. And it may or may not actually be honestly. Our system works pretty well. Right? So it's honestly, a lot of times it's just some mis-configuration or something, but there's something weird going on that's preventing people from just seeing that there's some obvious mis-configuration problem. And so, yeah, so you just ended up going down this rabbit hole for half a day.
Josh:
Yeah. And those more of your typical customer support things. That's kind of what customer support is for. Right? But the way we handle support at Honeybadger is again, we're small, small team. We're a technical product, so we like to give high quality support and that usually involves supporting developers. So we are developers on support. We don't have any dedicated support operator or anything like that at Honeybadger, which would normally be able to buffer between some of the more technical questions and the less technical questions. What happens is if you're a developer and you're trying to actually get development done, you're in the middle of whatever your project is, some deep thought or something. And then a support requests comes in, and if everyone's on call for that, you're basically constantly just expecting to be interrupted throughout your day.
Starr:
Yeah, it's like one of those psychology experiments where they watch you as you go about your day and then somebody administers random shots to you.
Josh:
They zap you, yeah.
Starr:
Yeah. And you never know when it's coming. So you just live in this state of expectation.
Josh:
Yeah. The customers who are listening, I don't think you guys are like electric shocks. I mean some of you are, but-
Starr:
I kind of feel sometimes that when I'm doing support, it's almost like I'm doing some whiteboard interview or something where somebody's like, "Okay, here's the problem. And fix it, go." And you're doing this blindfolded. It's like you're a veterinarian and you're trying to fix some problem with an elephant but you can only see two inches of it at a time. Right? It's like you can look at the elephant through a rubber hose from 10 feet away. And you have to ask the elephant, "Well, move the rubber hose over this way for a little bit, so I can maybe see through here."
Josh:
Yeah. You go, "Move it over to Active Record."
Starr:
Yeah, yeah. It's can you squeeze your Gemfile file through the rubber hose?
Josh:
Check the Postgres adapter. Yeah, obviously we don't have access to our customer's code or applications. We have a history of maybe even over supporting our customers, and that's kind of like, we like to do that. We like to actually sit down and really understand what their problem is and help them come up with a solution, even if it's not necessarily problem with Honeybadger. A lot of times it'll end up being, Honeybadger was kind of the ... It's the reason they thought there was a problem, but something's actually mis-configured in their application and we come across a lot of these issues that some of these, they seem to be similar across a lot of different applications when you're installing error tracking code. And we like to help people with that stuff. But at the same time it can be a lot of overhead and it's a lot of work too.
Starr:
Because our library is, it integrates in people's application. And the way Ruby works is that some completely separate third party library can come in and clobber something and then the Honeybadger library will stop working. And so the problem may be the problem isn't in our system, the problem is in this third party thing. But it appears that the problem is on our system.
Josh:
That's one side of the support problem we have. Those kinds of deep technical tickets can come in and just eat half a day, basically. The other problem is the smaller requests, the ones that you mentioned, where even sometimes it's really cool when you can ... Someone chats in and within five minutes you're able to say, "Oh hey, yeah I fixed that," or, someone wanted to ...maybe it's like an administrative task and they chatted and you can fix it real quick, and they're super happy.
Josh:
Every request like that that comes in though is a context switch for whoever is responding, right? So if we're in the middle of trying to get long term work done and if you keep having those little micro interruptions, as you know, it's creating a lot of time out basically because it takes time to get back into the flow and back to what you were previously working on.
Starr:
Yeah. Context switches are super difficult for me, especially because yeah, even for simple tickets sometimes it'll take me 20 or 30 minutes just to remember how everything works and sort of get ... I'm sort of like a train. It takes a lot to get me going. But then once I'm going, I'm good for a while but to always be changing direction. Trains don't change directions very easily. Anyway, so it makes sense that I spent most of my career working with Rails, because I'm a train, choo choo.
Josh:
Nice. I love that we're talking about all these support problems and Ben hasn't really said much so far, but Ben basically does most of our support if we really are honest, I think. Ben, well I guess one of the other things we've been trying to work out or come up with a solution to is the information siloing that happens based on how we've organized our roles at the company. At this point we have four developers. But even with three to four developers, we've each built specific parts of the application and we kind of own, we tend to kind of have ownership of those areas. And so when support requests come up that involve those parts of the application, it's typically our process is just to route those tickets to whoever created the code. But that creates dependencies basically between who can answer customer support requests. Because if it's not documented somewhere and it's the information is in someone's head, basically our only option is to send it to that person or have them wait so they can reply.
Starr:
So what are your thoughts on that, Josh? Because that is a serious problem and I've struggled with that as well because it's like, "Well if I'm spending most of my time either doing front end stuff or working on blog posts and things, I'm not say that familiar with how we process source maps." Source maps is this big system that we deal with that source maps are just inherently complex and messy. And so we get support questions about them. And a lot of times I just really ... I either have no idea of what to do or maybe it'll take me ... I'll work sometimes for an hour or two when you're gone, Josh, and I'll maybe have some very superficial understanding of maybe what's happening, but it's still not really good enough. And it's rough because how do we handle ... How do you deal with that? Because it's the solution isn't for me to learn about source maps because that means everybody at the company has to know in detail everything that's happening at the company, which is just unrealistic.
Josh:
Yeah, I think it's in those cases, it's really about writing good documentation and building good support tools, and then basically relying on those things to have the answers, if that makes sense. Because one trap we've fallen into is related to not trusting ourselves as far as how we built the system or how the system works. So when even I have fallen to this, when someone comes in and says they're having this issue and you know with source maps, JavaScript source maps. They're probably one of the most complicated things to support that we have. But I kind of got into this habit of assuming that there was something wrong, that we did something wrong if someone's having an issue with it. And that's not usually the case from actual experience.
Josh:
A lot of times I'll go in and I'll have to ... Even I have to go in and dive into the code and and dive into documentation on how the source map spec works and try to remember how all this stuff should work together. A lot of times usually it comes back to they didn't have one thing configured right and so it wasn't working, or they didn't follow something in our documentation. What I should've done is just trusted that the documentation was correct. I mean, if we wrote good documentation, does that make sense?
Starr:
Yeah. So what do you do when somebody comes to you and says, "Okay this is broken." Then you just give them a link to the docs?
Josh:
What do you do, Ben?
Ben:
Yeah, the source maps is a good one. Because that one does cause a lot of issues, and it's one that I was weak in. Because, Josh, you built that and so I was like, "Oh that's Josh's thing." But Josh goes on vacation from time to time. And so when that happens you have to pick up that ball. And the documentation that you've written, over those experiences that you've had those repeated times, we have a troubleshooting guide now that is a great starting point for someone who writes in about a problem. So to answer Starr's question, yeah, I actually do. The first thing I do is I point someone to that doc and say, "Hey, did you go through all the things here?" Thank you, Josh, for actually writing that because that saves a lot of time.
Ben:
And sometimes that's not enough. Sometimes there is additional followup. And the person's like, "Yeah, I did read through that and I'm still having this problem." And so at that point I do have to find out what's going on. And I like what Josh was saying about we always assume that we're wrong. It's like, I guess it's our version of the imposter syndrome, right? It's not that we don't know what we're doing, but that, "Oh, I guess we didn't do something quite right. And so yeah, got to go fix it." But usually that's not the case like you said. And just over time, I've had to get more familiar with it. Just a couple weeks ago when you were on vacation, we had a request come in for source maps. I'm like, "Well, I can't really ask the person to wait a week when Josh gets home. I guess I better find out what's going on here."
Ben:
And that was really useful, even though it did take me a day or or two, whatever to find out to dig into that code and find out what was going on. It was useful, and I found a place to do a performance improvement. It's like, "Oh, this maybe could work better, right?" on our end. And so wrote some code there. So for us having such a small company, but the problem with information silos is addressable. It just takes some time, right? Maybe you do have to drop what you're doing and work on something else for awhile that you weren't really planning on. Overall, I think that's a good thing. Right? That helps with the bus number. Right? And allows us to go on vacations.
Josh:
I think we're going to talk about some of the improvements we've been making to address some of these issues, but one of those is around setting clear expectations. And I mean, we want to set clear expectations for what our customers are expecting out of support. But we need expectations too. As a developer, we want to know ... Because obviously we don't want to have to drop. If you're in the middle of a complicated project or something, you don't want to be diving into another complicated project for the rest of the day and then have to try to go back and pick up the pieces. That happening on a regular basis just isn't tenable. We need clear expectations of what's expected of us in order to fulfill our customer's expectations of support.
Josh:
So one of the things we can do is we don't have to respond immediately to answer the most complicated questions of our product. It's okay to say like, "I'm in the middle of something right now. I got your request. I take it seriously. I'm going to respond in two hours," or, "I'm going to respond first thing tomorrow morning," or something like that. It's okay to defer. Really, I mean, you're just emailing with people so you don't have to drop everything necessarily and address it right now.
Ben:
I think that's one of the benefits of having moved away from Intercom's chat setup, right? There's expectation there that if you see a chat window, you're going to get a response. And now that we don't have a chat window, now that it's a leave us a message window, then that expectation's already like, "Oh, okay, I will get a response." And we tell them no, it's going to be in a few hours. And yeah, I'm totally cool with that. And I think that really helps people feel like, "Oh, they're not ignoring me." Even if it's going to take maybe a day. Right? To get that problem actually fixed.
Starr:
I was just going to say, here's a thing that I think about occasionally, which is that we pay ... How much do we pay? We pay AWS at least six figures a year. Right? And for awhile we were paying for additional support. And even when we're doing that, people wouldn't get back to us with developers ready to dive into super detailed problems within an hour. And we're providing this for people who are paying us what, 30, 40 bucks a month? And I think the expectation that Amazon has is that if their systems are working, then it's on the customer to make it work. Right? And they'll provide documentation and stuff like that, but we have kind of defaulted to a different thing where it's like it's always on us to make it work. Even if we end up spending ... If you spend eight hours, 10 hours a problem, 10 hours a problem, $200 an hour. We just spent $2,000 to solve your problem and you're paying us $500 a year.
Josh:
And we do that a lot.
Starr:
So I wonder about that. We do that a lot. And it's like, it feels good to do that sometimes. But then also, it's since we're such a small team, it's like, "Ah, is this really ..." It's like how tenable is this really?
Josh:
Well and there's more efficient ways to address the problem too. If we're actually getting that many requests, requests that are, if we actually support each of them fully is eating that much time, there's a larger problem I would say. And two ways that we're trying to work to eliminate those problems is through creating automated self service tools or improving the documentation and making it more discoverable. Surfacing answers in our support and documentation systems more efficiently or effectively. And I think there's a lot we can do there still.
Starr:
So you guys kind of alluded to the fact that we've recently switched help systems. We're trying out another one. I'm not sure we're 100% sticking with it forever, but we're giving it a shot. So, yeah. So we switched to Help Scout. And could you describe a little bit of the reasoning behind that? Why you wanted to do that and what we've seen happen as a result?
Josh:
The actual reason we switched to Help Scout was that I wanted to try and experiment. When I was trying to address this, the constant sense of urgency and support anxiety issue that I thought that chat was causing. At this point, I'm pretty sure that I was right. I wanted to try and experiment of just turning off chat and moving to email only. The problem I think as I recall with Intercom is that Intercom does not do email only very well. It's kind of built for realtime chat first it seems. Anyway that's what I remember. So basically it was easier to set up, just set up Help Scout for this experiment to try moving to a more email oriented system.
Starr:
Yeah, so Help Scout is a more traditional help desk system where people can email us, or maybe fill out a form online. And then it goes into our backend ticketing system, then we respond to it.
Josh:
Yeah. It has an in-app widget, kind of like Intercom, called a beacon. They actually do chat now so they're moving into some of those features. But I think the fact that Help Scout has always, from the beginning it's been like it started out as like a very email centric tool. That still shines through basically. So I kind of like the way that they've addressed the email versus chat problem a little bit better so far.
Ben:
Yeah. We really like having the UI in our application for someone to be able to submit a support request without having to depend on just opening up their email client. Right? We like that. But we just don't like having chats. So I think that's why you picked Help Scout because we had the best of both worlds in that case. Right?
Starr:
Is the widget pretty lightweight? Do you have a sense of that? I'm just curious.
Josh:
I don't know if I'd call it lightweight. I don't know what they use to build it, but it's pretty much ... It seems like most other JavaScript widgets.
Starr:
One thing that always bugged me about Intercom is it loads basically a React app into your application. I'm just too old fashioned for that.
Josh:
I will venture a guess and say that the Help Scout Beacon is more, it's lighter weight than Intercom's. Because everything Intercom does is heavyweight, it seems. That's just-
Ben:
Yeah. I think none of us are crying over the loss of having to use the Intercom UI for our help supports.
Starr:
Yeah, oh my gosh.
Josh:
Yeah. So I was going to say the second reason that we just decided to try Help Scout was that Ben and I, and Starr too, we've been dying to not use Intercom anymore for other reasons.
Starr:
So Ben, we saving money?
Ben:
We are saving buckets of money. Are you kidding?
Starr:
How much were we paying Intercom?
Ben:
Too much.
Starr:
Like it was thousands a month?
Ben:
Yeah.
Starr:
Something like that? Yeah.
Ben:
It's ridiculous.
Starr:
An insane amount of money. I've never seen another SaaS company that just squeezes blood from radishes the way that Intercom does.
Ben:
But I was going to say, but Help Scout is a nicer user experience in our opinion anyway. We're not huge fans of the single page application model, and Intercom went 100% that way. And it's just nicer to use Help Scout, for me anyway.
Starr:
That's true. And I wonder if having the default be email, or a form submission might actually encourage people to write better tickets? Because a chat window, it's like you're going to be like, "Hey, what's up? Something's broken. I can't get it to work. Peace." But with an email you have to maybe compose something. And you might actually include some details about something.
Josh:
Or all the details, assuming that you want an answer to come back in completion, yeah. I think, Ben, you've experienced that so far a little bit, haven't you?
Ben:
Yeah, definitely. We see better response. We see better requests come in because people do take a little more time to write out the full description of what's going on rather than expecting this is going to be an exchange of a chat, right? So we do get a bunch more information that allows us to actually see, "Oh, this could be the problem." And that helps our customers as well. Because again, with that expectation that they have to deliver us a full message rather than it's going to be a chat. We've seen times where people were like, "Hi." And we respond and we're like, "Hey, do you have a problem?"
Starr:
Six hours later.
Ben:
Six hours hours later, right? And then they're like, "Oh yeah, so here's my problem." Right? Whereas they could have given us the full thing right up front, and we'd be like, "Oh, here's the solution."
Starr:
It's a little more formal.
Ben:
Yeah. Yeah, so that helps.
Josh:
The worst tickets, and this happens on email sometimes, is it's not just a chat thing. But the tickets where it's not a very well formed request. It's just like I'm having a problem. And then you start to get into a debugging, troubleshooting conversation. But the information just slowly drips out in the conversation and a lot of times it's just off the top of the head. So it's not necessarily ... It's like, "Oh, well this is happening so this must be the cause." And so you go deep into that, but then it turns out that, "Oh well that was just ... It's not actually happening," or you just didn't see it correctly.
Starr:
Here's a question. For things like that, for situations like that, maybe we should have a template like open source projects have for submitting an issue where it's like, what did you see? What did you expect to see? What code did you write that did this thing? And then you're just like, "Hey, I'm having a problem." Great, fill this in and give it to us and we'll solve your problem.
Ben:
I'm not convinced. Yeah.
Josh:
You're not convinced?
Ben:
No.
Starr:
I mean, not for everybody, but for some people.
Ben:
I've seen so many open source projects use those templates on GitHub, and, "Here's your issue template." And so many people not following the template, and it was just like, "Delete all that junk, and I'm going to put it in whatever I can put in." So I was like, "No."
Starr:
I guess it requires a good faith effort on the part of ... so 2019, if it's taught me anything, it's taught me to not assume good faith.
Josh:
In anything?
Starr:
On the part of anyone in the world, ever.
Josh:
Moving forward, new policy.
Starr:
Default assuming bad faith. Unless I know that you're a nice person.
Josh:
Yeah. Yeah, Starr went on GitHub and replaced all of our GitHub issue templates with middle finger emojis.
Starr:
Yeah. The world is a terrible place.
Josh:
Oh, I don't know. I'm kind of in between both of you though. I think that even if it helps 50% of people create better, form better requests, or better support responses, I mean, it's probably helping more than it's hurting.
Starr:
It's not all or nothing. There may be some people who just don't know what you want them to give you. Maybe they just honestly don't know, so they're looking to be guided.
Josh:
Right. But also I think from our support process standpoint, one of the things that I am really trying to do is try to identify those kinds of tickets earlier and handle them better, or guide the user better to the solution versus letting them lead the conversation wherever it may be going. Because again, you get into those slow drip conversations that aren't necessarily ... You're not even communicating as efficiently as you could be. So that's part of some of the process that we're trying to implement or work through is analyzing more of our support tickets and actually trying to make improvements to the process.
Josh:
Trying to come up with ideas, like your idea with the template, maybe that's something we could try. But basically coming up with ideas, I'm calling them experiments, where we just try something out for a little while. If it helps then we keep it. If it doesn't then we try the next thing. The moving to email only and then setting more definite expectations of what people should expect from support was one experiment that I think at this point we could call that a success. And I would say that we're-
Starr:
It's a winner.
Josh:
Yeah, I think it's a winner. Announcing it on the air.
Starr:
Yay, we'll have to get some sound effects for that.
Josh:
Yeah.
Starr:
Yay, so-
Josh:
Yes, I think we're going to stick. I think we'll stick with Help Scout. I think, Ben, I don't think I can drag Ben back to Intercom even kicking and screaming. And I don't want to try. So yeah, Ben's the reason really that we can't go back to Intercom.
Ben:
Well the funny thing is, do you remember when we switched to Intercom and what we switched away from?
Josh:
Yeah, we switched from Help Scout. We're complete full circle.
Starr:
We're back.
Josh:
It does feel like coming home in a sense. It's familiar.
Ben:
So I guess the lesson there is if you're running a SaaS and you have a customer churn, they might come back someday. Right? Just keep doing what you're doing and building an awesome product, right?
Starr:
Yeah, I mean I see, because Help Scout didn't really change, but we changed. We decided that we liked that better and we went back.
Josh:
I thought it was interesting that our needs actually did change because when we switched, we had a legitimate reason to switch. We were trying to combine email and chat because we really wanted chat support so that we could have better visibility and more informal conversations with our users. And Help Scout didn't do chat at the time and we were tired of trying to combine two things into one. And Intercom solved that for us. And I remember we were really happy about that switch. Worked really well, we were happy for years. But then our needs changed back. Now we can't handle the strain of at our current level of customers, all of them chatting to us when we haven't scaled our team. It hasn't been linear with the number of people we have on our team versus the number of customers we have. So it makes sense that we've gone back.
Starr:
I feel like we're kind of like a ... When we switched away we were maybe an 18 year old. We're like, "Whatever, old man. I don't need you and your email. That's for old people. I got my new chats systems. What cool people are doing." And then we go, we live some life and we get beaten down and we see some reality. And then we come back and we just quietly start using email again. And then the old man is just ... He looks and he knows, he notices, but he doesn't say anything because he doesn't have to.
Ben:
So you're saying that we're now they ultra mature 24 year old?
Starr:
Yeah. Yeah, so we're ready to maybe start looking for a life partner, maybe start looking for some houses, some stable careers, I don't know.
Ben:
In our next episode-
Starr:
Wait, what am I talking about? 24's still adolescence.
Josh:
I was like, "It's probably six years out for the 401k," but-
Starr:
I didn't have a 401k until I was a ... When did we start our 401k? 35? I don't know, I felt super guilty talking to my accountant about it when she asked. I really liked what you said, Josh, about adding some formality back to the process. Formality means that, I don't know. Formality I feel like is all about expectations. It's like I'm going to treat you in this way that you expected to be treated. And then you know how. You know what's coming so you can prepare for it, and it's just going to be more efficient. Right? It's like a protocol in computers. Our help support protocol has been, just send us some data and we'll figure out what the protocol is on the fly every time.
Josh:
Our old protocol was like UDP. Oh I know Ben will appreciate that one.
Starr:
Except you are always guaranteed to get a response back.
Josh:
Oh that's right. That's a good-
Starr:
Don't go saying that, Josh. That's my best networking joke I've ever made.
Josh:
That was really good.
Ben:
That reminds me of my favorite joke. I would tell you an UDP joke but you might not get it.
Starr:
Oh, boom.
Ben:
Love it.
Starr:
Boom. So what's next? What's the next experiments? What's on deck?
Josh:
We've got the clear expectations. We have office hours now, which we kind of had before, but I think it's a lot more agreed upon and clear. And I think 9:00 AM to 3:00 PM Pacific is our defined support window where we're here active on it. If you sent an email after that, we actually have a response that goes out that says, "We might reply." We still try to offer the same high level of support that we always have. It's just we try to do it in a way that isn't killing us. So yeah, so we might say, "We'll get back to you in the morning or the next business day or whatever."
Josh:
But when we do, it's going to be the most kick ass customer support that you've ever had by a real developer who understands you. We can get the best of both worlds there. As for what's next, is just continuing to iterate on this experimental approach to automation and documentation for support. So I want to figure out how to make our support even better and make it even less dependent on the silo, the information silos that we were talking about earlier. So that involves actually looking at the customer support that we're doing on a regular basis and then actually making improvements gradually to issues as they come up, or coming up with, like we said, self-service type solutions, making our documentation more clear.
Josh:
I might like to try Help Scout's support beacon actually has an answers feature where it lets you put documentation into the widget and it'll surface that information before someone would actually contact you. So we might be able to actually surface some of the most common answers or troubleshooting guides even, up front. Things like that. Basically like trying to figure out how to make support something that anyone in the company can come into for a day or a week or something and do as a job versus having to route everything to the right person basically.
Starr:
That sounds really useful. So before we go, can I just throw out one out of the box lateral thinking idea at you? I think this could revolutionize our support. So you know how most of our support comes from people just getting set up in the products, for people who aren't sort of long time customers? So we make Honeybadger a invitation only product. We make it exclusive. It's like a country club. So we only invite people we know are super competent and won't throw us any support tickets.
Josh:
That sounds like a home run. We'll make it an experiment though, so in case it doesn't work out, we can always just revert it.
Starr:
I don't know. I think that you just can't put a value on exclusivity and on luxury Josh. The feeling that you get from knowing that just not anybody can sign up for the error tracker that you use.
Josh:
So we're not selling an error tracker anymore, we're selling a feeling of exclusivity.
Starr:
Yeah, maybe we could get PDiddy or something to become a limited partner in the business.
Ben:
See, I don't know that that's really on brand for the Honeybadger. Maybe if our mascot was a giraffe, that would be more exclusive feeling. I don't know. Honeybadgers, exclusivity, it just doesn't feel-
Josh:
Honeybadgers are breaking out.
Ben:
Yeah.
Josh:
You know, right?
Ben:
They're more democracy, and like, yeah. Everyone gets a piece of this pie, right?
Josh:
Everyone gets a piece of the honeycomb. Except no, just-
Starr:
The honey badger came from a rough neighborhood, and you're going to hold that over him his whole life. He has worked and clawed his way out of that situation, Josh.
Josh:
And you know he's not sharing that honeycomb either.
Starr:
All right. I think this one is going off the rails. So now we need to ... I think we better wrap it up. Yeah, if you enjoyed this episode of Founder Quest, go on your podcast thing and vote it up. Give us a positive review and everything. And we will check y'all next week. Bye.
Announcer:
FounderQuest is a weekly podcast by the founders of Honeybadger. Zero instrumentation, 360 degree coverage of errors, outages, and service degradations for your web apps. If you have a web app, you need it. Available at honeybadger.io. Want more from the founders? Go to founderquestpodcast.com. That's one word. You can access our huge back catalog, or sign up for our newsletter to get exclusive VIP content. FounderQuest is available on iTunes, Spotify, and other purveyors of fine podcasts. We'll see you next week.