Tag Archives: support

App maintenance and subscription rejections

Jason Snell closed his first take on App Store subscriptions with a question about iPhone app maintenance vs. web services maintenance:

Whether Apple would actually reject a subscription-based app that doesn’t offer any functionality outside of itself, I don’t know. It sure wouldn’t be the first time there was a baffling App Store rejection. But does Apple really want to take the position that ongoing maintenance of a web service has value, but ongoing maintenance and development of an app does not? I don’t think it does.

As I wrote about in my post yesterday, users can more easily see the hosting costs for a web service. They’ve been trained by a decade of paying for web subscriptions. Maintenance for the app itself has some differences.

Think about how costs scale if an app becomes popular. A web service becomes expensive to run, often thousands of dollars each month. You could say that a developer’s time for app maintenance is also thousands of dollars, but it’s essentially fixed. Outside of customer support costs, the incremental cost to a developer for an app doesn’t increase in the same way it does for scaling a backend service.

I hate that Apple has the power to reject our business model for a potential app. I’m now leaning more to the idea that Apple should approve nearly everything and let customers decide on the value. But there is a difference between maintenance of an app vs. a web service, and the services that are clearly appropriate for subscriptions will be the most successful apps using this new model.

Faster support response times

In an “interview with Kevin Hoctor on episode 5 of the iDeveloper Live podcast”:http://ideveloper.tv/shows, Scotty referenced my comment from Core Intuition that customers are so used to terrible support that they don’t mind a few days or even a week delay. I thought this was maybe taken out of context a little since we were talking about vacations, so I went back to listen to what I said:

“Most people are thrilled to get a response in a few days, maybe a week they’re still cool with it. They are used to sending support email to companies and not getting a response any time soon or maybe not at all in some cases.”

Of course I didn’t mean I strive for week delays before a customer gets a response, but looking back I think Scotty’s interpretation was right: in a way this was a confession that I’ve fallen down when it comes to support. My response times for Tweet Library questions are still very good (usually same day), but it’s dragging for my other products. Even when I’m quick to respond to an initial email, difficult follow-up questions often won’t see an answer for some time. I’m just not as responsive as I was when I wrote “this blog post about good support in 2007”:http://www.manton.org/2007/02/customer.html.

The worst part are the emails that fall through the cracks. They are on their 2nd or 3rd response to a problem that I don’t understand, or they’re waiting on a solution that isn’t ready, and months go by before I can pick up the thread again. I hate this.

I’m going to use this opportunity to get back to where I should be: less than 24-hour response in all cases, for all products. I’m adding a “stats section to my support page”:http://www.riverfold.com/support/ to keep me in check, and I’ve seeded it with response times for the most recent support questions via email and forums. This will also give customers an idea of what to expect without an explicit promise from me.

Better software, less support

A few months ago “Ars carried a story”:http://arstechnica.com/journals/apple.ars/2008/10/09/slowing-economy-impacts-apple-call-center-in-colorado about Apple canceling a call center in Colorado. This part stuck out to me:

“Somewhat surprisingly, the iPhone 2.1 update was also named as one of the reasons for the cancellation. The software update has apparently been so successful at resolving iPhone 3G problems that its release has caused a noticeable drop in support calls.”

In this case it was just bug fixes, but it reminded me of “Getting Real”:https://gettingreal.37signals.com/. Make software easy to use and simple and then there are fewer things that can break and users are less confused. I have been obsessed with following this advice lately. Some of the limitations I’ve put in a couple recent projects:

  • No preferences (for Mac, no prefs window; for web, no options or settings screen).

  • Single toolbar (no status bar or need to look in multiple places, e.g. both the top and bottom of the window).

  • Minimal toolbar buttons (only the absolute basics are exposed outside of menus).

  • Opinionated defaults (no customization, similar to others above).

On a few occasions this has hurt my ability to add features, but on others it forces me to see a user interface problem from a new angle, something I wouldn’t have done if I hadn’t had these limits to work in.

Limiting features in an app does not come naturally to me, but the more I embrace it, the more value I see in it. I “tweeted a bonus side effect”:http://twitter.com/manton/status/1177252437 to this approach last week: “Maybe another reason why simple software succeeds: customers see in it all the possible features to come, implemented just right for them.”

Customer support

One of the most interesting (and difficult) parts of running an independent software business is responding to support email. It is very time-consuming and often more frustrating than writing code because the solutions can be illusive. You want to help the customer, but it’s not always obvious how.

Two blog posts in the last week take entirely different approaches to customer support. The first is from Ryan Carson, who is well known for DropSend and The Future of Web Apps conference. Here’s a snippet from his response to a customer:

I am now marking your email address as spam and your communication will no longer get through. If you don’t want to use our service any more, please cancel your account.

I was relieved to read the comments, which are more sane. I think Ryan made a mistake in how he dealt with the customer, and wasted a bunch of time in the process. Adding a customer to your spam filter? Yikes. I would have refunded the customer their $5 immediately.

(I actually like a lot of what Ryan writes and the events he puts on, but lately I find myself noticing the differences. As another example, his post about outsourcing programming work to Russia left me puzzled.)

Joel Spolsky also wrote an essay on support, and it’s just about perfect. I especially like his section on memorizing awkward phrases:

It’s completely natural to have trouble saying “It’s my fault.” That’s human. But those three words are going to make your angry customers much happier. So you’re going to have to say them. And you’re going to have to sound like you mean it.

For almost every support email I get, I start by responding like this:

Hi Bob, Thanks for purchasing Wii Transfer. I’m sorry to hear it was not working correctly for you.

This does three things right away that I think are important:

  • Greet the person by their name. Kind of like making eye contact. And it’s respectful without being overly formal.

  • Thank them for using the product. If they haven’t bought it yet, replace “purchasing” with “trying.”

  • Apologize that the software gave them trouble. This is mostly equivalent to Joel’s “it’s my fault” phrase.

Although I could probably respond faster by using some macro shortcuts that do this for me, I actually type this out every time, varying it slightly as is appropriate for the question. I then move on to the actual solution or follow-up question about their issue.

This is more than just trying to be nice to people. As someone in the comments to Ryan Carson’s post said: you need to show the customer that you are on their side. Going negative demonstrates that you care about receiving their money but not actually building something useful that makes their life easier.

Here’s a portion of 37signals take on being on the customers side, from Getting Real:

At 37signals, all of our support emails are answered personally by the people who actually build the product. Why? First off, it provides better support for customers. They’re getting a response straight from the brain of someone who built the app. Also, it keeps us in touch with the people who use our products and the problems they’re encountering. When they’re frustrated, we’re frustrated. We can say, “I feel your pain” and actually mean it.

Most people who buy Mac software from independent developers know that it’s only 1-5 people behind the company. We can’t compete with the Microsofts and Adobes of the world on application size, but we can compete on quality customer service. Being small is a competitive advantage.

I’ve exchanged at least a couple hundred emails in the last few months with customers or potential customers. (I don’t actually distinguish between users who have bought the product or who are just trying it out. They all get the same level of support.) Have I handled each one perfectly? Probably not. There are a few people who are still experiencing problems. But my hope is that just writing this blog post will serve as a guide and reminder of why taking support seriously is worth it.