Dan Boland 06 Apr 05

So much of this rings true, you have no idea…

My take on the detailed help form is that with all of its classifications and divisions and permutations, the problem never seems to quite fit any of them.

The flipside is that when you simply e-mail the help department (or person), you can never guarantee a response, and when you get one, often times the support person isn’t helpful anyway (and downright rude, as in the case of Ipswitch).

I chalk it up as a problem with no good solution, though I would always pick a simple e-mail to a lengthy form.

Tony 06 Apr 05

I’ve sent fairly detailed support requests for software only to get back a response that has almost nothing to do with my problem. From a customer experience standpoint, getting no response or a useless response is way worse than having to fill in a form.

kingbenny 06 Apr 05

I guess to some extent expecting the customer to write a descriptive email of the problem is still somewhat “penalizing” them for the developer’s problem though, in that it takes their time and effort. But you may be right, in that it is the best way.

JD McMillan 06 Apr 05

How about a form that starts with a space to explain the problem in your own words, followed by an *optional* section with a few brief questions to classify and narrow the problem.

Richard Bird 06 Apr 05

There is a higher level of problem at the root of this effect. Quality of dialogue, in general, seems to be steadily degrading. I see it in all places - home and office. It is becoming increasingly difficult for too many people to effectively express themselves even at a low level of detail. We’re all available for all communications coming in, but not much goes back out.

This reminds me of one our own tech support staff. I would invest carefully in the documentation of issues via well-formatted, descriptive, and instructional emails. What always came back was his own carefully crafted response, “okey dokey!” - That’s it. No salutation, acknowledgement, conclusion, commitment or signature.

Over time I actually grew fond of this quirky pattern. So, I’ve come to call the lack of detail and clarity in communications, “the okey-dokey effect.”

Back to the problem. I’m sure there are simple ways to get at the heart of a problem in fewer steps by asking a few, well-structured questions… whether in a web-form or in that follow-up email.

Rob 06 Apr 05

Have you ever tried to find the support contact page on eBay to submit and an issue. Next to impossible. Yeah you can look at FAQ’s, but god help you to find an email address or form to fill out.

I have field requests almost daily, and a lot of the time the user has no idea waht the problem is and feels that its your problem to solve for them. They usually don’t provide much detailed info, so you have to pull teeth to get the information you actually need to help them. As another poster had suggested, there really is no good solution, just be patient and easy going.

Chris S 06 Apr 05

I’m more of a fan of the simple email myself and believe the response should match the query.

If someone who is tech savvy sends a question that reflects their understanding of the technology they’re asking about, they should get a clear, direct tech savvy response.

If someone who is clearly not tech savvy sends a question, they should receive a response geared toward their mindset that still doesn’t penalize them for not speaking geek.

I think that goes a long way toward reinforcing the idea that you’re communicating with a human who’s interested in solving the problem…especially when providing help via a medium as potentially impersonal as email.

Beau Hartshorne 06 Apr 05

Joel Spolsky points out that a screenshot can be a really simple way to demonstrate many types of problems. It’s usually pretty easy to tell which browser they’re using, OS, what the URL looks like, if their user name is wrong, and so on.

Perhaps you could encourage your users to send screenshots (via e-mail attachments) that describe their problems? Most of your users should be able to do this, and if not, it’s usually a pretty straightforward process.

jim winstead 06 Apr 05

while i like the idea of requiring little from the user up front, and asking them for the info you need, one thing to recognize is that it takes a lot of care to ask the right questions and to anticipate answers in order to cut down the amount of back-and-forth.

also, one advantage for asking for more structured information up front is that it helps to track root causes of problems. being able to query your bug-tracking system to see what platforms people are having the most problems on is very useful. it can also just be an indication of what platforms people are using. (with the assumption that more reported problems on a platform indicates more use.)

Jason Leister 06 Apr 05

I totally agree with matching the tone and apparent skill level of the customer’s initial contact.

