6 ms·

I own a platform with several thousand unique monthly users within the company where I work. In order to get to the point where you can raise a support ticket,

I own a platform with several thousand unique monthly users within the company where I work. In order to get to the point where you can raise a support ticket, we gently usher people through a flow that asks them whether they've checked our FAQs (that cover 90% of all tickets raised) and then provide them with examples of the kind of additional information that will help the support team to provide quick and useful responses. Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc. I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket. Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support.

galdosdi 4y ago
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. You can move this one out of the theory column and into the fact column. It is very real. :-) Not only is this common but I once even had the misfortune to be in an environment that was so high pressure and under-resourced that the only way to meet ticket quotas was "by any means necessary" I learned this and a bunch of other sketchy tricks to buy time there, such as the reverse of this, which is when the support person asks a question to the customer that is not actually relevant or they already know the answer to, just to buy time till the ticket queue is less overloaded.
- tomcam 4y ago
  Neither of those strategies ever occurred to me. That is… Not encouraging
- nicbou 4y ago
  "My code's compiling" https://xkcd.com/303/ https://xkcd.com/303/
Swizec 4y ago
> Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up … … the first question is always “Have you tried this obvious thing you just said you’ve already tried?”
- soco 4y ago
  I wonder if some support depts (I look at you Tumblr) have this first response automated. MLOps if you want to use a fancy name, but basically a dumb canned answer based on the keyword(s) in your ticket title.
  - Macha 4y ago
    Almost certainly. Some of them (iirc Logitech is one), surface the automated answers and make you click through that you've tried them before letting you contact an agent. I imagine others have this done but don't make it as obvious to the user.
    - soco 4y ago
      Actually this surfacing idea wouldn't bother me at all. But getting a fake answer from some "Joey" completely ignoring the problem description?
- hirundo 4y ago
  > As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up … I love tickets like that, they are so rare and make a resolution so much easier. So I try to compliment them without gushing too much. And then, yeah, I sometimes still want to confirm that they've tried turning it off and on again. I'm that stupid, so it doesn't feel insulting to think that they might be too.
codegeek 4y ago
Some customers just don't like to do their homework and want you to do everything for them. When we get a ticket like this at our company, we have some "Saved/canned replies" to resend which basically asks them for things like "screenshot, error message text etc etc" and only then we even jump in further with any follow ups. My favorite is when there is no info but they expect us to resolve the issue asap. :).
breischl 4y ago
Some people cannot be bothered to (or are incapable of) finding information unless it is spoon-fed to them at the exact time and rate they require. I think this might be the valid use case for support chatbots, even though I personally despise them. Ex: I was selling an item on Facebook Marketplace. The price of the item is in the item header, and in the item description. Multiple people started a chat with me - opening a chat window that has the price again in the chat header - to ask me what it costs. I don't know what you do about that other than have a bot spoon-feed them that information.
- mod 4y ago
  > I don't know what you do about that I refuse to answer them and wait for the next customer. I'd rather wait and sell the item passively (or not at all) than deal with answering questions for people who mostly aren't going to buy the item anyway.
- dahfizz 4y ago
  I think well implemented support chatbots are amazing. They collect all the information they need upfront, and forward it to the correct person who can then quickly solve my problem.
  - breischl 4y ago
    I could see that happening. My experience is mostly with the awful ones for big companies. The kind that are basically like a 1990's era text adventure game where there's only like 6 things you can possibly do, but instead of listing them out they make you guess the exact right phrasing. It's like they figured out the only possible way to make a phone tree even worse than it already was.
    - dahfizz 4y ago
      Yup, I have had that experience as well. I think companies with shitty chatbots would otherwise have bad support anyway, though. For companies that do care about support, chatbots can be a pretty useful tool.
2OEH8eoCRo0 4y ago
I think a big problem is discovery. I search google and it shows me reddit or stack overflow and I have my answer. In larger orgs there is no one stop search for all company knowledge or if there is its painful and returns thousands of useless items.
- geoduck14 4y ago
  It's like we need an internal Reddit or Stack Overflow!
