Want quick answers? Ask questions well
quick-answers.kronis.dev
quick-answers.kronis.dev
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.
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.
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?”
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.
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.
My favorite is when there is no info but they expect us to resolve the issue asap. :).
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.
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.
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.
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.
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.
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?
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.
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.
“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 they just write to think :)
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?
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'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.
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.
Ultimately, though, perfect reprexes move you nowhere in the queue since no one triages based on issue report quality beyond a bare threshold.
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.
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.
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.
1. Providing useful context up-front
2. No "hello" message sent while waiting for further input to be typed in
3. More emphasis on written communication
4. Less of a need to jump on a video conference
5. Use of headsets for video conferences
In some of the latter cases, the "office-first teams" still had management working out of the office and I believe that remote employees are kind of second-class citizens in these cases, and I found it less enjoyable and less productive to be a remote dev in that sort of situation.
I believe also that headsets for video conferences allows for full-duplex conversations where one or more people can talk at once and be heard, but I've not seen anybody else talk about this and may be wrong.
100% agreed. For a long time, I think I was the only remote employee, and always felt forgotten unless I bothered people.
Even after it became more balanced after COVID, it became clear to me that in office people were given far preferential treatment. Ultimately, it's that that caused me to leave for a remote first company.
That makes since most video conferencing services have complex audio feedback canceling algorithms. If the mic can't hear the speakers then there is no feedback to cancel.
- http://www.catb.org/esr/faqs/smart-questions.html
might be of some help as well :)
While those lean toward SO-specific usage, they also contain some very good guidance IMHO
So these days, I start writing down all this stuff as I'm exploring the problem, and much of the time it helps discover the solution and I don't need to send the message.
[1]: https://blog.codinghorror.com/rubber-duck-problem-solving/
Also with a detailed message, people don't seem to read (or grasp) the entire thing and get fixated on parts that aren't the issue or ask questions that I already answered in my initial question.
I guess you need to know your audience and adjust your question style based on that.
I could write a thorough narrative with a good description of my environment and details of all the things I tried to do. Then I get dismissed by a technician who says (this actually happened): "Your issue is to complicated to be solved over email. We need to have a call." The call lasted less than 5 minutes. It consisted of me reading my email (verbatim, because I'm an asshole and took being dismissed personally), the technician telling me what I needed to do, and me doing it.
I could go with the whole "quick question" route and spend more time than it would take to write having a back-and-forth with a technician who can't let me speak and keeps interrupting with suggestions (for things I've already tried or aren't applicable), repeated questions( because they aren't keeping written notes), or out-right confusion (because they have preconceived ideas about my situation and haven't validated them with questions).
I find it easiest to just grind away on a problem myself, reverse engineering, referring to source code, etc. Then I don't have to feel bad or make someone else feel bad. I loathe having to involve an unknown third-party. My confirmation bias says that it'll usually be bad.
But it's a double edged sword. I am not the most articulate person so sometimes the information ends up becoming more confusing for the reader which doesn't help either.
I’m a solo developer and receive maybe 10 emails a day from end users. I can answer 90% of the questions with a few characters on my phone via “text replacement” so if I type: lllic it’ll automatically insert https://label.live/faqs/licensing/can-i-use-a-license-on-mor...
You know, as an example…
A few other favorites:
Llty “Thank you for the email.” Lllmk “Let me know if this helps.”
I should really invest in Text Expander or similar. Although, maybe ZenDesk will come out with some wild AI integration that allows me to piece together a response based on my prior responses. Surely that’s coming.
Personally, doing calls with screen sharing when they could have been replaced by a screenshot or a code snippet alongside a text message feels like not the most efficient way to do things. Much like the "this meeting could have been an e-mail joke".
And yet, most of the sites that out there that encapsulate some of these ideas feel a bit emotionally charged:
https://nohello.net/en/ has a facepalm as a reaction to the behavior (though the design is great)
https://nohello.club/ calls pleasantries "useless", even if the logo is cool
https://no-hello.com/ seems to be meant for sending to someone in particular
So I went ahead and made my own little page that attempts to offer similar suggestions in a slightly more boring manner. Maybe some day I'll get a proper domain for it.
Overall, asynchronous communication just feels like one of those things where you can improve how well it works with minimal effort.
I do think that a lot of these sites date all the way back to 2013, to a blog post that was referenced in one of them: https://www.nohello.com/2013/01/please-dont-say-just-hello-i...
I guess it's actually very much like that xkcd about standards: https://xkcd.com/927/
But it also has a special badge so that can communicate to other people that you bundle polite greetings in with the payload of the message, which I think is weird, and is probably a clue that the author and I don't share a cultural context here.
If it's a day or more, do you still prefer they share just a little info or would you also prefer more info if a longer response time?
I've been texting with someone over Whatsapp and she seems to treat it more like email: no read indicators, no set response time (sometimes minutes, days, or weeks), longer responses when she does. It can be so hard for me as I associate WhatsApp and texting with relatively real-time chat and the differences in expectations have caused conflict between us quite a few times.
Too many technicians seem to freeze up as soon as they seem an error message.
> given this code, how would you return errors to an internal audience? How would you change the errors if you knew the error was going to be presented to the end user?
Because for sure crafting actionable errors is a life-skill
I want to rage close PRs that contain
throw new Exception("cannot query")Examples:
"We saw <garbled> and so we left."
'You left because you saw what?'
"I collect samples with <garbled> at the beach."
'You used what to collect samples at the beach?'
Otherwise, they will repeat the whole thing, or rephrase it, or even worse, start by appending detail that assumes you heard the original part correctly.
Otherwise these asks are nothing more than asking for attention, which isn't just given away freely.
That doesn't make someone an asshole, this makes someone who values their time.
“A problem well-articulated is a problem half solved.”
-Charles Kettering
https://jondouglas.dev/problems-vs-solutions/
Aside: If direct messages and email doesn't scale for you, try doing an office hours type deal.
This immediately cut the time I spent, with support, by half. Some people realized the solution its almost always in the error text. Others spend hours trying to figure out the problem themselves, just to avoid submitting a ticket. People are strange.
People will go through hell and back to not fill out a quick form for help.
What I find baffling is that when someone is working from home, they can answer a call any time. When someone is working in the office, they have to find a meeting room before getting on a call. And yet, the office is officially declared to be more conducive to collaboration. When Microsoft still had individual offices with walls and doors, the open plan offices were called "more collaborative" which is 100% incorrect.
Sometimes it's really hard not to get incredibly frustrated with it. The questions can be as vague as "hey we're having trouble authenticating to the artifactory, how do we fix it?" A few people really shine in explaining themselves clearly, giving the context, copy-pasting the error message, etc, and I truly treasure those people. The proper context can really turn an hour of debugging into 5 minutes debugging
Clearly there is, at least from your perspective, otherwise you wouldn’t be asking. Come out with it and state what the issue you’re seeing so someone can either tell you it’s known and point you at the ticket tracking an open incident, or do what needs to be done to resolve your issue.
Frustrating watching the description slowly emerge, line by line, like an old teletype machine or something. Get the entirety of what you want to say in one hit in one message. I know then to respond and not sitting there waiting for the next nugget of information.
I love my friends. I hate how they communicate over text.
"Silas,
I hope this message reaches you well. The sun is setting and I am optimistic about the future. I am wondering if you are interested in the upcoming conference, where you are sure to find many fans of that course you like. Let me know what you think and get back to me.
[his name]"
Me: "Oh sure I'm going already got ticket and booked flight."
(Interestingly once I scared off a potential dating partner who is heavily into texting constantly and called me out for my asynchronous messaging habits and I flatly responded “sometimes I just want to put my phone down and do literally anything else”)
https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...
I think it's frowned upon, here.
I won't do it deliberately, but, if I'm unsure of the answer, posting what I think is the answer, in a confident way, tends to get results. ;)
I've also learned to ask fairly detailed, well-researched questions, from StackOverflow.
They bitch at you, if you ask a "stupid" question (but usually answer it, anyway), but I have found, if I ask a detailed, well-researched question, crickets chirp.
I have basically given up on SO for anything useful, these days. I'm sad, because it used to be a great place to learn.
If I ask the kinds of questions they'll answer, I get sneered at. If I ask the kinds of questions they say they want, I get ignored.
Damn that is true. I actually have 94,000 rep on Stack Overflow, but I got banned for no reason. I appealed 9 times with no response, and finally they said someone was upvoting my stuff as a scam. I tried to cooperate to clear my name, but they are just ignoring me now for weeks.
Soon you are asking moderately complicated questions that some can answer (but probably have been asked before). This is where you can get some help if you’re lucky.
But later you’re asking questions so advanced nobody can answer them, and they never get answered unless you remember to come back and answer your own question.
Being cooperative, specific and transparent is really all you need to start with. Even synchronous communication benefits from this.
Be tolerant of others and gently suggest they can help themselves, in the future, by helping you. Be thankful for the times you get to work with people who share a common style with you.
Teammate: hey can we hop on a call real quick, I need some help
Me: yep, give me like 2 minutes and I'll send you a zoom link
This is a pretty good counterpoint to my site! I think that for some, voice is just the preferred medium of communication and that should also be taken into account when possible.
Of course, I'd argue that a little bit of context of what the problem is related to could still be helpful, not to have to waste a bunch of time trying to find some Jira ticket that had some relevant info from like 2 weeks back during the call.
For others, text will probably reign supreme, though I also enjoy things like huddles that Slack introduced, to make informal "meetings" a bit more organic: https://slack.com/help/articles/4402059015315-Use-huddles-in...
Fair enough, but it amazes me the number of people who pile in, clearly without reading what I wrote, seemingly unable to readjust when I point out "no, that's not what asked"
A while back I asked a question. Let's say it was about destructors (it wasn't but for example). People started answering about constructors. Repeatedly. One of the SO editors came in and pointed out that there was plenty about constructors on SO already so he was closing the question. I rather lost it at that point, spelt out DEE-STRUCT-ORRS I was asking about. He wiped all the comments (his own included), reopened the question and today it remains unanswered.
That was an extreme case of this phenomenon but stone the bladdy crows, it's not rare.
"Hey, you there?" works for a text to your partner
"Hey, are you available at 12:00 tomorrow?" works much better for your coworkers.
A problem has three distinct parts: 1) What you tried. 2) What you expected. 3) What you got instead.
Anything else is just complaining and I don't deal with complaints.
Usually there's enough information in the triad to begin troubleshooting. I will roughly know the steps to reproduce, what that reproduction returns, and what the user thinks they should have got.
If I get told "Hey, the calculation is wrong." I'm going to check the calculation. And if the math is solid, and passes all of the cases I can send it, that's the information I will give back. Usually while also asking why they think it is wrong. Sometimes, the only thing that is wrong is user expectation.
Second, the respondent can tell if you’re really trying to fix the problem and are stuck, or if you aren’t bothering and are instead simply asking. I,e, if you’re worth helping.
Please, tell us what you think is wrong with your bread, as well as the details of the recipe you followed. Why are you expecting us to be mind readers just so we can help you?
For situations where it's a complicated problem, this can be reasonable. That said, there's little excuse for "isn't working" or being vague about the error message.
That is the other heuristic when describing a problem and reporting what you already learned, that makes the whole process an art: keep it short!
A case I personally encountered was somebody who wanted to have better relationships with people and read the book "How To Win Friends And Influence People". Unfortunately, that book is just full of advice on how to make others feel good about themselves, which wasn't their aim, and it really backfired into blaming others for not following the book's advice.
1) He/she is in a meeting, they have a choice - to or not to reply
2) If their screen is shared, I am not disturbing the meeting attendees making them read what I typed, and what comes in the notification pop-up
3) Gives enough time for the other person to switch context
4) Ignore me for an indefinite amount of time and continue their work
If the other person responds, my second comment would be with full details.
Niceites are, well, nice. They help to make sure everyone remembers we’re all human beings rather than question answering machines, but we are also talking to get a job done. Unless you’re actually a good friend of mine if you drop me a message asking me how my weekend was, I know that you’re just lining up to ask me a question, but now I have to do The Dance to work out what it’s going to be about, whether I have time for it, and if I’m even the right person to ask.
> Them: "Hi"
> ...
> Me: "What's up"
> ...
> Them: "Do you have 5 minutes to join this conversation?"
> ...
is awful.
And as a blanket rule of thumb, don't send people chat messages that you wouldn't want to see displayed to an arbitrary meeting full of people. :)
If you have a question, just ask it. If you want to have a 5, 10, or 30 min, discussion, ask for that.
I'd prefer a long form question with all the communication from your side fully expressed, then I can ponder on it and multiplex it between my dozen other things.
Still.. the question is out there. At least when it's written out, you can know if it's a worthwhile question. Or ask some quick follow-ups that they hadn't thought to nail down first.
I much prefer the first situation where someone says hi and that leads to a discussion on their issue to the second one. All the things the article asks for will come forwards in the discussion anyway and ninety percents of the time the people asking for help have a different problem than the one they thought they had anyway.
I am not a robot. I don’t want to be treated like one.