A theory on why users keep mailing specific people

June 29, 2009

Like many places, we have several generic aliases that users mail about various issues. And, just like I expect happens everywhere, every so often users don't use those aliases and instead email some specific person here with their issue.

I recently came up with a theory for why this happens: it's easier to remember people (and then their email address) than it is to remember something impersonal. So people remember 'oh, I dealt with <X> last time to fix this', and they don't necessarily remember 'oh, I'm supposed to mail this random address'. And <X> gets more email.

(I am theorizing about this, but we know that humans have a fair amount of brainpower that's devoted to paying attention to other people (and we anthropomorphize like crazy), so it seems at least reasonable.)

Sysadmins may not see this as reasonable, but then I've got to point out that as successful sysadmins we are basically required to be good at memorizing computer-related trivia. Of course we can easily remember various abstract email addresses and keep them straight; we spend all day doing similar things, and we see the email addresses a lot more than the typical person does to boot so they're more familiar to us.

Unfortunately, I can't think of anything useful to do with this theory. It does make me wonder if anyone has experimented with deliberately anthropomorphizing their generic aliases and support systems, and if so if it did any good.

Comments on this page:

From at 2009-06-29 04:31:47:

In my experience, it's not that they don't remember the common aliases or avenues for support. They believe that by addressing a single human contact that they will bypass the tedium of queueing in a system and awaiting a dispatcher. Especially if the previous contact happens to be of better technical ability than the dispatcher and first line.

From at 2009-06-29 09:07:22:

I agree with the previous comment. In my experience, users send mail to specific support staff because they think it will get quicker attention or they want to avoid working with a specific person. What I've done to break this habit is to sit on things for two or three days and then add the ticket in. When I reply to them, I point out that they'd get a faster reply if they sent their mail to the correct address. It took a bit, but this is no longer an issue for us.

From at 2009-06-29 10:00:10:

Ditto the above.

It can be further re-enforced by explaining (or simulating, as you say!) an out-of-office scenario. If a user contacts me directly and I was out of the office, on business or vacation, then they might have to wait several days before they receive a reply. If colleague does eventually pick it up on my behalf then they might not have all of the information required because the user has bypassed the support process previously.

The net result is that it takes longer and longer for their ticket to be resolved. Everyone likes fast resolutions. Eventually they are persuaded to use the system like everyone else.

From at 2009-06-29 10:43:49:

I think users prefer to send requests for help directly to a specific person because not unreasonably they want to receive attention as soon as possible. There is a real sense that even without receiving a reply, sending an email to one person is already to have their attention, particularly when one has had previous communications.

Breaking that dependency by purposefully delaying a reply for two or three days works at the cost of being rude.

David Buxton

From at 2009-06-29 13:54:00:

Dear Purdue colleague at,

I wholeheartedly agree with David Buxton in his characterization of deliberate delays as rude. I would go even further and call it unprofessional and unfitting for office. The job of support people to resolve user requests as quickly and completely as possible. That's part of the job description. Any artificial delays are sabotaging your users and directly contradict this description. We have to remember that support exists for users, not the other way around. Making a point of self-importance by deliberately inflicting inconvenience on users (and by interfering with their job duties which they can not fulfill because some hotshot decided to ignore an urgent request for couple days just because he wanted to teach them wheenies a lesson) is definitely not a way to go...

Explaining the out-of-office scenario is perfectly fine by all means. But actually simulating it is just plain nasty on my book (if anything like this happened to me, I would've felt insulted and violated - and I would've complained to the insulter's supervisor with request of severe reprimands). Your users are not one year-olds, they are intelligent human beings capable of understanding rational explanations. And that's exactly why explanations work a lot better than silent sabotage. Which, among other things, means that you reach your end goal (teach users to use special addresses instead of personal ones) a lot faster.

Lev Gorenstein

By rdump at 2009-06-29 15:55:28:

@Lev Gorenstein

I think the large amount of emotion, pejorative terminology, use of [em] tags, and misdescribed motivation you pack into your description of actions taken by others ("making a point of self-importance", "teach them weenies a lesson", and so forth) shows what I can most charitably characterize as an overly healthy dollop of hubris on your part.

Helping users understand how best to get their problems resolved is an essential part of making things work smoothly for them in the long term.

If support staff had more budget, then yes, your absolutist "solve the problem no matter how" could work. The problem with that, however, is overhead rates would go up to make that budget room. The users I've talked to around here would much rather keep their project money, and meet support needs half-way with doing their part to make efficient requests.

Moving on, of course users are human (and there's no need to talk pejoratively about one year-olds). This means some learn by being told, others learn by seeing, and still others learn by doing.

There is nothing wrong, and in fact much right when helping the latter class of users, in ensuring that they actually practice sending support requests to the right place for most efficient action.

Towards that end, carefully selecting a misaddressed support request, and using it as a training example while staff is on hand, is a crucial technique for helping ensure that the truly urgent requests aren't left to languish in the future while a misaddressed individual target is on vacation.

Explaining it alone will not suffice in practice. To make it work efficiently, the users need to be reached other ways. Standing on a high horse and so badly misattributing the motivations for such training, the way you've done, does us all a disservice, and certainly doesn't help the users.

From at 2009-06-29 17:18:17:

Oh, Lev. With all due respect..

Let's just remind ourselves that the most common repeat occurance of this event is users bypassing the processes laid out for the delivery of support with the intention of having their request dealt with before everyone else. Now why should such people be dealt with expediently? Why do you assume that your time is more important than my own or the other people that I deal with?

Everyone in IT works a system of prioritisation. As a Computational Chemist I'm sure you will understand. My work, like a lot of other people's, is weighted largely by the source of data coming in and additional processing required to turn it around. Unfiltered email directly to my inbox that requires me to re-ticket often falls towards the back of that list.

Now what your Perdue colleague said was I beleive done so with a hint of humour. But still there is an inch of truth in it. In an ideal world people would listen and understand, yet frankly they don't. If each time such a request is received you say "please don't so this" but action immediately, then what is the incentive for them to behave differently next time? They achieved exactly what they wanted by having their request resolved quickly. This is how humans work.

From at 2009-06-29 20:59:52:

@ (oh, I wish you left a name to use in salutation... I hate to address people by dotted quads ;-)

I have to disagree with you on couple points. First of all, I don't think that the mistake is caused by the desire to speed up my request at the expense of other people requests (quote: "the most common repeat occurance of this event is users bypassing the processes laid out for the delivery of support with the intention of having their request dealt with before everyone else"). This is not the case in my experience (and I've been on both user side and support side of things).

Think about it - I (as a user) know that you will deal with my request in the order it was received, because you have other duties and other users to support. By contacting you directly I'm not trying to get unfair advantage (because I know that you will not give it to me). No, all I'm trying to do it to convey my request to you, my support contact - and all I'm asking is to deal with it when you can. If this "you can" is immediately - great. If it is in a week - ok. The key point for the user is to know know that you will attend to it at your true earliest convenience (as opposed to "at the convenience plus 2 days just to teach user a lesson").

You see, as a Joe-user I consider that special support address as just another address of yours - and so it feels more natural to me to email a more "personal" recipient, rather than some robotic xxxx-yyy-support@... (especially if you have ever replied to support alias from your regular e-mail ;-). Again, it doesn't necessarily occur to many users that using the support alias is more convenient for you (ticketing, request accounting, delegations and such), and it occurs to even less users that using the alias is also more convenient for them too (out-of-office situations, etc.) And this is exactly why I insist on what I said in my first comment - informing the user about incorrect address is perfectly fine, bouncing his e-mail to the ticketing alias (at the end of the queue, of course) is perfectly fine, but purposefully delaying his request just because of incorrect address is rude and unprofessional.

The other side of things is that: a) users tend to remember human names better than robotic names, b) if in the past you didn't have support alias, and now you do, it'll take a while to reeducate your users to a new way (old habits die hard), and c) the period of re-educating may seem like a very repetitive eternity to you (you've worked hard to set up the alias and ticketing system, you've announced this on mailing list, printed memo and support web site, and yet here comes another moron who didn't pay attention to any announcements and sends you his request directly ;-).

The b) and c) combined are actually quite an issue - after explaining twenty times to twenty different people it seems that everybody should have gotten it by now... but they don't. And number 21 comes in and has no knowledge of your conversations with numbers 1-20 ;-).