ok_dad 4y ago
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. Agree, but sometimes it isn't even the user's fault and they do things like this out of desperation or frustration. Imagine working in a place where nothing works right, you always have to search through shit documentation to find tiny nuggets of wisdom, and everyone is always pushing to get more done in less time. Then, if you sense a chance to have a short break by throwing something over the wall to another team, you might also choose to do that rather than work even harder to try and find some missing answers for the questions you seek.
- _puk 4y ago
  Don't forget actually putting the work in to understand an issue, and then becoming the go to person for all problems related to X as there's no chance support will solve it in any reasonable timeframe.
  - ok_dad 4y ago
    Yup, the old "hey, X fixed it once, they can do it again" combined with "fixing this permanently will cost too much time" resulting in "X" having to repeatedly tape together the paper airplane carrying the load of a 747.
onion2k 4y ago
I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket. I think this is correct, but I also think it's fine. Users shouldn't have to think about your job. They have their own jobs to fill their time. Implement systems that capture and trace errors, that provide an audit trail of user actions prior to an error event, and capture the state of the system when something goes wrong (or when they hit the help button). Don't rely on users to have to learn how to describe an error in a meaningful way in order to make your job easier. That's not their job.
- pc86 4y ago
  I agree with you if it's a customer reaching out to a company whose product they use, or service they've purchased, etc. But if you're using internal company support, it is by definition your job. You should be expected to put in the minimal effort of reading through the "What to do when X doesn't work" documentation when your ticket subject is "X doesn't work" and the body is "help"
_gabe_ 4y ago
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. I would like for this to be the case, unfortunately I've run into this same thing in many open source projects where it's random users that don't need excuses. I suppose an alternate theory for open source tickets like this is: users who are trying to buff up their github activity regardless of what that activity is.
swatcoder 4y ago
Another theory: we spend most of our lives interacting with people and trading care and attention. Maybe some people don’t have a natural instinct to pore over text looking for a case study that sort of might fit their troubled experience. Automatic funneling through FAQ’s and documentation may be the only way for a company to service it’s 100M users, but necessity doesn’t mean it’s a good fit for the users or that there’s something wrong with the users who don’t take to it well.
- ep103 4y ago
  Agreed. If I am looking at a company FAQ about how to open a ticket, then the emotional interaction here is that the company is putting in not only 0 effort, they are asking me to put in more additional emotional labor to figure out how to get _them_ to address the problem that is causing _me_ harm. To then ask the user to do yet more labor to fill out a _good_ ticket for the company just adds insult to injury at that point, so it should be no surprise so many tickets have nothing worthwhile mentioned. At that point I'm frustrated, have been given the cold shoulder by your company, and have no desire to do your !@#%$ job for you, to help you fix your software, that should have been working already..... I understand that a company might not be able to dedicate a human phone call for every ticket, but I guarantee if they did so, the mere fact that the company would be putting in emotional labor on their end to address the harm their 'bug' has done so far, would cut the number of empty raised issues down massively. In lieu of doing a phone call for every ticket, perhaps try to figure out ways to interact with your customers when they have a problem, that isn't as emotionally barren and uncaring as an FAQ page and forced work to submit a ticket.
  - sokoloff 4y ago
    If customers were, on average, willing to pay enough to companies to staff an employee per 100 customers (or whatever the ratio is to allow prompt, individual service to issues), I think you’d see some companies doing that. That’s more or less how AWS support works when you have a large enough account with them. I don’t directly see the bill for the team who works mostly on my account, but I do know that I’m paying for them (and am happy with that arrangement). A lot of customers (users?) with low or zero spend level want personalized hand-holding. I’m not surprised that they often end up disappointed.
_dain_ 4y ago
On the other hand: please don't make it an odyssey just to email you with a problem. I find it so disrespectful when I have to jump through a million hoops to confirm that yes, really, my problem isn't solved by the FAQs, it's something that you haven't thought of. One particular blind spot that I've come up against again and again is on websites that aren't really for tech, they're for selling some product or service. In their ontology, customer problems are only ever to do with things like accounts or payments or deliveries, never technical aspects of the site itself. In the designers' minds, all their forms work flawlessly, all information presented to the user is consistent, all links work, etc. When any of this fails, they make it hard to report. Things like: dropdown menus for "what is your problem" that don't have an "other" option for anything not listed. Remember that there are always unknown unknowns that need an escape hatch.
- yccs27 4y ago
  As a lot of other comments here indicate, having to confirm multiple times it's really not in the FAQs is not out of disrespect, it's out of necessity for all the people asking the same question again and again. When I encounter that I check the help pages one more time, and just go through the motions to get to the real support. On the other hand, it does bother me when there is just no way to escalate from tier-one support. Some customer service person sends you a canned reply, you respond that the problem persists and you already know there's a technical issue with xyz, and after a few cycles they just go quiet or say "sorry can't help you". After investing time to get this far, that's incredibly infuriating. I've also encountered your issue with "other problems", and how much it matters really depends on how easy it is to get beyond the initial support stage to someone who really listens/reads your messages.
