Customer Support: "information triage"


#1

Well, it happened again! I waited 17 hours for the customer service rep to write back and say “Send more information.”

(I wrote in to report slow FTP and telnet service. I checked the tracert (~15 hops, all < 70 ms), but did not include the tracert in my report. The customer service rep wrote back to say “Send the tracert.”)

I would like to suggest that you use “information triage” on incoming support requests. That is, have someone read every incoming request within a couple of hours or so, and evaluate it not on its substance, but on its information adequacy. If more information is needed, inform the client within a few hours so that the process is not unnecessarily stalled.

I am happy to wait 17 or 24 or 32 hours for a substantive response, when necessary. But to wait 17 hours to begin the resolution process is extremely frustrating.

Hope this idea is interesting to you.

–David B.
“greendavid”


#2

We ARE asked, when we submit a support request, how critical the problem is. My assumption, from the right coast, is that the folks on the wron^H^H^H^H left coast are going to hop on site outages and let less critical problems and suggestions wait if necessary. I certainly hope that’s how they do things.

Triage means to divide into three groups -

  • those which recover, with or without attention.
  • those which are hopeless, with or without attention
  • those cases where you can make a difference

I ran my own traceroute, and it appears that the problem (if you care to define it as one) occurs at Exodus. Since the support staff at Dreamhost doesn’t get to twiddle with Exodus’s system, a proper triage system would ignore your support request until they had everybody else taken care of.

1 17 ms 19 ms 18 ms 10.12.3.1
2 16 ms 15 ms 16 ms F1-0-0.G-RTR1.CAP.verizon-gni.net [141.151.196.66]
3 22 ms 25 ms 24 ms s3-0-0.baltimore1-cr1.bbnplanet.net [4.1.25.225]
4 25 ms 29 ms 26 ms s7-0.washdc3-cr9.bbnplanet.net [4.0.2.53]
5 24 ms 23 ms 25 ms so-3-1-0.washdc3-nbr1.bbnplanet.net [4.24.8.117]
6 26 ms 27 ms 24 ms so-0-0-0.asbnva1-hcr1.bbnplanet.net [4.24.11.250]
7 27 ms 26 ms 26 ms bpr1-so-2-1-0-0.VirginiaEquinix.cw.net [208.173.52.5]
8 28 ms 28 ms 26 ms acr1-loopback.Restonrst.cw.net [206.24.178.61]
9 29 ms 30 ms 29 ms agr3-loopback.Washington.cw.net [206.24.226.103]
10 30 ms 30 ms 29 ms dcr1-so-6-2-0.Washington.cw.net [206.24.238.57]
11 27 ms 28 ms 30 ms cable-and-wireless-internal-isp.Washington.cw.net [206.24.238.26]
12 30 ms 29 ms 30 ms bbr01-g8-0.stng01.exodus.net [216.33.99.81]
13 66 ms 67 ms * bbr01-p4-0.atln01.exodus.net [216.32.132.177]
14 67 ms 67 ms 67 ms bbr02-g2-0.atln01.exodus.net [216.35.162.4]
15 83 ms 85 ms 83 ms bbr01-p7-0.ftwo01.exodus.net [209.1.169.21]
16 85 ms 84 ms 83 ms bbr02-g6-0.ftwo01.exodus.net [216.39.64.18]
17 115 ms 114 ms 113 ms bbr01-p4-0.irvn02.exodus.net [209.1.169.9]
18 113 ms 118 ms 116 ms bbr02-g6-0.irvn02.exodus.net [216.39.96.18]
19 116 ms 116 ms 115 ms bbr02-p1-0.elsg01.exodus.net [206.79.9.233]
20 115 ms 114 ms 113 ms dcr01-g6-0.elsg01.exodus.net [216.34.192.1]
21 116 ms 115 ms 115 ms csr11-ve240.elsg01.exodus.net [216.34.192.218]
22 113 ms 123 ms * 64.70.8.30
23 117 ms 117 ms 117 ms discussion.dreamhost.com [64.70.42.60]


#3

Dear Deke,

  1. Reference this announcement from DreamHost dated 2002-08-16 11:15:43:
We have been experiencing some system-wide server slowdowns this morning starting around 9am PST and have been working to stabilize things. This slowdown has affected email, webmail, and the web panel intermittently. The webpanel and webmail are running smoothly once again, but there is still some email slowdown. We are working to resolve the remaining issues. We will be analyzing this situation to determine the best course of action to prevent it from happening in the future.

DreamHost Fixit Team

I thought it perfectly appropriate, even helpful, to mention that a similar problem was occurring.

  1. My tracert showed 15 hops, all times < 70 ms, meaning there was a problem (perhaps a recurring problem) at the server.

  2. My suggestion has nothing to do with how important or un-important my support request is. I am suggesting that each incoming request be vetted for informational completeness and that incomplete requests generate an immediate response, asking for complete information. This could save an immense amount of time.

From the left coast,

–David B.
“greendavid”


#4

That just doesn’t many any sense. What you’re basically asking is for every support request to be read – twice! Once when they come in to be manually veted and categorized and or acted upon, and then once again when someone actually deals with the support request.

Phewks. That sounds like a good waste of resources to me. Providing a big bolded, underlined, font size 10 message next to the submit support ticket button advising folks to enter as much information as they possible can would be a far better use of existing resources.

. o 0 ( Have you noticed that you can now have a member of support staff call you back on your telephone in the US? :slight_smile: ) .

  • wil

#5

Dear Wil,

I understand your point, of course. Reading a message twice does add overhead to the support process. Also, I am not familiar with the actual process by which support requests are handled, nor with the load on the support staff, so I may be missing something. In fact, I’m quite certain I am deluded about both the need and the possibility of improving the customer support system.

DreamHost does a great job, and the need for support is in fact quite minimal. But for certain urgent or complex requests, the effeciency of the support response mechanism could be improved.

As far as I can tell, there are at present three “dimensions” of priority for a given request: 1) the age of the case (though from the client side we do not have this information; 2) the age of the latest message; and, 3) the priority given to the message by the client.

I am suggesting that an additional dimension (that of “informational completeness”) would increase the efficiency of the system. It makes no sense to have a useless, incomplete request sit in the queue for 17 hours only to have the support rep handle it in 30 seconds by asking for more information. Those requests that can be handled in a minute or less should be handled first.

Unfortunately, the only way to know this is to have someone read the request when it comes in, and this obviously intereferes with the way the system is currently configured.

Perhaps I am the only person who has had this problem, and maybe that means I am either ignorant or impatient or both. I will try to learn more and calm down.

–David B.
“greendavid”


#6

I honestly don’t see a way to solve this other than support staff read each message as they come in to manually check them. And to know that all the required information is there, this will sometime mean having a to dulge into the mentioned problem to see what information is required. This takes even more time.

It’s simply not practical.

I believe Dreamhost are currently testing telephone support, and Dreamservers already come with telephone or priority email support (someone correct me here if I’m wrong). So what you’re basically asking for is your question to be read faster and acted upon faster, which will inevitably mean moving up your service plan.

I have to stress that there is and there damn right should be an element of responisiblity on the user, here. I am guilty of this many times previously where I see a problem and I think it’s an urgent problem so just scribble away a message to support and hit the submit button. If everyone took the time to re-read their messages and think of how someone else will interperte them then I’m sure we could help to bring the support staff’s workload down by doing our part.

And this, I believe needs to be stressed a little more in the submit request form or somewhere.

Just my 2 euros …

  • wil

#7

I think you’re right. It’s basically a question of moving up my service plan.

I’ll look into it.

Thanks for the direction!

–David B.
"greendavid’


#8

Well, maybe I’d hold my horses if I was you. How many times has this happened to you? And how much of the blame was on yourself for not providing the right information in the first place? :slight_smile:

Wait to see what happens with their telephone call back service. I believe you can try it out now from your web panel.

  • wil

#9

I think my problem is that I’m at the “knows-enough-about-Unix-to-be-dangerous” stage. I can sense the possibilities, but I do not grasp the implications.

I don’t want tech support to hold my hand every step of the way, but I guess I would like opportunity to engage in a dialogue with people who know more than me (which would be just about everybody, at this point).