Same thing when you are negotiating with a client-to-be or shaking a prospective client’s hand. You rarely can go wrong by matching what you are given.

Start from where the customer is and, over time, use subsequent communications to help educate them.

Definitely resource intensive, but in my opinion, good business.

bmc 06 Apr 05

Forums.

Forums are great because they allow people to express problem matters in their own words, search in their own words, see if there’s been timely responses, and create a dialogue with the support staff.

Another big benefit is the archive this creates. It’s like dirty documentation.

sloan 06 Apr 05

You are outlining a conversation. A conversation about a technical problem has two elements when successful, a person with a problem and a person with a high enough level of experience and expertise that they can communicate with the person in a way that is helpful. What I mean is, the expert has a pretty clean mental model of how the thing works, what can go wrong with it, and how to fix it. It is only through good communication, really teaching, that the problem gets fixed over the phone. The expert has to teach along the path to fixing the problem because they need to be able to refer to common objects and actions, without jargon.

I heard this from a journalist once, simple minds use big words, in an attempt to explain that the best way to communicate, the clearest way, was to use the simplest words. If you can explain something in simple, non-jargon words, you really understand the subject. Experts cost money though and support is difficult to justify as a line item because the sale is already made! They don’t consider the number of former customers, lost to a bad support experience and that cost.

SU 06 Apr 05

MediaTemple has impressed me with their support/help system, even when the help they offer has been less than supportive. They accept basically a free-text e-mail that enters into their system and is coded with a number. The support technician then posts his/her comments to that entry and you are notified of their responses. Like blogs or Basecamp, you can then add further messages below the technician’s note(s).

Pretty simple.

Emily 06 Apr 05

I like Dreamhost’s form. It’s a combination of a simple email form with only a few pulldowns to deal with.

I especially like the last pulldown: “Please select your general expertise in this area….” I’m guessing this is pretty helpful for both parties.

A screen shot: http://www.emilypetrick.com/stuff/dreamhost_support.jpg

brennen 06 Apr 05

Totally agree with bmc. In fact, forums and knowledgebases serve two key functions: 1) searchable records and 2) community-building.

Possibly this works better for “open source”-type projects, where the whole experience doesn’t need to feel packaged, or you don’t want to give any ol’ user with an answer the power of official tech support (or the power of unhelpful advice).

But people learn in different ways. So giving different troubleshooting options shows you know one size doesn’t fit all.

Brad 06 Apr 05

As a user, I think forums and knowledgebases work well when you’ve got time to figure out a problem on your own. But when you’re trying to meet a deadline and you bump up against a glitch in the software or you can’t figure out how to do something, that’s when you need a helpdesk. One reason why people often don’t take time to adequately explain their problem when they contact a helpdesk is that they’re in a big hurry to get an answer so they can get on with their work.

For these urgent situations, my first preference is telephone support, next preference is simple e-mail, distant third would be a ticketing-based system, and last resort would be to go through a knowledge base or forum.

Darrel 06 Apr 05

it’s not the system, but the people. Is there followup? Is there a real human response? Are they actually trying to help or just reading of the training sheet?

As long as they are keeping the customer in the loop as to what the status of their problem is, the actual technology is irrelevant IMHO.

Brian 06 Apr 05

I worked in tech support for 3 years and there are certain things that are helpful to know right off that bat. O/S and version, browser and version, some basics to get your line of questioning on the right track.

I think a support form would be useful, like mentioned earlier first box is free form text of description and 3-4 dropdowns below are optional but helpful questions. This would eliminate several back and forths and email and get the user on his way a little quicker.

Nothing frustrates me more in email support then question / reply / wait / question / reply / wait just to get going on the problem.

Then there is figuring out the level of knowledge the user has, novice or expert. You don’t want to waste your time asking over simplified questions or asking questions they won’t understand. So maybe one of those dropdowns is what is your level of expertise.

It is very bothersome when the first question asked is an obvious one. Then again those times you dont ask it, it ends up being the issue.