sacrosancty 4y ago
It can be easy to think that since your problem seemingly happened so easily, surely it must already be well-known and you just need to identify the problem to the support staff so they can give you their already-known answer. I've fallen into this trap myself sometimes. Also, sometimes it's true. I get support emails where I see the subject line and know immediately what's wrong. Another thing is people are trained to ignore the content of error messages, probably because usually they're totally useless or meaningless. I used to teach computers at school and kids would demonstrate the problem they're having but when the error message popped up, they're reflexively close it. I'd have to get them to start again so we can read the message. Error messages really are stupid. If you try to copy photos from an Iphone to a Windows, it can fail with either "A device attached to the system is not functioning.", "The device is unreachable.", "Can't read from the source file or disk", or "The requested value cannot be determined.". What the hell is the difference between them? What does the last one even mean?
- EvanAnderson 4y ago
  My favorite is the "Unexpected error". You know, because all the other ones are "expected".
  - ryandrake 4y ago
    My favorite lately is "Something went wrong". Thank you, error message writer! How is this even a remotely acceptable error description? You might as well just crash.
    - hnuser52395 4y ago
      Yes, exactly. I kept getting a "Sorry, something went wrong" with no error code when trying to give a third-party app permissions with my (paid!) Google account, and the most probably reason was that my accounts were locked temporarily due to suspicious activity. There is no information on how long this will last, there is nothing I can do to fix this, and of course, there is no customer support available. I can't even confirm that waiting will actually fix this, as there is no error code. I thought the people at Google would know better.
codingdave 4y ago
Supporting your customers is a different scenario than interrupting co-workers. You want to make sure you have frictionless communications within your team. But your customers are already feeling friction if they feel they need to contact you - don't make it worse for them. Just take their call and fix their problem.
frozencell 4y ago
> some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. Maybe they just write to think :)
fn-mote 4y ago
> Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" [...] Do you get support for just closing these tickets as "does not contain enough detail to be actionable"? Or do you have to deal with them anyway?
- NovemberWhiskey 4y ago
  For the most part, they get directed back to the user with a link to our "helpful guide to writing a good problem report" and put into a "pending user response" state. If the users don't update the ticket within 5 days, the ticket will go self-resolve.
fezfight 4y ago
Having had the displeasure of dealing with several large oligopolies, I have been trained to ignore FAQ funnels/forums/chat windows/phone menus. They seemed to be designed to frustrate the user into giving up.
lhorie 4y ago
> Another theory: that for some people, hitting a problem is an excuse to stop working entirely What I do in these cases is link back to the docs in question format, e.g. "have you tried [link to relevant docs page]". Puts the ball back on their court and kinda puts them on the spot for not doing due diligence without coming off too passive aggressive. On occasion, I had to also explicitly spell out "please include error messages, expected and actual behaviors, repro steps, what have you tried, etc" as a response to a question in slack chat. Some people just lack self-awareness.
pianoben 4y ago
Oh my god I feel so seen right now! I'm in a similar position, and it is an incredible struggle to convince people to raise their head up from their work and think about the context in which they are doing that work. I've generally treated obnoxious bug reports as being my fault, in that the API or interface I've shipped is not sufficiently obvious. In that light, they're a good source of insights on possible new features or design tweaks. All the same, it's demoralizing as hell to see that onslaught of laziness from your coworkers.
Spooky23 4y ago
Absolutely, it’s a form of goldbricking. I ran a service desk for a bit. 70% of tickets are password resets, and 95% of those resets can be done online. We deliberately put password calls in a flow that required a 25 minute minimum wait time, which actually increased the number of calls from some cohorts of users. We reduced the call count by a significant margin by requiring remote users to report to the office if they needed a password reset first thing in the morning, after discovering that cohort was like 5x more likely to call, and most likely to call before 10am.
- SpelingBeeChamp 4y ago
  Why didn't you just require password resets to be done by the user?
