Monday, December 3, 2012

More Customer Relations

On several occasions, customers have mentioned how much they appreciated that I was both responsive and kept a regular update schedule with NEO Scavenger. It's nice to be complimented, of course, but I was a bit surprised that folks noticed. Does this mean some other indies aren't keeping their customers up-to-date? Or worse, is that negligence the case for such a majority that good customer relations is praiseworthy?

I hope not. And thankfully, that doesn't seem to be the case with many indies I know personally. But I'll admit, my pool of indie friends is pretty small. In the spirit of sharing best practices for aspiring indies, maybe it's worth going over some customer relations policies that I adhere to.

Publish Regular News

I have a pretty strict work schedule. I work 9am-6pm (ish), Monday to Friday. I don't work on weekends nor stat holidays. And I give myself 3 weeks of vacation each year. For each day worked, I publish news on my company website (with RSS, as requested by several customers), at the end of the day .

I also post news about my availability. When I'm going to be out of the office, I post news to that effect. Similarly, I announce vacation plans in advance. I think it helps to set the correct expectations if you're going to "go dark" for a period of time.

My company website's news is for customers to see what I'm up to. It's the primary means of reaching customers in an official capacity. If someone wants to see what I'm currently working on, the news will tell them exactly that, to within one business day.

I think it's easy to forget, as a game developer, what it's like being a fan of a game in development. We may have forgotten the days of poring over every screenshot, interpreting the HUD and UI in previews for hints of unrevealed gameplay, or reading interviews in hopes of glimpsing the creative process. For someone not in the world of game development, even the mundane tasks can be interesting.

So share! Talk about some of the interesting problems you had to solve that day. Or think out loud if something's got you stumped. If you started using a new tool, talk about your experience with it. When it comes to making games, someone, somewhere, probably wants to know what you're up to, or why you arrived at a decision.

There's also a marketing advantage to regular news updates: proving that your project hasn't stagnated. Often times, when checking out unfinished software, one of the big questions we ask is, "how likely am I to see this thing finished?" If you're about to commit resources to software, you want to know if your investment is going to be worthwhile. This is true of both monetary and time investment.

So when you're gauging a project's likelihood of being finished, what's the first thing you do? Well, you probably check to see how frequently it's updated. You read the news, browse changelogs, check the dates, and see if the product is active or dead. If the user sees that your news is only updated semi-annually, there's a good chance they'll assume it's not actively being worked on. So if you're working on the project actively, you may as well let everyone know!

And what's more, it becomes a tool for you to use as well. Wondering what you were doing last month at this time? Check your news! Having a daily, public journal entry about your work is a great way to keep track of your decisions, solutions, and progress.

Open Hailing Frequencies

News is a great way to "push" info out to your users, but communication is a two-way street. You should be prepared for customers to contact you, with questions, suggestions, concerns, and praise.

In the case of Blue Bottle Games (BBG), I have several channels, such as my own forums, news comments, Twitter, email, Steam Greenlight, and Desura. Different customers have different channel preferences, so having a variety of channels means most customers can use a method they feel most comfortable with.

I also keep tabs on a few forum threads around the web, as communities will sometimes spring up in the forum of their choice. Usually, Google Alerts is the tool which helps me find these discussions as they appear.

Maintaining multiple channels does place a burden on a developer, though. It sometimes takes me over an hour each morning to keep up with all of these channels, and quite often, it's impossible to cover them all. As a result, I prioritize them, and doing so consistently helps customers to know where they can go for urgent matters vs. casual ones.

For example, my email is one of my top priorities as a business owner. Every single email I receive (save occasional spam, like SEO offers) deserves a response, so I'll usually deal with that first. Comments on BBG news items are also a priority. The news is what I'm working on right now, so customer comments on that are highly relevant.

Tech support is another biggie. I hardly have time to scratch the surface of the BBG forums (particularly suggestions), but tech support is a frequent haunt of mine. If my product is broken or causing trouble, I want to know so I can fix it.

I have a few customers who reach out to me on Twitter, and I always reply if I see them. However, I find that many journalists also tend to prefer Twitter, so there's a second reason to consider opening that channel, if you haven't already.

Desura and Greenlight are also official "presences" that I maintain, though they're a bit easier since most messages are consolidated on one page. In retrospect, the Desura forums was probably unnecessary, as the main summary page comments do the trick for feedback.

