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.
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?
But then, there’s also that class of things that fail in exciting and unexpected ways: a bit randomly flipping in memory, a cable detached in an untimely moment, a missing system library that was there when the program started… you cannot enumerate all things that may fail unexpectedly, hence the only viable solution is to have a special case for those - „Unexpected error“ doesn’t sound wrong from that perspective.
Still, it’s completely useless to the human in front of the machine, so there’s that.
The useless error messages are still my number one reason to avoid anything from Microsoft.
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.
“Unexpected error” basically means “I called a function that threw an exception, but didn’t have code in place to catch it, so it hit some toplevel global exception handler that just aborts the whole thing.”
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.
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.
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.
For the googles and amazons out there, they have enough customers who don't require manual service that they can afford to just let go of any customers who do.
Of course most companies are somewhere between "little shop that needs your money" and "google."
In many cases it's just respectful of the other person's time.
But at the same time it's starting to feel like every experience is becoming like self-checkout. You end up doing everyone's job so that the employer can cut costs.
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.
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.
... then you're already not part of the problem.
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?”
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.
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.
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.
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.
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.
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.
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.
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.
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"
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.
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.
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.
My favorite is when there is no info but they expect us to resolve the issue asap. :).
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.
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.
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.)
I disagree. Whether the bug can be resolved is on you, not them. It's nice when they make it easy. It's smart to incentivise them to help more than just a basic report. It's stupid to ignore the existence of a bug just because you don't like the way that someone reported it. You might deprioritise it based on a time ROI consideration but you shouldn't ignore it.
Ultimately, though, perfect reprexes move you nowhere in the queue since no one triages based on issue report quality beyond a bare threshold.
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?
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.
Maybe they just write to think :)
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.