renewiltord 4y ago
Well, extra-large FAQs run into the access/completeness trade-off. A 200 page manual is a poor substitute for targeted help. But it's true that StackOverflow and FAQs are fantastic resources. Ultimately, though, perfect reprexes move you nowhere in the queue since no one triages based on issue report quality beyond a bare threshold.
Aperocky 4y ago
This is why you have a bot to comment and reinforce the same language in the ticket if information are not explicitly provided.
SkyPuncher 4y ago
If I've hit the point where I'm deciding to contact your support channel, I have absolutely zero interest in looking through any other documentation. Anything that's preventing me from contacting a human is a waste of time. At the point of contacting support, I've probably already done my research and have come to the conclusion: * I don't know how to explain my issue. I want a human that might be able to make the connection for me. * I've already searched your docs. They're either too confusing, don't answer my question, or lack clarity in a critical detail. * I haven't searched your docs because I suspect it's a glitch (like downtime) or bug (like clearly bad UI) * I haven't searched your docs because, I don't care. I'm doing a courtesy of informing you of a problem, but I don't expect you to fix it. * I'm a potential customer. I want to understand how your team will actually deal with me if I have issue. Good documentation is great, but useless if you don't have a human to support weird edge-cases.
- NovemberWhiskey 4y ago
  >At the point of contacting support, I've probably already done my research ... then you're already not part of the problem.
fatneckbeardz 4y ago
where i work, alot of this could be fixed by recording/watching what users are actually doing then improving the UI so its more obvious what is supposed to be done. its like the old story about how on a college campus some administrator put up dozens of signs about not walking on the grass between buildings, put up mini fences around the grass, etc etc, eventually someone just built a sidewalk where the students were walking.
deleted 4y ago
[deleted]
derefr 4y ago
Tell these people that their tickets will be closed as WONTFIX. The company should back you in just never solving problems specified in such a useless way. If they respond to this not by opening a new, better ticket; but rather by just sitting around doing nothing indefinitely… well, sitting around for weeks when you could be working (where “helping IT to solve your problem” is working) is a pretty good justification to fire someone.
- m1sta_ 4y ago
  This is not the right approach. Your users finding issues in your system is your users doing a service for you. Help them do it better, don't put your head in the sand because they're not doing what you had hoped.
  - derefr 4y ago
    > Your users finding issues in your system is your users doing a service for you. Well, yes, but if they don't report the issue in a way where it can be resolved, then they haven't actually done the service, yet. They've half-done it. > don't put your head in the sand because they're not doing what you had hoped. To be clear, the point isn't that these issues shouldn't be addressed; it's that users need a disincentive to laziness / an incentive to engage actively with the ticketing process. Because, by default, there is no such incentive. By default, in most companies, IT helpdesk workers are seen as a kind of lower-class servant to the people submitting the tickets, where the entire responsibility for solving the problem — including diagnosing the problem — is placed upon them; and anything they might ask of the ticket submitter, e.g. information about what's going wrong in order to do the diagnosis, is seen as an impingement upon the submitter's valuable time. Like a maid interrupting their master's important conversation to ask how they'd like their tea. Nothing needs to change about the workflow of helpdesk ticket submission. In many cases, it's already pretty good. As the GP states, we've tried putting tons of work into guiding people through information-collection flows in such a way that people motivated to do so will submit all useful/relevant information for diagnosis. The only thing that needs to change, is the relative status with which ticket submitters see the IT people. The incentives, on who needs to "put in the work" for whom. In every organization with a sane/healthy/functional IT system I've ever seen, the system is sane/healthy/functional precisely because someone high in the company, e.g. the CTO, happens to also be the head of the IT department; and therefore IT workers, in some sense, have an "ear to power." It's a bit like the setup of the show Undercover Boss — "flipping the script" of traditional organizational power dynamics, by giving those on the bottom of the organizational hierarchy a direct line to those at the top, such that the people in the middle will get in trouble for disrespecting the people who nominally "work for them" (but, in reality, work for those at the top, just assigned to be managed by them.)

galdosdi 4y ago

> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. You can move this one out of the theory column and into the fact column. It is very real. :-) Not only is this common but I once even had the misfortune to be in an environment that was so high pressure and under-resourced that the only way to meet ticket quotas was "by any means necessary" I learned this and a bunch of other sketchy tricks to buy time there, such as the reverse of this, which is when the support person asks a question to the customer that is not actually relevant or they already know the answer to, just to buy time till the ticket queue is less overloaded.

tomcam 4y ago
Neither of those strategies ever occurred to me. That is… Not encouraging
nicbou 4y ago
"My code's compiling" https://xkcd.com/303/ https://xkcd.com/303/

Swizec 4y ago

> Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" with no attempt to report what (if any) error was experienced or what parameters were supplied or what indeed their expectation for "work" was or whether this was "working" before etc As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up … … the first question is always “Have you tried this obvious thing you just said you’ve already tried?”

soco 4y ago
I wonder if some support depts (I look at you Tumblr) have this first response automated. MLOps if you want to use a fancy name, but basically a dumb canned answer based on the keyword(s) in your ticket title.
- Macha 4y ago
  Almost certainly. Some of them (iirc Logitech is one), surface the automated answers and make you click through that you've tried them before letting you contact an agent. I imagine others have this done but don't make it as obvious to the user.
  - soco 4y ago
    Actually this surfacing idea wouldn't bother me at all. But getting a fake answer from some "Joey" completely ignoring the problem description?
hirundo 4y ago
> As a user I have given up on providing this info. Any time I start a support conversation with a detailed analysis of what’s breaking, what I’ve tried, and even which resources I looked up … I love tickets like that, they are so rare and make a resolution so much easier. So I try to compliment them without gushing too much. And then, yeah, I sometimes still want to confirm that they've tried turning it off and on again. I'm that stupid, so it doesn't feel insulting to think that they might be too.

codegeek 4y ago

Some customers just don't like to do their homework and want you to do everything for them. When we get a ticket like this at our company, we have some "Saved/canned replies" to resend which basically asks them for things like "screenshot, error message text etc etc" and only then we even jump in further with any follow ups. My favorite is when there is no info but they expect us to resolve the issue asap. :).

breischl 4y ago

Some people cannot be bothered to (or are incapable of) finding information unless it is spoon-fed to them at the exact time and rate they require. I think this might be the valid use case for support chatbots, even though I personally despise them. Ex: I was selling an item on Facebook Marketplace. The price of the item is in the item header, and in the item description. Multiple people started a chat with me - opening a chat window that has the price again in the chat header - to ask me what it costs. I don't know what you do about that other than have a bot spoon-feed them that information.

mod 4y ago
> I don't know what you do about that I refuse to answer them and wait for the next customer. I'd rather wait and sell the item passively (or not at all) than deal with answering questions for people who mostly aren't going to buy the item anyway.
dahfizz 4y ago
I think well implemented support chatbots are amazing. They collect all the information they need upfront, and forward it to the correct person who can then quickly solve my problem.
- breischl 4y ago
  I could see that happening. My experience is mostly with the awful ones for big companies. The kind that are basically like a 1990's era text adventure game where there's only like 6 things you can possibly do, but instead of listing them out they make you guess the exact right phrasing. It's like they figured out the only possible way to make a phone tree even worse than it already was.
  - dahfizz 4y ago
    Yup, I have had that experience as well. I think companies with shitty chatbots would otherwise have bad support anyway, though. For companies that do care about support, chatbots can be a pretty useful tool.

2OEH8eoCRo0 4y ago

I think a big problem is discovery. I search google and it shows me reddit or stack overflow and I have my answer. In larger orgs there is no one stop search for all company knowledge or if there is its painful and returns thousands of useless items.

geoduck14 4y ago
It's like we need an internal Reddit or Stack Overflow!

ok_dad 4y ago

> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. Agree, but sometimes it isn't even the user's fault and they do things like this out of desperation or frustration. Imagine working in a place where nothing works right, you always have to search through shit documentation to find tiny nuggets of wisdom, and everyone is always pushing to get more done in less time. Then, if you sense a chance to have a short break by throwing something over the wall to another team, you might also choose to do that rather than work even harder to try and find some missing answers for the questions you seek.