All that to say, freetext and few questions to start.

Brady Joslin 06 Apr 05

I could see value in a form such as this, using Basecamp’s functionality as an example:

1) Goal: What were you trying to accomplish?

ex. Add a new milestone to a project

2) Action: How did you try to accomplish that goal?

ex. Added milestones in Mozilla Calendar

3) Result: What happened?

ex. My milestones were added on my Mozilla Calendar, but not reflected on the web site.

4) General Comments

ex. I really like this product, but I’m confused. Ahhh!

DGiunta 06 Apr 05

In trying to structure a comment to this list, I tried to analyze my own personal habits when I find I’m in need of support. Do I prefer to provide more information in a time of crisis? or less? What do I expect from the support staff when I offer more information? or less? Are there any trends in my own behavior that help discern a best-practice for providing support?

I found that I actually prefer both more and less information depending on what it is that I’m having a problem with. For example, if I feel I have a lot of information about what’s going wrong, but I’m having trouble discerning a solution to the problem, I would rather dump all the information I’ve got in the support person’s lap. This makes me feel like I’m actively participating in finding an answer.

In situations where I don’t know much about why I’m having a problem or what the possible ways of solving it are, I would rather feel as though I’m in good hands. In which case, I’m going to need the support person’s help in figuring out my problem. Whether it’s through a series of automated questions or e-mails that drill down to the answer, or a conversation with a live person, I will need this person (or website, or e-mail, etc.) to take the reigns of the conversation.

In light of this, it seems as though the best method for handling user problems when the users have multiple desired methods of communicating them is to give these users many ways to communicate with the support staff.

We can all speculate as to why some people may desire one method over another, but to only choose one method means you’re leaving anyone who would prefer another method with a less-than-optimal experience.

My .02. Thanks.

Nice Paul 06 Apr 05

I find automated ticketing systems for large companies annoying because they are invariably abused by support staff who close a ticket, sending off one of any number of predetermined emails which roughly fits the criteria of the problem but doesn’t resolve it.

Although support tickets are good in that support staff can read the ticket history, nothing beats a system where you can email or telephone a real person and they see the entire problem through to resolution, possibly over a number of days. In effect they ‘own’ that issue until they have resolved it or found somebody who can. Unfortunately in a large support centre that isn’t always possible.

Benjy 06 Apr 05

Interesting you mention this today, as just hours before I was cursing Earthlink’s support system, which requires numerous selections about a problem. There were some where none of the options quite fit my issue or were not relevant to it, yet I had to pick something to proceed. The answer I received back seemed like it was a form answer based on those rather than an answer to the specific problem I described.

Nathan 06 Apr 05

I like how Apple tries to solve this issue. In the event of a crashes the OS asks you if you would like to send a report which allows for a small message from me.

This provides the tech support with a read out of what the machine experienced and what the person experienced.

Even though I know they probably don’t read all of them I feel like I’ve sent them enough to get my issue resolved.

Jeni 06 Apr 05

I think a good tech support experience depends less on what you use as your gatekeeper and more on who you use to provide the support. I don’t mind filling out a longer form if I know that the guy on the other end is friendly and knowledgable. At the same time, filling out even the simplest form is a hassle if I think that it’s going to end up in a support black hole.

Banks 06 Apr 05

Hands down Less Information First. This does several things for me, namely allowing me to control the flow of support. I can widdle down to the solution since I have the chance to ask the questions.

When I think of Less Information First, I am not thinking of “Broad”. I rarely recieve the call “My Internet is down”, when they are really only using the wrong password to sign on to AOL.

Jim Winstead is absolutley right:
“it takes a lot of care to ask the right questions”. What needs to be realized is that people using their computer, your Web App, whatever, are much more confused than we may even realize. If going out of the way simply means two extra emails, then it is well worth it.

“There may be an initial burst of anxiety for the customer”. I do not think this is so. The burst comes when the App “fails” to work. The strees-releaver is that first email/call back, whatever its contents.

