If, as a previous commenter suggested, it were $0.25 per issue, that’s about 2 minutes of time at minimum wage; barely enough time to read a request and reply with “Maybe.” And since we position ourselves as a service for experienced users, we don’t have any minimum wage “tier 1” script-readers answering support inquiries. We need people who can understand and troubleshoot complex problems, and then effectively communicate the explanation. We need people who view it as a career path and not as an alternative to fast food with no heavy lifting, which means we need to pay accordingly.

So if we were to charge less per issue than it costs to provide the answer, we’ve magnified the problem, because we would have codified the old joke:

Me: We sell each issue at a small loss.
You: How do you make a profit?
Me: Volume, volume, volume!

The second problem is scope. What if a person pays their $0.25 (or whatever) and asks two questions in one request? Do we tell them to resubmit the other one? What if they respond to our answer and say “Well, what about this…?” or “I was also wondering…?” We already get people who try to reply to weeks-old issues rather than start new ones, just to keep the message on the request page from changing. What about complexity? Some questions just take a lot longer to answer than others.

Do you implement a sliding scale or charge based on the actual time it takes? But if the person doesn’t know in advance how much it will cost, what if it turns out they can’t afford it, or the answer is not worth that much to them?

The third problem is this: not all support issues should be paid for. Should you pay to get a response to a “Hey my site isn’t working!” issue? Well, it depends. If it’s not working because one of our servers is down, then no, you definitely shouldn’t. But if it’s not working because you skipped a step during the setup and you need us to point out which one, then yes, you should. Between those two examples, there is a lot of gray area, which leaves room for disputes and arguments over what someone should or shouldn’t have to pay for.

The fourth problem is satisfaction. What if the person who paid for an answer isn’t happy with the answer? Either we expend unlimited effort until the person is satisfied or there has to be dispute process again, which would take more time and cost more money.

Sure, the dispute processes could be “Don’t like it? Tough luck!” and that would work fine for us, but it would alienate people. When we encourage people to find a service that provide a higher level of support for a higher monthly fee (for example, people can sometimes really benefit from telephone support, where someone can walk them through something step-by step), we do like to try to do it gently, without alienating them, so that once they gain the necessary expertise, maybe they’ll give us another shot. Putting people in a situation where they feel like they got ripped off won’t get us there.

Finally, there’s a focus issue. Our service is designed for experienced users, so when a situation comes up, we often have to say “do we optimize this for experts or novice users?” Systems optimized for experts annoy novice users and systems optimized for novice users annoy experts.

One example of how that can hurt is our member FAQ. It’s grown to a fairly unwieldy size and can be hard to navigate. It’s not really good for experts or novices right now, because there’s a lot of material in there pulling it in each direction. We need to make some changes there as well.

Similarly, even if you give out the first one free, pay-per-issue schemes seem to be dragging things away from our focus. Offering to respond to issues for a fee creates a sort of unlimited obligation to answer all those questions that we shouldn’t be answering. Even if that means we make more money, it also means slower response times for our core users when they need it most.

Remember, our goal is not to make money from support, merely not to lose any.

So that’s why limiting the number of support requests (as one example) might make more sense than charging for them (as another example).

Over the next few weeks, we’ll see how well the heavy support users self-identify and opt in to Extended Support, and then we’ll go from there. We do have some other good ideas that we’ve kicked around that should help us make sure everybody gets what they need, which is ultimately what we’re here for.