_puk 4y ago
Don't forget actually putting the work in to understand an issue, and then becoming the go to person for all problems related to X as there's no chance support will solve it in any reasonable timeframe.
- ok_dad 4y ago
  Yup, the old "hey, X fixed it once, they can do it again" combined with "fixing this permanently will cost too much time" resulting in "X" having to repeatedly tape together the paper airplane carrying the load of a 747.

onion2k 4y ago

I'm sort of coming to the conclusion that for some fraction of users, there is nothing that can be done to get them to think at all before raising a trouble ticket. I think this is correct, but I also think it's fine. Users shouldn't have to think about your job. They have their own jobs to fill their time. Implement systems that capture and trace errors, that provide an audit trail of user actions prior to an error event, and capture the state of the system when something goes wrong (or when they hit the help button). Don't rely on users to have to learn how to describe an error in a meaningful way in order to make your job easier. That's not their job.

pc86 4y ago
I agree with you if it's a customer reaching out to a company whose product they use, or service they've purchased, etc. But if you're using internal company support, it is by definition your job. You should be expected to put in the minimal effort of reading through the "What to do when X doesn't work" documentation when your ticket subject is "X doesn't work" and the body is "help"

_gabe_ 4y ago

> Another theory: that for some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. I would like for this to be the case, unfortunately I've run into this same thing in many open source projects where it's random users that don't need excuses. I suppose an alternate theory for open source tickets like this is: users who are trying to buff up their github activity regardless of what that activity is.

swatcoder 4y ago

Another theory: we spend most of our lives interacting with people and trading care and attention. Maybe some people don’t have a natural instinct to pore over text looking for a case study that sort of might fit their troubled experience. Automatic funneling through FAQ’s and documentation may be the only way for a company to service it’s 100M users, but necessity doesn’t mean it’s a good fit for the users or that there’s something wrong with the users who don’t take to it well.

ep103 4y ago
Agreed. If I am looking at a company FAQ about how to open a ticket, then the emotional interaction here is that the company is putting in not only 0 effort, they are asking me to put in more additional emotional labor to figure out how to get _them_ to address the problem that is causing _me_ harm. To then ask the user to do yet more labor to fill out a _good_ ticket for the company just adds insult to injury at that point, so it should be no surprise so many tickets have nothing worthwhile mentioned. At that point I'm frustrated, have been given the cold shoulder by your company, and have no desire to do your !@#%$ job for you, to help you fix your software, that should have been working already..... I understand that a company might not be able to dedicate a human phone call for every ticket, but I guarantee if they did so, the mere fact that the company would be putting in emotional labor on their end to address the harm their 'bug' has done so far, would cut the number of empty raised issues down massively. In lieu of doing a phone call for every ticket, perhaps try to figure out ways to interact with your customers when they have a problem, that isn't as emotionally barren and uncaring as an FAQ page and forced work to submit a ticket.
- sokoloff 4y ago
  If customers were, on average, willing to pay enough to companies to staff an employee per 100 customers (or whatever the ratio is to allow prompt, individual service to issues), I think you’d see some companies doing that. That’s more or less how AWS support works when you have a large enough account with them. I don’t directly see the bill for the team who works mostly on my account, but I do know that I’m paying for them (and am happy with that arrangement). A lot of customers (users?) with low or zero spend level want personalized hand-holding. I’m not surprised that they often end up disappointed.

_dain_ 4y ago

On the other hand: please don't make it an odyssey just to email you with a problem. I find it so disrespectful when I have to jump through a million hoops to confirm that yes, really, my problem isn't solved by the FAQs, it's something that you haven't thought of. One particular blind spot that I've come up against again and again is on websites that aren't really for tech, they're for selling some product or service. In their ontology, customer problems are only ever to do with things like accounts or payments or deliveries, never technical aspects of the site itself. In the designers' minds, all their forms work flawlessly, all information presented to the user is consistent, all links work, etc. When any of this fails, they make it hard to report. Things like: dropdown menus for "what is your problem" that don't have an "other" option for anything not listed. Remember that there are always unknown unknowns that need an escape hatch.