There are many others, of course, and it will depend on the community you're building, and the ones you want to interact with. Just make sure you only open as many channels as you can manage. Like news, an unattended channel can reflect poorly on your business, and give the impression that your project is vaporware.

Be Responsive to Customers

So just how responsive is enough for all these channels? As a business owner, you'll have to decide on a timeline that works for you. Generally, I try to respond to customer inquiries within one business day. It gives me some time to consider how I'll respond (and to find an answer, in some cases), but it's a short enough time that most will be understanding.

One exception is in cases involving order issues and lack of game access. In cases like these, I respond as soon as I am able to, usually immediately.

As mentioned earlier, though, it's impossible to keep up with all chatter, everywhere, all the time. So I find it works best to stay 100% reliable on primary channels like email, official platform accounts (i.e. Desura), and tech support, and use any remaining time in my PR schedule to address the most relevant concerns I find (forum comments directly related to my current development, Greenlight comments, etc.).

How to Treat Customers (and Trolls)

In addition to where and when, there's the matter of how one responds to customers. In most cases, politeness and earnestness are the key things to strive for. It's hard to go wrong with being respectful. In my experience, folks are much more willing to discuss things constructively and politely if you lead by example.

Even some of my harshest critics get a "thank you for your feedback," and I do my best to address their concerns. If they bring a valid argument, it's important to recognize it as such, and let them know they're at least heard, even if you don't agree. Often, in these cases, they simply want something different than what you're building. And making that plain disarms any animosity.

The one exception to the above is the internet troll. A troll is someone who's primary interest is causing a stir, and getting a reaction out of people. It can sometimes be hard to tell the difference between a frustrated customer and a troll, but be assured there is one.

Some customers may be insulting, or terse, or misinformed, but they want something better (be it better features, better service, or a better community). A troll is just looking to get attention, at any cost, by any means.

I've talked a bit about this before in my PR policy post, but I'll repeat the summary here: ignore the trolls. Don't use your power of influence to draw attention to them by responding or addressing them. Just pretend they don't exist. If they are particularly disruptive, and your community allows it, you may have to ban or edit their comments. But more often than not, they'll go away in search of more interesting targets if you simply ignore them.

Frequent Builds

This one will depend a bit on your product and how you're distributing it. In my case, I'm offering a game which is still in development, and distributed digitally. As such, I can update the distribution channels with new builds as I develop them. And this is a powerful tool.

For one thing, it's a more powerful version of the aforementioned news updates. It's an actual, functional news item that players can try for themselves. If the updates are interesting enough, it can keep the game relevant in the players' minds for a long period of time, instead of the short-burst often seen in retail releases.

Additionally, adopting a policy of frequent build releases gives the developer a chance to try features and content with customers before committing to it in the final product. And it gives players a real way to influence the game for the better. For example, player feedback was instrumental in making NEO Scavenger's combat orders of magnitude more engaging than the original iteration.

The one caveat here is to be careful not to lean on your customers too much as a source of quality assurance. They will find bugs, and that's natural. But as a developer, you should not expect them to bug test your software for you. In fact, do everything you can to make sure each build is stable enough to be fun. After all, they're still your customers, not employees.


There's one other topic that I thought might be worth mentioning, and that's dissatisfied customers. No matter what you're selling, there are going to be some folks who experience buyer's remorse. It could be that your product failed in some way, or perhaps they simply expected something different.

Whatever the case, I think it still pays to be respectful, and I'd probably issue the refund. I can't think of many cases where arguing with a customer over a refund ends well. Even if you keep the money, is it worth the time, bad press, hard feelings, or potentially, the customer disputing the charge with their payment provider?

There are some exceptions, of course. If the customer had the game for several weeks, and then wanted a refund, I'd wonder why it took that long to seek the refund. But even so, as indie developers, a single refund isn't going to break the bank. There's no need to haggle over a few bucks (nor is it even worth it).

You'll probably have noticed a pattern in the above suggestions. Basically, treat your customers with respect.   Customers are a diverse group, with a range of expectations and skill at communicating. For the most part, though, they mean well. Give them the benefit of the doubt, set a positive example, and they'll return the favor!


  1. Great stuff. I hope you are planning to put all of this in a book.

  2. You know, I've been thinking about that. There was an author someplace on the web who was saying "seriously consider publishing your blog in a book, since self-publishing and e-books have lowered barriers."

    I wish I could remember where I saw that. But yeah, it'd probably be worth going back over the posts, and editing, applying hindsight, etc. to see if there's a book in there.