Day 22

We're building a startup in 80 days in public. Day 22 was on Feb 8 '22. You can find today's entry at Day 67.

Today's posts:

Good customer support means saying you’re sorry

Your startup will fall short and will disappoint some of your users. This is inevitable.

  • Essential functionality is missing. When you launch you have to say no to all these features that you really want to include, but there’s no time. You want the core experience of the app to be good, and everything else will barely work or be missing.
  • Your documentation is lacking. Your app is still figuring out what it’s going to be. Documentation comes later.
  • Your app is slower than it should be. You want simple code that you can change easily for experimentation. Optimization gets in the way of that, which means your app isn’t as slick and smooth as it deserves to be.
  • Bugs and other breakage. When you’re pushing multiple updates per day to your app some quality issues are inevitable. You’ll break things. Oops.

Even if you have a bit of a perfectionist streak and you delay launching multiple times because you can’t bring yourself to have your first MVP be a buggy mess your product will still fall short. It has to because good software takes years to build. You’re launching way before you’re ready because you need to figure out if your product concept is good.

Therefore, customers are going to run into all sorts of issues. When a customer contacts you and they’re clearly unhappy you should go out of your way to:

  • Thank them for contacting you with whatever issue they have,
  • apologize for the problem (no nonpologies),
  • talk to them frankly and respectfully about the issue without any corporate euphemisms,
  • then fix the actual problem as quickly as you can,
  • and thank them + apologize again if necessary.

This isn’t rocket science, but practically every business gets this wrong. For every bug report you get another 10 (or 100 or 1000) people are equally annoyed by the bug but don’t say anything because they expect customer support to be useless. If you want to make a product that delights users you have to fix all the little things. If people report a bug and you don’t fix it promptly they’re not going to report another bug, and they’re less likely to recommend your product to others.

You want to fix every single issue people complain about. Bugs are tremendously frustrating for your customers, and most people have bad experiences with computers and with customer support in general. Empathize with your customers. After you’ve fixed the customer’s issue, try to fix the entire class of that issue. If a customer is confused about a dialog in your UI rework the dialog. If you don’t have time to fix the dialog, at least add a little ❓ to the dialog with a popup explaining that which isn’t obvious. Or maybe add a better error message. You can usually do something.

There are occasions where you really can’t fix the problem. Perhaps fixing a bug would take weeks or months, because it requires rebuilding a large part of your app. In that case, explain to the customer why you can’t fix the bug. Not just with a lazy one-liner, but go out of your way to explain why fixing this specific issue is way harder than it might seem. Try to avoid technobabble, but never condescend to your customers. Yes, they can tell and no they don’t like it when they’re condescended to.

Angry Office GIF

Many customer support requests should result in a git commit. If you’re not going to fix the problems with your product you’re basically telling customers that you don’t care. And if you don’t care about your own startup and the customers that make your startup possible, why even bother?

I’ll illustrate what I mean by good customer support.

Customer: Hi there. We can't find the invoices for February and March. Please send them to [email protected]?

Easy enough, right? This is an example of a poor response:

Sh*tty support: Invoices are sent monthly to your billing address. Search your inbox.

This response presumes the customer is incompetent or lazy, which is insulting. Also, it does nothing to fix the issue.

Sh*tty support: [automated email with FAQ responses that may be relevant and some ticketing system]

So rude. You can show customers FAQ responses or documentation before they’ve gone through the trouble to write you an email, if you have to. Lazy autoresponders send a clear signal that you just don’t care and that you view customer support as a cost center.

Sh*tty support: Thank you for contacting AmazingSoft customer support. We want to deliver excellence in customer support and we thank you for your business.

You can download prior invoices at /billing/history.

Thank you for contacting AmazingSoft customer support. We closed the support ticket and no further responses are possible.

This is still a pretty bad response. It’s mostly filler, and the customer can tell only the middle line was written by a human. Although this response indirectly addresses the problem, it doesn’t really. Perhaps the user can’t log in anymore (maybe they closed their account). Perhaps you’re emailing somebody from accounting who has no idea what your software does or how to log in. In addition, the request clearly asked for the actual invoices, which weren’t included in the response. As a whole, this kind of customer support is totally inadequate.

Acceptable support: Hi, I've attached the two invoices below. Thanks for using [product].

Now we’re getting somewhere. The first response that actually helps. But could the response be better? Well, yes! Remember what I said before about a good response involving a git commit? You can create a self-service area where customers can download prior invoices. You can let your customers configure one (or more) email addresses where invoice copies get sent to. You can add a link to the invoice history to every invoice email so customers will automatically see it. And you can add a authkey to the invoice history link so when the invoice email is forwarded to a bookkeeper they can find the missing invoices themselves without having to ask. If you do all this you will only get requests for invoice copies once in a blue moon.

Of course when you just launch a new product you won’t have the time to do any of the above. But realize that the root cause of this customer support request is that your billing system sucks. You cut corners out of necessity and you waste your customers’ time because of it. The same applies for most customer support emails you’ll get. It’s embarrassing. Unavoidable, but embarrassing and you should feel bad about it. And you should tell your customers you’re sorry.

Footnote: As we’re deep into code to get a workable prototype going we’re changing our blogging schedule a bit. There will be fewer articles and more updates about what we’re building.

← Previous day (day 21)Next day (day 23) →

You can follow us on Twitter @jdvhouten and @wcools and look for #80daystartup

Read more

Work/new-life balance
Durable tech
Early user feedback
Spending time to save time
Products want to be platforms
Always be launching
Enjoying the journey
Work-life balance
Recap @ Day 59
Perils of caching
Making sense of contradictions
Trust signals
DIY javascript error logging
Taxes: an automation story
Magical thinking
Start small
High conviction, low conviction
Most deals fail

Post archive