Positive Internet

There are a many tales of horrible technical support experiences. Listless automatons who seem to be reading from a laminated script. Long call queues leading nowhere. An infuriating refusal to allow you to speak with someone who can actually solve your problem. Being stuck as a modern-day Sisyphus in an eternal "support escalation" hell.

Of course, the primary response to such tales is to use a more competent, humane organisation. One like ours (hey, this is the Positive Internet blog, after all :-) We do try really hard not to be jobsworths. We get our hands dirty. We try to act as if those seeking support pay our salaries. Because, well, they do.

We like Email as a primary support medium. It means that you can paste us copies of logs, we can type the exact URL you need to visit without having to spell each letter out on the phone. It means that you have a full written record of the ongoing issue, and a later reference for how we solved it. In all, Email is perfect for this. Of course, too many organisations have tainted the form as an effective support channel. They take too long to respond, or don't respond at all. And when they do respond, it's illiterate, haughty or confused. We try very hard not to be that sort of company. Our 3-working-hour support promise and related efforts underlie this.

All this said, even with the best support team, getting help is a two-way street. There are things you can do when seeking support that can help you massively in getting good answers quickly. I'll present you here with some tips, all based on real-world examples. Some might seem obvious. Even then, you'd be surprised how often the obvious is overlooked:

Set your subject

The subject-line of your mailed support request is what the team sees when they scan a list of tickets. As such, they can be useful in quickly identifying which ticket is yours and in offering a quick summary of the problem. As such, it's puzzling how many people set their subject line to something generic like "urgent" or "help please". Or nothing at all. Instead, use a short, descriptive, identifying subject which will help the right people in the team get to your ticket more quickly. For example, let's say that one of your database queries is timing out, and you'd like help in identifying why. You might have the subject as something like:
 Subject: Simple DB query on www.example.com times out

I think you'll agree that this will get the DB experts' attention more rapidly than something like:
 Subject: Urgent!!!!!!

This is especially true if the ticketing system is full of "urgents". Again, it may or may not surprise you to realise that many "urgent" subjects are not urgent in any reasonable interpretation of the word. Indeed, the word has become so devalued in support circles that it's seen as crying wolf. So, ironically, if your problem really is urgent, try not to use the word "urgent" if you want to get good support.

Say who you are

We certainly try to get to know our clients, and get quite good at identifying Email addresses and the like; however, you'd be surprised how often we receive a mail from an unrecognised address, asking for help on an unidentified site. What would you do if you received a message like this?:

 Subject: site down
 From: BR <br2947@yahoo.com>

 Hi. My site is down. Can you tell me when it is going to come back up?

Who are you? Are you even a client of ours? What site are you talking about? Of course, our first response will have to ask all these questions, which will just mean that the actual help will be delayed. Mention your name, the organisation for whom you work and any usernames/domains/server names in question. Yes, it'll take an extra few keystrokes, but I promise you that the disambiguation will save time and get your ticket answered more quickly.

Say what you see

Sometimes, we can all be a bit solipsistic. We forget that the people we talk to don't have a bird's eye view of our thoughts. So, when we say "the site's down", we forget that this comes with a lot of contextual baggage that we just take for granted. Which site? How do you mean "down"? How did you check? How can someone else confirm this?

A group of philosophers in the 20th Century, called the Logical Positivists, deployed what they termed the "Verificationists' Creed" when they tried to work out what things meant. It went like this: "The meaning of a statement is the method of its verification". Whilst the Logical Positivists are no more, this creed that was such an important part of their toolkit is astonishingly useful in giving and getting good technical support.

Use the creed as a rule of thumb when writing to support. Instead of saying "the site is down", think "To get the meaning of the statement 'the site is down', I need to describe the method of its verification. Otherwise, it's ambiguous at best, or meaningless at worst". Then, type that verificatory method out and send the ticket!

So, for example, instead of:
 Hi. My site is down.

You might say:
 Hi. I am trying to visit www.example.com in my Firefox 3.5 web browser, and it immediately returns an "Error 404" message.

Notice that this doesn't describe or summarise a "metaphysical" situation: it describes what you're doing - something we can try to replicate. So, always describe the steps you take rather than your opinion or summary of the results of those steps. Then we can follow those steps too, and can either confirm the problem or point out which step was in fact a misstep.

Say what you want to see

Sometimes, saying what you want to see isn't enough - you need to let us know what you'd want to see in normal operation. For example, if you complain that something looks odd, we need to have some yardstick of normality. So, let's say you send in a ticket, saying:
 When I view my web page, it has a blue background. Can you fix it please?

Well, you've followed the verificationists' creed - you've explained what you see, rather than just saying "there's a problem with my web page"; however, we don't know what you expect to see instead of a blue background:

So, you might add something like:

 When I tried to view the same site last night. it displayed with the correct yellow background. I haven't made any changes that I know of.

That way, not only can we validate what's wrong, but we can validate what state we need to help you to attain to make it right.

Say where you are

The Internet's a big and complicated place. Sometimes, problems that you might see at your end of it could be caused by any of a dozen of possible points between you and your website at our end. To help us verify where a problem might lie, you should make a habit of providing your remote IP address. You can find this by visiting a site like http://itempeter.com

We can then find out whether your ISP is having network problems, whether some local firewall is blocking you or whether there's a problem somewhere else between you and us.

Say what you're using

Sometimes, different software on different operating systems can produce different results when accessing Internet services. Let us know what you're running and how you're connecting to the Internet and we can analyse whether that might have any bearing on the issue.

Try alternatives

If something seems to be awry, try to replicate the result using a different context or system. Try a different brand of web browser, try using a mobile phone on 3G to view the same issue, call a friend and ask whether they notice the same issue. This can help you and us to determine early on whether the problem's related to some local issue at your end, or whether there's a more general problem.

Tidy the thread

As replies on support tickets get batted back and forth, the quoted previous reply can obfuscate the fresh content. We've all struggled through a thicket of triple-quoted, confusing old text to find the craftily-inserted new update. Instead of solving your problem, we spend the time parsing it. The best thing to do is to delete most of the old baggage, and leave in just the sentence (or perhaps paragraph) to which you're responding. If you're adding responses to a number of previous question or comments, then delete the stuff in between with, perhaps [snip] in its place to show that you've done so. This sort of pruning can be really useful in getting directly to the evolving heart of the issue.

Keep things separated

If you have a number of issues, and they're all related then, by all means, mention them in the same ticket; however, if you have a number of unrelated issues you wish to discuss, it's probably best to put them in separate tickets with separate informative subjects. This means that not only will the successful solving of one problem not lead to the mistaken ignoring of the others - it also means that different members of the team can focus on the different issues in the different tickets in parallel.

Don't panic

In the end, our team's probably seen your issue before and, once it understands what's going on, will be able to solve it. And in the meantime, there are always pictures of kitten to look at!