The Vague Email
Feature XYZ isn’t working. Please fix.
Provides next to no information other than at some point, a feature — possibly XYZ — didn’t function the way a specific user expected it to. Issue could be anything ranging from a catastrophic system failure to a simple misunderstanding on the part of the user. Usually requires a series of follow-up emails, phone calls, and conferences in order to clarify the problem at hand.
The End of the World Email
URGENT!!! System is down! NONE of our users can do XYZ! Please advise!!!11!
Usually flagged as important in Outlook and CC’ed to everyone in the user’s contact list. Grossly overstates the magnitude of the problem either to guarantee an expedited fix or simply because the user would rather yell at someone rather than bother checking. Rarely turns out to be as terrible as originally advertised. Unfortunately, that still won’t save you from having to put out all the fires the email started.
The Red Herring Email
Can you check if XYZ is working?
Actual problem winds up being completely unrelated to XYZ. Unfortunately, you won’t find that out until after you’ve spent several hours poring over code trying to envision the perfect storm of events that would have triggered a failure in XYZ.
The Ideal Email
When I do XYZ, ABC happens. I expected DEF to happen instead. Here are some screenshots showing what happened.
Clear, concise, and doesn’t make any assumptions about the issue at hand. Gives enough information for a programmer to at least approach the problem and is oftentimes sufficient without any additional follow-up. These are rare and far between, yet the amount of effort to type them up isn’t much more than any of the three other types of emails. Wouldn’t life be a lot simpler if all emails came in this format?
Great post. Other good info would be: date/time of issue, who found it, and if it consistently happens.
You forgot one: the email that is completely irrelevant to anything you’re doing. This is by far the most common kind of email I get.
Couldn’t help but smile reading your article.
I know these types of emails just too well,
although I think the last one is a myth
Regards,
Sascha
so true. what do you think people can do to encourage people to send more Ideal Emails? you’d love to just throw back the other kinds, saying “please send more info,” but i don’t think that’ll go over too well. also, i suspect a big cause of non-Ideal Emails is not just time people are willing to spend typing out emails, but knowledge. programming is just “magic” to most people, so they have no idea how to help a developer track down a bug. maybe we can encourage training regarding how to send “i found a bug!!1!” emails.
I’ve found there are a couple ways to remedy this problem. Neither are 100% effective, but every little bit helps:
1. When dealing with users you interact with frequently, try to be as consistent as possible when responding to them. If they never remember to tell you what they expected to happen, ask them. Eventually, they will catch on and start incorporating them into their initial e-mails to you. After all, they’re not interested in wasting time any more than you are.
2. When dealing with new users, a “Contact” form that essentially follows the template in #4 will help. A blank “Contact” form invites all sorts of crazy requests, but if you structure it in a way that asks for relevant information (don’t make it too fine grained, otherwise it’ll put off users), you should see better responses in your inbox.
You mean you’ve actually received #4? Incredible.
Jason Baker, with that look on your face I’m just going to go ahead and assume that people are asking you about projects you’ve been assigned for months but you just don’t remember it.
This made me laugh.
Don’t you mean the *3* types? That fourth one is just a theoretical novelty, isn’t it?
Poring != Pouring
Oops! Thanks for catching that. Fixed now.
On my internal app, I think I am going to try to explicitly ask for the items in #4 on my error page and see what I get… Couldn’t hurt to tell the users exactly what I want instead of just a there was an error message.
That was my first thought – I’ve gotten the first 3, never saw number 4.
Although, I’d add the email you get FROM programmers. You send a clear, concise email stating that you’ve tried ABC, DEF, and GHI as per their posted instructions in the FAQ and they reply saying \try ABC\. You reply saying you did and that you also tried DEF and GHI. They reply saying \try DEF\. That’s when I generally lose it.
Big +1 on that one.. but not from programmers specifically – any sort of “support” that does that drives me wild. *cough* ebay, twitter
You’ve probably read this already, but I’m obligated to link to “Asking Questions the Smart Way”, ESR’s extended essay on this topic. Pointing your bug reporters at this article is a good way to start getting more category 4 emails.
http://catb.org/~esr/faqs/smart-questions.html
If your bug reporters are internal employees where you work it sounds like a great way to be dismissed as “that unhelpful guy who sent me a link to a really long webpage every time I asked him to fix his busted-ass crap”.
The most common email I get, at least after a meeting where everyone has signed off the development priorities, is “I forgot to bring up issue X during the meeting, so that means priority Y is the most important. Please work on it and don’t bother other employees by telling them this.” This is sent by every member of the meeting, where Y is replaced that person’s priority.
I am with Kevin Pang; if your communication looks like #1 – #3, then maybe you are not the best communicator yourself. As he states: keep consistently asking for the details you are looking for, and they will start appearing. YES absolutely users are a pain and give cryptic messages full of information holes, but if you keep getting the same mails over and over, consider educating your users in how to best help you help them.
As a programmer, I always send email type #4 when I contact a company about problem XYZ. It usually reads like this, “Dear Company, I was on the login page of your web site on Thursday morning. I clicked the submit button and the screen did not post to the next page. I tried this in IE6 and Firefox 3.6 and I got the same result. My account is paid through next December. I went to three other pages on your web site and the forms on those pages work fine so I believe that this issue is specific to the login page.”
The response I get is, “Are you sure you’re connected to the Internet? Did you try Firefox? Do you have an account?”
So there’s really no incentive for the use to take the time to write email type #4. By your own acknowledgment, it makes more sense for them to send The End of the World Email because that one actually gets results.
I would hope that most programmers would be appreciative of a #4 e-mail and respond accordingly, but you’re right in that a few rotten apples can spoil the bunch.
Great post, but one point, this:
I find it’s important to understand WHY there was a misunderstanding. Perhaps there is a problem with the UI, help documents, etc., even if the functionality is working as expected and designed.
Point well taken. I didn’t mean to imply that “misunderstanding on the part of the user” was entirely the user’s fault. I agree that UI / documentation is often the actual problem. Still, that fact doesn’t absolve the user from submitting a coherent e-mail when reporting the issue.
This is what you use a bugtracker for :> You’ll find a bugtracker asks all the pertinent questions needed to be asked to identify a problem. Humorous article :>
At my current place of employment I have received one (yes one) ideal email. I literally celebrated, running around to my other coworkers in disbelief! I loved your article!
At least these mails all point out that it is abouy XYZ. I get these far more often:
“omg the site doesn’t let me post”, possibly with insults added. And there happen to be at least a dozen different kinds of “posts” on that site.
Somehow the sentence “the site doesn’t let me xx” seems to return a lot. That always makes me envision the website as some kind of monster with a giant hammer, slamming users backwards if they try to post a comment.
Reply from a user: I am a user who tends to use more combinations of software than most at my company, so I get more than my share of problems. I have enough of these to know what sort of information might be useful, at least some if it. Unfortunately, most of the time my explanation of problem XYZ, what was going on at the time, and recent changes to the system, almost always get a middle of the night phone message saying “I understand you are having a problem with ABC. Please call 1-800-generic number”.
Hehe. I love the end of the world emails. Those are my favorite
On a stylistic note, I really dislike the entire message is in the subject line email. How am I supposed to reply?
My solution? I change the subject, copy and paste original subject into body of message and reply. People don’t always like it because it messes up their threading. Too bad =P
So true, all of it.
“Please advise” – this phrase makes my blood boil
The problem here is not the programmer, but the middle-man customer support person who actually knows nothing but the rote responses of what to try. If the email had in fact been received by a real programmer I believe you would have received an appropriate response.
This was in response to Eric’s post above but somehow the reply didn’t get associated with the original post. User error I am sure.
Well, here’s the thing– the end user doesn’t always know the in, out and other of your programming.
I like to send email type #4 when I have enough detail to do so, but, often I just don’t know what steps of X–>Y–>Z our programmer has taken or will need to fix it.
Is it better to send an info bomb or an “ummm.. it’s broken..” type of email to get optimal results?
I’d say when in doubt, err on the side of more information. You don’t necessarily need to tell a programmer exactly what’s wrong with the system. That’s difficult, if not impossible, without knowing how the system works. What programmers really would like is if users could accurately describe what they’re seeing on their screens and what they think should be happening instead of what actually is happening.
Actually the time taken to write “the Ideal email” is actually greater than the rest, as it actually involves “logical thinking” about the problem based on the facts of the situation in which it occurred. Its easy to fire off an email which is based on the emotion at the time ie. Annoyance/Frustration, but its harder to actually look past the initial feeling and actually type something that is useful to the recipient.
Logically though, a good description based on actual facts may take time initially, but in the long run it saves time when you don’t need follow up emails, unwarranted patches and heated debates.
Man, I almost never get the Ideal Email, but it sure is refreshing when you do. Most often I get something along the lines of the first one…
On #4, you misspelled the word “Imaginary”.
And I agree with Eric. I too have sent detailed bug reports to companies and gotten back the kind of thing he describes. There are only so many pearls I’ll cast before swine before I just plain give up on writing Ideal E-mails.
Build the information provided in example four into your error handlers. It’s easier to do with some systems than others, but now that my team has done so, we waste a lot less time dealing with users or matching up issues with error reports.
You forgot this one….
“When I click on “Do Test Parse” I get an error saying “You have not specified an output folder to place your parsed files. This can be done via the Tools > Settings menu” – What does that mean, can you fix it?”
Gee, I wonder….
I’m a big believer in sending email #4. I’ve been on several sides of these problem – the programmer, help desk, employee, manager, CIO.
A user once wrote to an employee of mine,
“I received a message telling me that changes required
me to close and reopen the application. What should I do?”
My employee responded,
“Apologize”
Email is a lousy medium to convey technical issues. Avoid it whenever possible. Nothing beats a face to face chat in this circumstance.
your users know how to make a screenshot? wow!
My tech lead does the end of the world thing all the time. It’s his technique of trying to get his requests serviced first. You don’t want to completely ignore them in the off chance that they are important, though that also means non-critical ones are labeled as world-ending ones. Is there a way to correctly respond to these types of emails? and how do you distinguish them apart?
Actually, you don’t. You and your co-workers will get more and more used to his alertness and will pay less and less attention to them. Until one day, there will be one world-ending issue that will not be corrected in time and someone will get fired. You just can hope that the boss of your boss will agree with you, that your boss asked for it, as making EVERY mail an end-of-the-world one.
I agree with Eric. I advice to stimulate the users to use #4 more often. They don’t have a clue. As u user with some technical skill I use the #4 mail when needed (I try to fix it myself first) and usually I don’t get any different response other than that the problem is probably solved faster. Ofcourse this is a good incentive, but I advice to educate the users a little.
Actually, the majority of emails I receive are of the type “grow 3 inches right now!”
i wish! in reality, this is more common:
… and when you check, everything seems to work fine. then you call the customer, and it turns out there’s a broken image link on the imprint-page because the user decided to upload underexposed 3000x2000px photos again (even though you told him last week he shouldn’t do that).
Hilarious!
The best applications engineer I’ve ever worked with would do this when he encountered a bug:
1. Spend time trying to reproduce the bug. Failing that he would at least provide context.
2. If the bug was reproducible he’d write a detailed description of how to reproduce the bug. This description included the version(s) of software that exhibited the bug.
3. Attach any relevant log files, screen shots or input files.
4. Made himself available for consultation.
And what about an email with a *screenshot of the logs*?
I guess is something between “The Ideal Email” and “I Read Logs With Word”.
If you get emails your project probably doesn’t qualify for a real service desk like system. If that’s the case, pity on you.
Most used key on my keyboard is the delete key. If it’s not in the bug tracking system, it does not exist and it does not concern me.
End of story. Building systems is too costly to waste time on vague reports.