Supporting the supporters
Find out how to help your friendly technical support person, in David & David's helpful guide.
We're blessed in the Acorn market with authors and companies who generally offer excellent levels of technical support for free. Many a person has posted to the Pluto mailing list to request a feature, only to discover that Jonathan Duddington implemented it five minutes before receiving the message, and has incorporated a cure for world poverty, the 'flu and Jeremy Beadle into the bargain. This is not a good situation, the RISC OS market should be encouraged to move towards the 'industry standard' of unhelpful support staff, who take every opportunity to imply that the customer is an idiot for even needing help in the first place.
Towards this aim, we (the Davids Pilling and Matthewman) present our handy guide to making the technical support person's life difficult. This step-by-step plan is built from the combined experience of many years answering support queries - mostly by e-mail these days - that has given us both a clear insight into how to write the sort of query that turns a mild-mannered support person into a gibbering, puppy-kicking misanthrope. Trust us, we know whereof we write. We've received those e-mails, and there are labradors that cower whimpering when we walk past.
Supply just the right amount of information
In other words, send an e-mail consisting of the single word 'help'. We've both received these before; and yes, we are psychic. Another good trick is to e-mail someone like Clares and say 'Your program won't install,' leaving the person on the other end to try to figure out which of the many programs they sell is giving problems.
If the ungrateful support person comes back with a request for helpful information like:
- system details
- procesor
- model of computer (and, these days, manufacturer)
- main pieces of installed software
you might feel worryingly obliged to give it - it's a reasonable request after all. Take heart. Now is the time to go for the second approach: the detail flood. If you include a directory listing of your hard drive, a memory dump of the RMA, a copy of the offending software and ten screenshots then not only will you probably kill the technical support person's e-mail (allowing him/her to concentrate on your problem alone) but even if you do unwittingly provide the information it'll never be found.
On the subject of screenshots, most useful ones are of dialogue boxes. Switching to a 16-colour mode, cropping the screenshot to the dialogue box and then compressing it in an archive gives a small file which efficiently delivers all the information needed. So you won't be doing that then. A 24-bit sprite of the whole 800 x 600 screen is much more artistic, after all. Or you could go the other way, and include the screenshot as a really low-quality JPEG 'to save bandwidth'. With any luck it'll be far to blurred to read.
Remember, in the old days, large files were slow and expensive to shift over a modem. They still are.
Don't say 'XXX gave an error message saying ZZZZ', say 'XXX went wrong'. We just love playing twenty questions with people to work out which program went wrong, in what way it went wrong, and what you were doing at the time. Incidentally, 'trying to update the software while running a copy' continues to be one of the most entertaining answers to that last question.
Spam-block your e-mail address
Be wary! We technical support people are just aching to sell-on our accumulated lists of e-mail addresses of customers to the highest bidder. It is therefore vital that you supply a spam-blocked or even totally fake e-mail address when you send your query.
Of course, we won't be able to reply to you, but that's OK, because it gives you the chance to send ever more aggrieved e-mails over the next few days complaining at being ignored. For that perfect touch, hide your real e-mail address ROT-13-encoded in your .sig. That way you can send a really patronising e-mail two weeks later along the lines of 'In case you're too stupid to find my e-mail address, it's IN MY SIGNATURE.'
M? What FM?
Manuals used to be things with which to prop up your monitor; these days they tend to be an excuse for the programmer to take a break from programming and get stuck in to some HTML or StrongHelp code. Heaven forbid anyone should actually read them before getting on the blower to the technical support person who these days is likely to be the programmer anyway.
Look at it this way. Time and resources spent answering queries from people who haven't read the manual are time and resources that won't be spent on developing the software. Which means that the software won't acquire lots of exciting new features for you to get confused over and pester the technical support department about. Alternatively, it will push up the price of the upgrade so that you won't be able to afford it and ask lots of questions about it - and let's not forget that the very act of upgrading is fraught with potential for diving in without reading the instructions and making a total mess of your lovingly configured installation.
Users who don't read the manual (or check FAQs on the company's web site, or do a search on DejaNews and Altavista) are just nature's way of keeping a brake on the furious pace of software development.
Call at the first hint of trouble
Technical support people are, by and large, lonely people who live for the joy of talking to you. We want to hear from you the moment you start unpacking the box. There's no point in wasting time hunting around for all the cables, connectors, driver discs and other junk in the packaging. We're waiting for your call. We probably packed the box ourselves and deliberately left out a vital component just so that you'd phone us up or e-mail us for a chat.
Of course, if you have checked the packaging carefully, and there really does seem to be something missing that's on the 'in the box' list, please forget to mention this fact when asking for help. We're psychic, remember?
Hardware problems
Get a SCSI card. They're wonderful items of hardware; there are just so many little things that can go wrong with them:
- Each end of the chain must be terminated.
- Yes, including the card in the computer.
- But not the middle of the chain.
- And not the device that you just removed from the chain.
- And not the card in the computer if it's in the middle of a chain.
- Every device needs a different ID.
- The order of devices in the chain can matter.
- Every device should be switched on, preferably before the computer itself is.
- A new peripheral can hang the system on a Cumana card if block mode's switched on.
This list of problems can keep a technical support person giving you his undivided attention for several days at least. The key is to trigger a second problem in fixing the first. For instance, when changing the ID of a device on the end of a chain, 'accidentally' remove its termination.
While SCSI cards reign supreme in the kingdom of support nightmares, almost any hardware can rise to the occasion when called upon. Take scanners. If you're an impatient sort you can try scanning as soon as you turn the scanner on, and then complain that your scans all come out blue-shifted. Most scanners have a lock to keep the scan head in place during transit. Unfortunately, mosy technical support people know this, and usually suggest it as a solution right away. If you shop around, though, you'll be able to find a scanner with two locks - surely I don't need to spell out what a perfect opportunity that gives for an aggrieved 'Yes, of course I've unlocked the scanner, how dim do you think I am?' reply.
Questions and answers
The conversation between you and the technical support people is, by its nature, a dialogue. But that doesn't mean you should feel compelled to answer according to any particular timetable. There's no Good Friday agreement setting a deadline for technical support e-mails. Take your time. Reply two months later, preferably from a different e-mail address, without quoting the e-mail you're replying to at all.
Sometimes we technical support people will ask you a few questions. Ignore them - you're bound to know more about what's relevant to the problem than we do.
Remember to make your e-mails as free as possible from all rules of grammar, spelling and punctuation. Run-on sentences with no commas or captal letters are a favourite, and how it brightens up our day to sit down and puzzle over where to put the full-stops. Native English speakers might feel that non-native English speakers have a head start in this, but not so. Many have a near perfect grasp of English and are a model of clarity. Besides, all you have to do is go to Babelfish - the translation service at Altavista - and translate your text to German or Portugese and back. It'll be just as mangled.
Above all, ask for things that you know you don't want or can't use. There's nothing guaranteed to make a technical support person go stark raving foam-at-the-mouth mad as an e-mail saying 'Please could you e-mail me X', shortly followed by one saying 'I don't know how to unpack e-mail attachments'. Unless it's a letter which encourages a reply by e-mail to an address that's only checked once every two months.
David Pilling runs the Ovation Pro mailing list, and has been offering free technical support on his products for longer than he dares remember. David Matthewman has never officially worked in technical support but, in his past roles as editor of Acorn User and webmaster for Computer Concepts and Xara, people wanting support seemed to regard him as fair game. They both dread the first person to take this list at face value. Don't let it be you.
David Pilling & David Matthewman