yccs27 4y ago
As a lot of other comments here indicate, having to confirm multiple times it's really not in the FAQs is not out of disrespect, it's out of necessity for all the people asking the same question again and again. When I encounter that I check the help pages one more time, and just go through the motions to get to the real support. On the other hand, it does bother me when there is just no way to escalate from tier-one support. Some customer service person sends you a canned reply, you respond that the problem persists and you already know there's a technical issue with xyz, and after a few cycles they just go quiet or say "sorry can't help you". After investing time to get this far, that's incredibly infuriating. I've also encountered your issue with "other problems", and how much it matters really depends on how easy it is to get beyond the initial support stage to someone who really listens/reads your messages.

sacrosancty 4y ago

It can be easy to think that since your problem seemingly happened so easily, surely it must already be well-known and you just need to identify the problem to the support staff so they can give you their already-known answer. I've fallen into this trap myself sometimes. Also, sometimes it's true. I get support emails where I see the subject line and know immediately what's wrong. Another thing is people are trained to ignore the content of error messages, probably because usually they're totally useless or meaningless. I used to teach computers at school and kids would demonstrate the problem they're having but when the error message popped up, they're reflexively close it. I'd have to get them to start again so we can read the message. Error messages really are stupid. If you try to copy photos from an Iphone to a Windows, it can fail with either "A device attached to the system is not functioning.", "The device is unreachable.", "Can't read from the source file or disk", or "The requested value cannot be determined.". What the hell is the difference between them? What does the last one even mean?

EvanAnderson 4y ago
My favorite is the "Unexpected error". You know, because all the other ones are "expected".
- ryandrake 4y ago
  My favorite lately is "Something went wrong". Thank you, error message writer! How is this even a remotely acceptable error description? You might as well just crash.
  - hnuser52395 4y ago
    Yes, exactly. I kept getting a "Sorry, something went wrong" with no error code when trying to give a third-party app permissions with my (paid!) Google account, and the most probably reason was that my accounts were locked temporarily due to suspicious activity. There is no information on how long this will last, there is nothing I can do to fix this, and of course, there is no customer support available. I can't even confirm that waiting will actually fix this, as there is no error code. I thought the people at Google would know better.

codingdave 4y ago

Supporting your customers is a different scenario than interrupting co-workers. You want to make sure you have frictionless communications within your team. But your customers are already feeling friction if they feel they need to contact you - don't make it worse for them. Just take their call and fix their problem.

frozencell 4y ago

> some people, hitting a problem is an excuse to stop working entirely and claim to be waiting on another team for support. Maybe they just write to think :)

fn-mote 4y ago

> Some ridiculously high proportion (half?) of tickets still come out looking like "it doesn't work when I do X" [...] Do you get support for just closing these tickets as "does not contain enough detail to be actionable"? Or do you have to deal with them anyway?

NovemberWhiskey 4y ago
For the most part, they get directed back to the user with a link to our "helpful guide to writing a good problem report" and put into a "pending user response" state. If the users don't update the ticket within 5 days, the ticket will go self-resolve.

fezfight 4y ago

Having had the displeasure of dealing with several large oligopolies, I have been trained to ignore FAQ funnels/forums/chat windows/phone menus. They seemed to be designed to frustrate the user into giving up.

lhorie 4y ago

> Another theory: that for some people, hitting a problem is an excuse to stop working entirely What I do in these cases is link back to the docs in question format, e.g. "have you tried [link to relevant docs page]". Puts the ball back on their court and kinda puts them on the spot for not doing due diligence without coming off too passive aggressive. On occasion, I had to also explicitly spell out "please include error messages, expected and actual behaviors, repro steps, what have you tried, etc" as a response to a question in slack chat. Some people just lack self-awareness.

pianoben 4y ago

Oh my god I feel so seen right now! I'm in a similar position, and it is an incredible struggle to convince people to raise their head up from their work and think about the context in which they are doing that work. I've generally treated obnoxious bug reports as being my fault, in that the API or interface I've shipped is not sufficiently obvious. In that light, they're a good source of insights on possible new features or design tweaks. All the same, it's demoralizing as hell to see that onslaught of laziness from your coworkers.

Spooky23 4y ago

Absolutely, it’s a form of goldbricking. I ran a service desk for a bit. 70% of tickets are password resets, and 95% of those resets can be done online. We deliberately put password calls in a flow that required a 25 minute minimum wait time, which actually increased the number of calls from some cohorts of users. We reduced the call count by a significant margin by requiring remote users to report to the office if they needed a password reset first thing in the morning, after discovering that cohort was like 5x more likely to call, and most likely to call before 10am.