My previous host (though lame in other ways) had a threaded support system that enabled such a dialogue. Their response time was not much shorter than DreamHost’s, but it was much more possible to have a coherent back-and-forth discussion. They were much smaller, though, and I can certainly understand that at DreamHost’s scale, individual dialogue is not likely to be the primary mode of operation.

However, you have pointed me toward the DreamServers, which include phone and priority e-mail support. When I can afford it, I’ll be going that way.

Thanks again!

–David B.
“greendavid”


#10

I have thought about the “triage” idea as well; I believe I’ve even suggested it to our developers.

I’m not sure how feasible it is at this point in time, but I suspect something like this will eventually become necessary. Depending on the nature of your question, I don’t think individual dialogue is unlikely with our system - especially if your question is routed to an individual person’s queue.

If there’s someone who is helpful, you can always request a followup from that person; it just may take a little longer depending on who the person is.


#11

Just a note - this slowdown had nothing to do with the web machines, nor did it have to do with network problems (so the tracert is irrelevant).

The slowdown only affected central services like webmail, the web panel, and customer email.

If you have an issue like this again, note the load (“uptime”) on the server at the time of the problem.


#12

Dear Will,

Thank you for your reply, for the information about the slowdown, and for your consideration of the “triage” idea.

Best regards,

–David B.
“greendavid”


#13

This thread might be a little cold, I’m just killing time at the end of a long day.

The full time TS people generally answer the oldest questions, usually weighting older threads even if the most recent message isn’t that old.

For most TS questions, a majority of the time spent is just in reading the question and getting a handle on the user’s situation. A person checking for information completeness would have to do the same thing. Basically, by the time you know that all the info is there, you can answer the question.

We don’t really have the staff to have someone doing that full time. You would also be surprised how little it happens. We can answer probably 70% of TS questions without having to ask for information first.

TS here is a hard job. The support people are all really smart and know their stuff. Giving them really boring duties would be crummy. Generally, the less repetitive a task, the more interested a smart person is. We like to keep their jobs as interesting as possible.

If there’s anything we could do, it’s improve TS people’s information-gathering resources so they’re faster, more complete, and more clear. It can take some time to really investigate somebody’s account to find problems. DreamHost’s backend is extremely complicated, and we tend to work on tools that are visible to the user before we improve internal ones.

I can say that, on personal level, the best way to make sure your message is NOT read is to use all caps in the subject, sound angry, and ask things like “WHY IS MY SERVER DOWN?!!?!?” I will never, ever write to you if you do this.

Then again, it’s probably a good thing I’m a developer and not a support person.

Nate.


#14

I could post some threads from support conversations here that have a real Beckett feel to them (Waiting for Godot) springs to mind.
Day 1
me> can i have u uncompress a zipped mysql dump file there…the file is

[quote]about 12mb but 3mb zipped…i’m on a 56 modem so have mercy! also i
have the option of to tar… please advise.
[/quote]

Day 2
support: I’m sorry, but I wasn’t able to find the file in question. Could you please let us know where it’s at and we’ll be happy to take care of it for you.

…I hadn’t uploaded the file yet! So i did & contacted support.
This is a typical misunderstanding I meant was it possible - support presumed it was there. Support waste time looking for non-existent file.
Day 3
support> I was able to unzipthe fle for you, but you’ll need to import it into SQL yourself. Sorry about that. If you need anything else, please let us know.
…This could have been a good time to tell me I could remotely unzip easily…its the old teach a man to fish routine…hohum

Day 4 - spent about 6 hours trying to figure out why ‘load data infile’ wouldn’t work - contacted support

Day 5 - get terse (but entirely correct) reply - spend hours trying to figure out what support reply meant

Late day 5 - woohoo it works
So thats 5 days of wasted time on a conversation that would take maybe 10 minutes.

How about booking live support slots? Give us a couple a month charge us for the rest if u like…it could actually save resources…I think 3 different ppl got involved in my minor query…perhaps dedicate 1 junior person to checking incoming requests & dealing with minor ones asap. If its complicated a short note saying that its being passed on to a Happy Dreamhost Genius! & will be dealt with asap would reassure the customer. The illusion of action would be at least reassuring. This would also ensure that your super brainy support team don’t get bogged down with questions they believe are way below them. U can promote your junior support person when the endless mundane queries get too much:)