Secondly, your other point ("In an ideal world people would listen and understand, yet frankly they don't. If each time such a request is received you say 'please don't so this' but action immediately, then what is the incentive for them to behave differently next time?"). Well, who said a word about acting immediately? ;-). I never implied that. I understand prioritizing, I too have to do it in both of my user and admin roles. Quite the contrary, you don't act on private request immediately, but rather you act exactly as if it was just added to the ticketing system via regular route(yes, you would have to push the 'bounce' button and re-ticket... but that's hardly an effort). By any means, no undeserved bumping up - but also no artificial bumping down (as my Purdue colleague suggested).

I have experienced all of the above on my own skin on both sides of the barricades. My point is that we have to remember that support is there for users. And in all fairness that support alias is indeed just another address of ours (and I'm sure you'll agree that most of its behind-the-curtain features tracking are there for our convenience, not user's). Thus we should give users the benefit of the doubt and resend "direct submissions" to the ticketing queue without delays. Nothing more, nothing less.

Lev Gorenstein

By cks at 2009-06-30 00:50:15:

My further views don't fit within the comfortable margins of a comment so I've made them into a new entry, WhyPeopleMailPeopleII.

From at 2009-06-30 10:51:39:

Lev, calm down. First of all, I never said anything about urgent requests. Those get handled immediately, even if it means I have to drag myself out of bed at 2 AM. Secondly, I know what my job is. I'm not deluded enough to think the users are there for my existence, but there has to be a little bit of give on both sides. If support requests are coming directly to individuals instead of the group, it makes it harder to balance my staff's workload.

Also, there's more to support than answering tickets. Sometimes the work I'm doing on a critical server is more important than answering a question that is already answered on our website. The latter may or may impact the work of a single person, the former could impact the work of the entire department.

I agree that frequently imposing artificial delays is unprofessional. Unfortunately, it is sometimes necessary to take a heavy-handed approach. It's a short term loss for a longer term gain. After all, the easier it is for the support staff to do their jobs, the better supported the users will be.

From at 2009-06-30 20:26:18:

@ Quote: "Also, there's more to support than answering tickets. Sometimes the work I'm doing on a critical server is more important than answering a question that is already answered on our website"

Of course it is more important, I'm not arguing with that. But in the context of our disagreement (you thinking it's ok to be "heavy-handed" on users and purposefully delay action on their requests just because they sent it to the wrong address, and me strongly opposing to this), this argument is not relevant. Firstly, because I never said that personal request should be given any preference compared to identical ticketed request, and secondly, because when you are working on a critical server, you wouldn't answer the silly question anyway (no matter how it got to you) until you finish.

I fail to see how imposing artificial delays (be that frequently, as you wrote initially, or infrequently, as you corrected later) is "sometimes necessary". No matter when and how, but from the user's standpoint such behavior would always be perceived as arrogance, and thus would not help meeting halfway. User would think "Well, these guys just treated me like dirt - why should I ever bother making their life easier?"

Written on 29 June 2009.
« How we solve the multiuser PHP problem
More on why users keep mailing specific people »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Mon Jun 29 02:19:43 2009
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.