4

I've seen various questions proposed for soliciting feedback on incident resolution. Examples include:

  1. Did we fix your issue?
  2. Were you happy with the service we provided?
  3. Did this resolution help?

In the context of Help Desk feedback, which probably provides the best indicator of overall quality of service?

I would tend toward #1, but that is partially answered by how often users re-open the ticket (using a ticket survey makes this more reliably though, because this helps avoid them creating duplicate requests for an unsolved issue).

Number 2 is a good overall happiness metric, since few users will be pleased by a wrong answer, and a right answer delivered unpleasantly is still something that needs to be addressed.

The last covers the common cases where you direct users to the correct department (IT can't fix your payroll issue, but HR can at x123). It was helpful, but did not fix their problem. But it also seems a wishy-washy question.

Can someone point me to any literature on the subject of one-question Help Desk metrics?

3

I think the question you may ask yourself is does a closed-ended question provide you with the information you are wanting to know. The options you are presenting are YES and NO.

Often the answers aren't so black and white. YES my issue was fixed, but not another issue that I had at the time. NO my issue wasn't fixed because after it was "resolved" it happened again.

You may want to ask more open-ended questions to allow the respondent to give those details that could be important to you. A great video you may want to watch on YouTube from UX Mastery is Better User Research Through Surveys. If you are looking for literature on the subject they also have books. I'm not affiliated with them, but I have personally used their books and videos before.

  • Welcome to the site, @saylormic! How would you aggregate such free-text responses into a trackable metric to show whether the help desk is getting better or worse over time? – Graham Herrli Jul 23 '15 at 18:31
  • +1 for pointing out 'yes vs. no' isn't much of a metric. :) – DA01 Jul 23 '15 at 19:43
  • We have a separate survey that allows for more nuanced feedback sent out to a sampling of users. This is a feedback link included in the solution email. Answering this survey requires 5 seconds of investment or less, meaning we get a much higher percentage of users who respond. – Myrddin Emrys Jul 23 '15 at 23:11
0

To clarify the question, you're asking what follow-up is best for a user who has now received an answer to a question.

The tone depends on the general tone of your company, website, etc, but doesn't have to. If it's playful, then the question should follow suit. If not, it still can be playful. Ultimately you're looking for feedback, so the question is "what question promotes the highest chance for honest feedback after the user has attempted to have a question answered?"

In my experience that has always been a yes/no or number-rated question, meaning:

  • Did you get the answer you were looking for? Yes/No (with followup on no with "why" text input
  • How close were we to answering your question? 1-10, where 10 is a perfect answer and 1 is that we didn't answer it at all.

Sadly I don't have any literature on the subject. However, we are currently A/B testing this ourselves, and have found that people who do answer are more willing to do so when the question is phrased more relateably (more playfully) and with the simplest options (aka a Yes/No dropdown is two clicks vs. a 1-10 selector, which is 1 click) always winning out.

  • Thank you for your input. But if I may, why is yes/no two clicks? We use a yes/no where the choice is the submit button, so literally one click. – Myrddin Emrys Apr 24 '15 at 12:22
  • That's fine. If it's a dropdown with 2 clicks, then it's worse. But I think of it this way: if the physical cost is light, people are generally willing to put in the slightest additional cognitive cost for free. So take advantage of that. – Jamezrp Apr 24 '15 at 16:12
0

Just to add, I know the examples you provided were just shorthand quick examples but make sure in implementation you avoid shifting the blame onto the user.

Did we fix your issue?

If I were using an application and something went wrong due to an overloaded backend, poorly implemented code, or incompetency of an employee and I was forced to put in a helpdesk ticket to get my problem resolved, I would likely take it as an affront if I was responded to with "Did we fix your issue?". It was the applications issue, not mine. I may be nitpicking but I know plenty of people in the heat of frustration from it not working in the first place that would take offence to such a response.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.