So after some experience with working with these on both sides of the fence I’ve formed some rather strong-willed opinions on these things. Both good and bad, a lot of common mis-use from users, mis-perceptions from developers and support staff, as well as some other frustrations.
I think all of us have been frustrated by having to wait in call queues. I also think most of us has been frustrated by sending emails to support systems, and waiting days for responses. Trust me when I tell you the frustration goes both ways. I’m on both sides of the fence.
Firstly, I think people need to understand how many emails comes in which are duplicates of existing issues (often logged by the same person). This can be caused by many things, the best thing to note here is that most ticketing systems use a “subject tag” to identify the ticket it’s using. RT for example puts a [uls.co.za #???] string in our tickets. Now consider the following scenarios:
- Subject Cleanup: The act of cleansing the subject. Most users guilty of this don’t realize that email can be processed by automated systems, and that those automated systems may be relying on the subject to remain in tact for some reason.
- New Emails with subject referencing the other ticket: Often I’ll see subjects like “re ticket 1234”, this isn’t good enough for RT to link the tickets automatically, causing a new ticket to be logged.
- New emails with no reference: Often we’ll get emails that are obvious replies, but doesn’t contain message context. For example, one we’ve recently recently was an email with subject “problem” and body “yes” and I also recall some tickets where the subject is simply “thanks” with an empty body.
- Replying to an existing email for a new issue: This also has the potential for causing great chaos. Often one reads emails in the light of the context, and keeping the subject in the back of your head …
- Useless subjects: For examples “phones” or “email” or something. This is NOT a descriptive subject. When under load support staff tends to scan subjects of logged tickets for important things that needs to be dealt with first. Subjects such as “phones” or something equally cryptic is NOT likely to get your issue on the top of that list.
These things are actually general email etiquette, and comes from writing proper letters. I know I used to be hammered on how to write a proper letter, both in Afrikaans and English. I also recall thinking how useless that was at the time seeing that everything is moving towards email. The art of writing letters however teaches you how to think structured. In other words: How do you pick a subject, how to structure paragraphs and how to convey information in a concise manner (an art I suck at – I tend to write essays and then have to trim them back down).
It’s difficult to give advice on how to best approach an issue. However, I can say this, often just phoning isn’t going to get your problem sorted out. The problem here is that unless the technician has the savvy to open a new ticket with your email address as requestor, and actually entering all the information you’re giving him/her over the phone chances are another call is going to come in as soon as you put down the phone totally obliterating the technicians thought process, and if you’re lucky he might context-switch back to your issue. More likely than not (especially for the scatter-brained like myself) your issue is completely forgotten by now. Thus I personally believe that if at all possible, take the time to write an email with the information you deem required and email that. If the technician requires more info he’ll contact you. The other risk is providing too much information, requiring the technician to first sift through relevant and irrelevant information. Not always an easy task.
I think the most crucial thing when logging a ticket is picking a good subject. For example, instead of just saying “phones” one could say “switchboard phone @ company xyz is down” or “switchboard phone @ company xyz is unable to transfer”. This is concise and I can almost promise you you don’t even need to write something in the body. This appears immediately in the list of tickets, it’s easy for technicians to pick out their tickets and they can almost commence work on your issue without even having to open your email.
Picking subjects like “urgent” is absolutely useless, it doesn’t tell us what the issue is about, and we’ve learned from experience that all issues are urgent. However, if you email me a subject with “urgent” stating that you’re unable to receive incoming email you’re very likely to be ignored the next time round you do have an urgent query. Yes, your email may be urgent, but let’s say you’re the technician and next to that you have a ticket that states: “PABX system down, unable to make/receive calls”, or “web server down” or “database corruption on server xyz database abc” – which do you think is more urgent? Your email problem (which is most likely caused by a temporary delay anyway) or the fact that a database that goes corrupt tends to cascade down the corruptness ladder once it gets going?
Other than subjects my other pet peeves are not using the reply and forward buttons correctly. There are two extremes for the reply here – on the one hand there are people that will NEVER use the reply button – they always create a new email, usually with a subject somewhat similar to the email they’re replying on, without copying any of the context they’re replying on. On the other hand you get folks that will always go and dig out an old email and hit reply, and updating the subject line is optional. At this point I’m going to curse at Microsoft. Outlook doesn’t do any kind of half-decent threading display last I checked. Almost every other mail client do. Guess what the usual suspects tends to use. The importance of the reply button is critical, almost all mail clients honor the Message-Id and In-Reply-To email headers (not visible by most mail clients, but used in order to figure out threading). If you don’t reply when you should our threaded displays will start a new thread (which it’s not). If you reply instead of creating a new email your email goes into an existing thread, again incorrectly so.
The rule is really very simple: Always use the reply-all button and not just reply (there is a reason people was added as a Cc on a mail in the first place – they should probably also receive the reply). Use reply if you’re answering or responding to an existing email. Do NOT use reply if you’re starting a new “discussion”. It’s not difficult. Common sense should be more than sufficient to grok this.
Now, recently I’ve started seeing a new trend (or possibly accidental usage). And that is to click forward instead of reply, and then manually re-entering all the email addresses. Not overly serious, just annoying. This mostly just messes with the subject line.
When forwarding messages, please do bother checking the subject. A prime example here is if you receive a bounce and simply forward it – the subject itself is most likely useless, in fact, I’m likely to treat it as a bounce myself and it’s likely going to end up somewhere trashy. In the case of a bounce, it’s all good and well, but please do think a bit, a subject of “mail undeliverable” compared to “unable to send email to abc@def.co.za” is likely to be better received, and in the body you can simply state “when trying to send email to abc@def.co.za I receive the following bounce back: …”. The same goes if you forward something you’ve received from another person.
Keep enough context, but do clean it up. This is related to the whole top-posting vs bottom-posting vs inline posting. I tend to use a combination. I usually have a greeting at the top, then I respond inline in the email, sometimes add a new conclusion paragraph and then my salutation and signature at the bottom. The reason I do this is so that someone that sees my email (without having received the original) can read the newly formed “document” top to bottom like a sane human being. It’s extremely important to clean up the email though. Outlook users tend to spam us with email footers that is approximately ten times longer than the actual content of their email (this goes to the cut buffer never to be returned).
On the topic of footers – yes, they can look nice, but more often than not they only serve to irritate the recipient, especially if you top-post (as most outlook users do). When logging issues with issue trackers – strip them out. They waste space, and seeing that issue loggers often prefer reading the plaintext version it looks like garbage when compared to the html variant. The reason why these footers are irritating when top-posting is because it makes it difficult for the recipient to locate the original email. Why is that important? Well, you may only send one or two emails a day and can remember exactly what you said in each of them – there are some of us that send anywhere upwards of 30 to 50 emails a day. Personally I don’t remember what I said in an email I wrote a minute back, thus when I receive an email I first scan what I wrote in order to joggle the memory before I read your reply. If three quarters or even more of the email is headers and not actual content this becomes difficult.
Now, when everyone follows these extremely basic rules it saves technicians a LOT of time. To give you an idea – I personally spend probably around 45 to 60 minutes a day just sorting through the above few things. This wastes time that could have been spent way better towards actually solving real problems. In normal day-to-day email it’s not as painful because I just tend to read my email top-to-bottom usually but even here it’s preferred to follow the rules. Especially the aesthetics such as maintaining good subjects, cleaning up emails etc. For ticketing systems especially it’s crucial to follow the rules regarding when to reply and when no to reply. Never clean out the subject. Ever. There is most likely a reference tag in the reply you received and removing this will annoy the technicians trying to help you.
If you were asking something on #exim the answer is use :: eg….
somehost::578 : otherhost:25 and so on….