sloan 06 Apr 05

How about, when an application crashes, instead of sending a message to Apple, you get to send the message to the company that built it? THAT would be a good first step in support don’t you think? There is already a mechanism in place to do it right?

eyezberg 06 Apr 05

Same as providing support on a forum.
New users don’t know the words the dev’s use in their app,
so they don’t know how to describe their problem.
And also do not know what to search for.
And the pple trying to help out the newbies do not
understand what the problem is, thus can’t help solving it.
Hard to accomodate both…

Randy 06 Apr 05

Ian, by the looks of your partial screenshots it sure looks like you’ve “borrowed” some UI concepts and structure from Basecamp.

Ian Landsman 06 Apr 05

Hey Randy,

Actually that’s an old screenshot the designer used from a very early version, but I assure you it’s nothing like Basecamp. I wish it were, but alas…

John Nunemaker 06 Apr 05

I personally don’t care whether it is ticket or email. I just want my problem solved. I have found however that the email support seems to resolve my problems more quickly than ticket systems. Event with ticket systems you still have to explain your problem a few times to get on the same page as support and it is a far greater pain to do so.

Stefan Koopmanschap 07 Apr 05

It’s a hard field, support. In my work in supporting phpBB I’ve found that a lot of customers can make their and our experience much better by first trying some things themselves and searching through the documentation already available. A support form with more and sometimes more complicated questions can help in the customer solving the problem themselves without even having to contact support.

The problem is, that you can’t classify all customers as just ‘customer’. There’s those that are tech-savvy, and those that know nothing about anything. So it is always hard to support everyone using a single support mechanism.

A form to fill in should not be long, but imho might contain some more complicated questions. Maybe leave them optional, but still, they should be there. You’ll weed out those who might be able to solve their problem themselves once they see the question. And of course, such a form, should *always* contain a free text field where customers can describe their problem in their own way.

Support will of course always be a hard thing.

Anthony Morales 07 Apr 05

The long forms definitely turn me off. I’m already upset or stressed out by the error, but having to classify the error using someone else’s words is tough. Sometimes the classifications aren’t distinct enough from each other. I’m fairly tech savvy, but I must admit sometimes I’m not sure which button to press in some tech support forms I’ve seen.

On the other hand, e-mail is like sending a message in a bottle out to sea. But if I get a response within a few minutes - even an automated one - that says “We’ve heard your cries for help and we’re coming” then I feel 100% better.

Jamie 07 Apr 05

What about a call center? I realize that this may be cost prohibitive, but most of the time getting on the phone is the best way to get things straight.

mindful_learner 07 Apr 05

I’ve found a screenshot to often be worth a thousand pull-downs. Often, users aren’t knoweldgeable enough to do this using Print Screen. I know that Joel’s FogBugz software now has a gizmo to easily let people take a screenshot and attach it to a bug report. Seems very sensible to me…

David 07 Apr 05

Today’s Dilbert seems especially relevant to the topic at hand:
http://www.dilbert.com/comics/dilbert/archive/dilbert-20050407.html

David 07 Apr 05

P.S. Here’s a real technical support request, in a free form box. See what you think of it…

Horst’s first comment is interacting very poorly with Safari. There is an empty a tag: <a href=”“/>, and Safari doesn’t understand that this means end-of-tag too. So the whole rest of the page is underlined, and a link back to reload the same article.

I tried to put a </a> in my previous post to fix it, but the blog software (despite claiming HTML is allowed) removed it. I believe the only way to fix this, then, is to have an admin edit Horst’s post and remove/fix the incompatible link tag. Or just wait for Tiger to come out with a new Safari :-)

Please fix… the linking even (strangely) affects the comment entry fields. Whenever I click in the Name box, the page is reloaded! I have to use the tab key to even get to type a comment.

Moises Kirsch 07 Apr 05

For a non profit website that I created with some other people we added a link on every page that says “HAve you found a bug” and even to report material that it isn’t proper (it’s an educational website).

