Great Expectations, Part Four: They’ve Got Questions, You’ve Got Answers

by Sanya Weathers

Here’s the scene: The game isn’t yet launched, but the alpha build was solid, and your first, very limited beta is going very well. Your team is hitting their deadlines, and you feel confident that the game will launch within six months. (And if you’re not, stop reading this post now, because you should not be taking questions from the general public yet.)

You’ve been feeding information to news sites, hoping to pique the public’s interest in your game. And it worked. Interest is piqued, and peaking too. Potential players have come to your site, and they’ve started to ask questions about your design, your target market, and more. To streamline this process, you’ve decided to set up a forum to officially take their questions.

But be careful. The usual mistake is throwing out a general request for questions. When you invite people to ask questions, you create an expectation that you’ll answer them all, not cherry pick the easy ones. And the customers aren’t going to ask any easy ones.

Here’s a quick guide to making the question process better for everyone:

–    Treat them as customers even though you’re months away from taking their money. Don’t be too casual. If you’re hanging out on your pre-launch forums killing time by answering questions, you are setting the expectation that you’ll always be this available, this open, and this willing to speak off the cuff. And you won’t be. Are you really going to be different from every other developer in the history of the universe? Maybe, but that’s not the way to bet.

–    Build your dev tracker, your FAQ, your search tools, and your wiki tools before you start answering questions. Most questions will be repeats, especially over time. So save yourself time, and have your community specialist archive your every golden word. If you don’t do it, someone will do it for you – in their sig file, out of context, on a third party message board.

–    Set parameters in each call for questions. For example, you are not ready to answer questions about combat scenarios  unless you’ve logged a few hundred hours of playtesting. If you haven’t done that testing yet, state up front that you’re not answering those types of questions. Do give them a specific topic, and don’t be afraid to be too specific. Your average early adopter can come up with twenty questions on looting tables. Use that tendency to your advantage.

–    Once you have stopped reading the question thread, lock it. A question thread still garnering user activity is creating frustration in every single customer posting after the point where you stopped reading.

–    If you put out the call for questions in a thread, you can’t cherry pick from that thread. By making the request, you created the expectation that you will answer them all. You can delete those questions that are not within your stated parameters, but the rest have to be answered.  But remember, “I don’t know yet” and “No” are answers. The pre-launch phase of development is the best time to use those two – but do follow up on the “I don’t knows.”