SpelingBeeChamp 4y ago
Why didn't you just require password resets to be done by the user?

renewiltord 4y ago

Well, extra-large FAQs run into the access/completeness trade-off. A 200 page manual is a poor substitute for targeted help. But it's true that StackOverflow and FAQs are fantastic resources. Ultimately, though, perfect reprexes move you nowhere in the queue since no one triages based on issue report quality beyond a bare threshold.

Aperocky 4y ago

This is why you have a bot to comment and reinforce the same language in the ticket if information are not explicitly provided.

SkyPuncher 4y ago

If I've hit the point where I'm deciding to contact your support channel, I have absolutely zero interest in looking through any other documentation. Anything that's preventing me from contacting a human is a waste of time. At the point of contacting support, I've probably already done my research and have come to the conclusion: * I don't know how to explain my issue. I want a human that might be able to make the connection for me. * I've already searched your docs. They're either too confusing, don't answer my question, or lack clarity in a critical detail. * I haven't searched your docs because I suspect it's a glitch (like downtime) or bug (like clearly bad UI) * I haven't searched your docs because, I don't care. I'm doing a courtesy of informing you of a problem, but I don't expect you to fix it. * I'm a potential customer. I want to understand how your team will actually deal with me if I have issue. Good documentation is great, but useless if you don't have a human to support weird edge-cases.

NovemberWhiskey 4y ago
>At the point of contacting support, I've probably already done my research ... then you're already not part of the problem.

fatneckbeardz 4y ago

where i work, alot of this could be fixed by recording/watching what users are actually doing then improving the UI so its more obvious what is supposed to be done. its like the old story about how on a college campus some administrator put up dozens of signs about not walking on the grass between buildings, put up mini fences around the grass, etc etc, eventually someone just built a sidewalk where the students were walking.

deleted 4y ago

[deleted]

derefr 4y ago

Tell these people that their tickets will be closed as WONTFIX. The company should back you in just never solving problems specified in such a useless way. If they respond to this not by opening a new, better ticket; but rather by just sitting around doing nothing indefinitely… well, sitting around for weeks when you could be working (where “helping IT to solve your problem” is working) is a pretty good justification to fire someone.

m1sta_ 4y ago
This is not the right approach. Your users finding issues in your system is your users doing a service for you. Help them do it better, don't put your head in the sand because they're not doing what you had hoped.
- derefr 4y ago
  > Your users finding issues in your system is your users doing a service for you. Well, yes, but if they don't report the issue in a way where it can be resolved, then they haven't actually done the service, yet. They've half-done it. > don't put your head in the sand because they're not doing what you had hoped. To be clear, the point isn't that these issues shouldn't be addressed; it's that users need a disincentive to laziness / an incentive to engage actively with the ticketing process. Because, by default, there is no such incentive. By default, in most companies, IT helpdesk workers are seen as a kind of lower-class servant to the people submitting the tickets, where the entire responsibility for solving the problem — including diagnosing the problem — is placed upon them; and anything they might ask of the ticket submitter, e.g. information about what's going wrong in order to do the diagnosis, is seen as an impingement upon the submitter's valuable time. Like a maid interrupting their master's important conversation to ask how they'd like their tea. Nothing needs to change about the workflow of helpdesk ticket submission. In many cases, it's already pretty good. As the GP states, we've tried putting tons of work into guiding people through information-collection flows in such a way that people motivated to do so will submit all useful/relevant information for diagnosis. The only thing that needs to change, is the relative status with which ticket submitters see the IT people. The incentives, on who needs to "put in the work" for whom. In every organization with a sane/healthy/functional IT system I've ever seen, the system is sane/healthy/functional precisely because someone high in the company, e.g. the CTO, happens to also be the head of the IT department; and therefore IT workers, in some sense, have an "ear to power." It's a bit like the setup of the show Undercover Boss — "flipping the script" of traditional organizational power dynamics, by giving those on the bottom of the organizational hierarchy a direct line to those at the top, such that the people in the middle will get in trouble for disrespecting the people who nominally "work for them" (but, in reality, work for those at the top, just assigned to be managed by them.)