When the user clicks on it the script tracks the file and even some variables that we think that might help to fix the problem (if there is one).

It also gives a textarea to let the user explain the problem but imagine if someone is trying to login to Basecamp and for some reason they can’t… if they clicked the link directly from there you could now what page/file/script they are looking at and maybe some extra data such as all the globals on the system, time, etc.

I think this is a very good way of getting some of the needed information to fix the problem.

Waylan 07 Apr 05

I would certainly go for the simple email first. As others have mentioned, in my experience, the problem never seems to fit into any of the listed categories when you are forced to pick from a list. Or maybe it could easily fit to a few depending on how you look at things. If you include such a list with the email, it should not be mandatory. Perhaps one of the list items could be “other” or “not sure” or something like that.

pb 07 Apr 05

I think a ticketing system is way better than email because it gives the customer visibility into the workflow. The one I currently like is DeskPro:
http://www.deskpro.com/

I rarely if ever expect a response from an email sent to support. And certainly never expect the response to be prompt or helpful.

AK 08 Apr 05

I think the problem doesn’t stem from asking the right information, it comes from how it’s handled internally.

I suspect that the majority of the tech support/customer support is provided by a third-party that doesn’t have my or the company’s best interest in mind. They have scripts they need to follow and your answers dictate who will take care of your problem. I don’t know if this third-party notifies the company of these issues.

As a customer I feel like I don’t matter to these giant companies. I have to do all the work myself to remain their customer and my rates keep going up.

If I had a problem, I would like to have the same person or the same group of people work with me. I want them to know my history, my problems, and how we resolved them. I don’t want to have to explain my history every time I have a problem.

How I communicate with them depends on how critical it is. I like email for things that are of low-priority, online chat is great for on the spot questions, online ticketing for something that cannot be pinpointed, and phone calls for times when my business is affected by it.

My favorite “customer support” is my landlord. We email each other on updates of our problems, he will call my cellphone when something important is happening, and he will meet me in person to help diagnose the problem. He then takes care of the issue with plumbers, electricians, and other contractors and fills me in on the progress. It’s the reason I don’t want to move even if there are cheaper/better places around. I feel appreciated as a tenant and I want to remain loyal.

Mr. Negative 08 Apr 05

People are lazy & self-centered, and most of them can’t write very well. How many tech support people have received an irate call or email along the lines of, “The [feature] is broken. Fix it!”

Users do not take the time to communicate where they were going, what they did to trigger the problem (or perceived problem), what their expectation was, what the context of the problem was…

Add to this the inherent frustration of doing tech support (by definition, nothing ever works, you only see the problems), the high frequency of “user-error” (sometimes due to poor design, but usually not) and you’re got an environment where frustration and hostility is the norm.

lcreekmo 08 Apr 05

I had a similar argument with my sister last week in a completely different context. [Major home improvement chain] completely screwed up a job I was having them do for me, except that the job was actually performed correctly. Doesn’t make sense you say? Every step of the job was like nails on a chalkboard — they gave me wrong info, said more than once please come back [15 miles to the store] tomorrow, or no, talk to this person, what she told you isn’t right, etc.

As I explained to my sister [who was willing to excuse many of their missteps], in my very unhumble opinion, the customer is ALWAYS right. Period. If the customer can’t tell you what’s wrong, it’s your fault. If you don’t realize it’s wrong, it’s your fault. If the customer thinks it’s wrong but it’s not….still your fault.

I work in a client relationship role where I have to practice what I preach every day. I’m not a technical person though I am a Web person. I don’t know the answer to making tech support work, but we all have to keep trying. Goal is seamless interaction for customers, and quick resolution of problems, which are hopefully few. But if we start out by saying, “They’re using it wrong….” or “They didn’t fill out the form right….” or “They didn’t [fill in the blank]” we’ll never solve it. We have to start with “We didn’t….” and “We can improve by….”