[HN Gopher] Want quick answers? Ask questions well
___________________________________________________________________
Want quick answers? Ask questions well
Author : KronisLV
Score : 163 points
Date : 2022-08-31 18:08 UTC (4 hours ago)
(HTM) web link (quick-answers.kronis.dev)
(TXT) w3m dump (quick-answers.kronis.dev)
| MarkLowenstein wrote:
| Great article. Hits the best points without wasting time on
| minutia.
|
| 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!
| mfrw wrote:
| I think a passing mention of:
|
| - https://xyproblem.info
|
| - http://www.catb.org/esr/faqs/smart-questions.html
|
| might be of some help as well :)
| KronisLV wrote:
| Thanks, that's a good idea! Added these as "further reading" at
| the bottom.
| mdaniel wrote:
| and https://stackoverflow.com/help/how-to-ask along with its
| sub-section https://stackoverflow.com/help/minimal-
| reproducible-example
|
| While those lean toward SO-specific usage, they also contain
| some very good guidance IMHO
| svnpenn wrote:
| > The best way to get the right answer on the Internet is not to
| ask a question; it's to post the wrong answer.
|
| https://wikipedia.org/wiki/Ward_Cunningham#%22Cunningham's_L...
| ChrisMarshallNY wrote:
| This is true.
|
| 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.
| svnpenn wrote:
| > 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.
| chihuahua wrote:
| I found that when I'm about to ask someone a question, in the
| process of writing down all the details of what I want to do,
| what I've tried, what happened, which alternatives I've tried,
| and why it can't possibly be the fault of my own code, at least
| half the time I find the answer on my own.
|
| 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.
| SilasX wrote:
| Great stuff. One related hack I have for oral communication: if
| you mishear/aren't sure about part of what someone said, repeat
| back everything you _did_ hear as part of your question, so they
| only have to repeat that one part. (Bonus: It validates that you
| were listening!)
|
| 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.
| elicash wrote:
| Person 1 wanted to have a video call and was using messaging as a
| way to facilitate that call.
|
| 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.
| coldblues wrote:
| https://dontasktoask.com/
|
| https://nohello.net/en/
| lxe wrote:
| I don't care if you say hello as long as you follow up with a
| detailed question. What grinds my gears is developers not linking
| to tickets or error logs, or not pasting the error messages into
| the question. I'm not going to play detective and investigate
| your failing CI logs -- provide me with the exact line where the
| error occurred.
| avg_dev wrote:
| I've been working from home for most of the past 15 years, and
| I've worked at some companies that had remote-first development
| teams and some where development started in-the-office and then
| branched off into remote. I believe in the former there was more
| understanding of:
|
| 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.
| guelo wrote:
| > headsets for video conferences allows for full-duplex
| conversations
|
| 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.
| silisili wrote:
| > 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
|
| 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.
| overthemoon wrote:
| Nothing makes me more fucking annoyed than the singular "hey". I
| will always, always ignore it. If it's important, fill in more
| detail, we're not on a phone call.
| macintux wrote:
| I'd like to come up with a series of interview questions to
| evaluate whether someone can interpret error messages and ask
| reasonable questions regarding them.
|
| Too many technicians seem to freeze up as soon as they seem an
| error message.
| mdaniel wrote:
| And the opposite bank of questions:
|
| > 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")
| zasdffaa wrote:
| I try to write good questions for stackoverflow (which I'm
| certainly not dissing, I think it;s a great resource used
| properly) and I usually miss something out and have to throw in
| an edit.
|
| 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.
| BlargMcLarg wrote:
| It's a little ironic how the field which continuously talks about
| the importance of communication doesn't understand the basics of
| communication, and how synchronous communication made them a
| luxury.
|
| Being cooperative, specific and transparent is really all you
| need to start with. Even synchronous communication benefits from
| this.
| werdnapk wrote:
| I find when I ask questions in public forums and provide a lot of
| detail about the issue, it seems to get ignored because there's
| too much information compared to other people who ask more basic
| questions that require follow up questions.
|
| 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.
| EvanAnderson wrote:
| What's daunting is when you don't know the audience-- like
| opening a new tech support case.
|
| 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.
| semireg wrote:
| I've been looking for "how to ask questions the smart way" for
| years! I kept googling the wrong title ... I love how thorough it
| is, in the style of a Linux how-to or RFC.
|
| 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.
| gumby wrote:
| Sharing what you've tried already helps in two ways. The
| respondent can tell if you're barking up the wrong tree or not
| and give a better, sometimes briefer answer.
|
| 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.
| bena wrote:
| I like to ask "Do you have a problem or do you have a complaint?"
|
| 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.
| hankchinaski wrote:
| I see this often with very junior engineers. They just haggle
| around before getting to the point. But something that rarely see
| in more seasoned people.
| sacrosancty wrote:
| I help people with tech problem all the time and I don't like it
| when they tell me what they tried in too much detail. It means I
| have to read through it all and be sure I'm considering
| everything they said even when the likely problem and solution is
| already obvious. I'd rather they just say "I did this and then
| that happened." and if my obvious answer is wrong, then we can
| dig into the details. Perhaps that serves my interests more than
| theirs, but if you're trying to help the tech support guy, then
| why not?
| jimkleiber wrote:
| I've noticed how much I write tends to depend on how long I
| think it will take to get a response. If I think it will be a
| live chat, I'll say just a sentence or two. If I think it'll be
| maybe a few hours to reply, maybe a paragraph or two. If a day
| or more, then often multiple paragraphs.
|
| 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?
| sacrosancty wrote:
| It's mostly over email with a day turnaround and I don't mind
| it dragging on. But I worry the customer won't like that!
| SilverBirch wrote:
| Even ignoring the obvious "Users are idiots" chat, if you ever
| show a problem to someone else "Oh it works now" is almost
| always the answer.
| jlokier wrote:
| Heh. I'm known for fixing things that don't work. I do it by
| looking over someone's shoulder while they show me. I don't
| have to say anything, just agree to watch. Then I walk away,
| all fixed. It's like magic.
| sneak wrote:
| The reason that so many people ask for calls is because they are
| slow/bad at typing. Speaking is faster/easier for them because
| they are not trained.
| chihuahua wrote:
| On the r/bread subreddit, I am greatly irritated by people who
| post a picture of their failed bread along with the title "what
| did I do wrong???"
|
| 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?
| BarryMilo wrote:
| Anyone else notice the corrected version is just the standard
| format for an email?
| karaterobot wrote:
| My ideal interaction is more like: 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
|
| There is almost always value in seeing what happens right before
| the problem, and I almost always have questions I want to ask
| them about it, and it's _so much faster_ just to do it with
| screensharing and voice. A lot of the time anyway.
| KronisLV wrote:
| > There is almost always value in seeing what happens right
| before the problem, and I almost always have questions I want
| to ask them about it, and it's so much faster just to do it
| with screensharing and voice.
|
| 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...
| RoadieRoller wrote:
| I always start the chat conversation in office with a simple "Hi"
| or a "Hi, Do you have a minute?" This way, I am giving that
| person a choice if
|
| 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.
| wnolens wrote:
| I don't like this. You're demanding a sync interaction from
| someone who is probably very busy.
|
| 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.
| james_in_the_uk wrote:
| As someone who receives lots of questions as a core part of
| my job, often concurrently via multi async comms channels, my
| biggest challenge is controlling cognitive load so I can be
| efficient and effective. Having a spot of politeness in the
| interaction, as the parent suggests, helps me meter the flow
| of information in my direction. I much prefer it. Horses for
| courses I guess.
| ivank wrote:
| Reducing the information content of a message, effectively
| concealing the information that you already plan to send
| after "Hi", isn't being polite to people with this
| personality, it's frustrating.
| james_in_the_uk wrote:
| Agree with this. Perhaps it's my British sensibilities, but I
| find it rude when people launch straight in.
| jon-wood wrote:
| I think there's a middle ground. "Hey, are you free to talk
| about Project X?" is a perfectly valid entry to something
| where you know an actual conversation will be needed.
| Likewise "I'm having trouble with the frobinator, when I run
| frob -x blah it gives me this error: XXX, are you able to
| help?" if you just need an answer.
|
| 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.
| nql wrote:
| I absolutely hate it when people send me a question that
| doesn't have the question. Now I have to pull it out of them,
| on their time.
| grayclhn wrote:
| Obligatory: https://www.nohello.com/
|
| 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. :)
| chihuahua wrote:
| Many people at $TECH_GIANT have www.nohello.com as their
| Teams status message. I love it.
| wizofaus wrote:
| Strangely I've found at my current workplace no matter how much
| time I put into preparing the initial message with detailed info,
| screenshots etc., it just gets ignored and we end up doing a call
| anyway. And to be fair it usually is quicker to resolve issues
| with a live/screen-sharing session, but obviously it relies on
| the other party's availability.
| WastingMyTime89 wrote:
| That's because talking to someone is always nicer than perusing
| error message. Plus it's a nice break. I am always a bit
| baffled by people who are full remote and want even less social
| interaction like if it wasn't already hard enough to somewhat
| get to know people when you never see them.
| wizofaus wrote:
| Actually I do agree with that, but...it's still annoying when
| you think you've done the right thing by providing all the
| information upfront and placing no expectation that you need
| the problem solved immediately, just to have it ignored.
| chihuahua wrote:
| It depends on how many interruptions those people receive
| during the day. If there's a question once or twice a day,
| the call could be a pleasant break. If it happens every 15
| minutes, the person being interrupted may not be able to get
| any work done at all.
|
| 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.
| jon-wood wrote:
| I work remote, and also have anything up to a full eight
| hours a day scheduled as meetings. Another video call really
| isn't a break for me, and I'm not suffering from a lack of
| social interaction at work. Throw an error message, nine
| times out of ten I'll be able to point you in the right
| direction after a quick glance at it, and by not insisting on
| getting on a call to talk about it you also get to avoid an
| exciting game of 20 questions about comparative availability
| of meeting times.
| NovemberWhiskey wrote:
| 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.
| lhorie wrote:
| > 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 wrote:
| 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.
| ok_dad wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| codingdave wrote:
| 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.
| galdosdi wrote:
| > 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 wrote:
| Neither of those strategies ever occurred to me. That is...
| Not encouraging
| Swizec wrote:
| > 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 wrote:
| 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 wrote:
| 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.
| hirundo wrote:
| > 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.
| onion2k wrote:
| _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 wrote:
| 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_ wrote:
| > 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.
| codegeek wrote:
| 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. :).
| _dain_ wrote:
| 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 wrote:
| 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.
| frozencell wrote:
| > 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 :)
| swatcoder wrote:
| 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 wrote:
| 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.
| bee_rider wrote:
| While it is annoying I can definitely see why _some_
| companies operate this way. I mean, if an individual
| customer is a large recurring revenue stream, then they
| should be strongly incentivized to keep them around.
|
| 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."
| sokoloff wrote:
| 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.
| Spooky23 wrote:
| 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.
| breischl wrote:
| 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 wrote:
| > 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.
| fn-mote wrote:
| > 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 wrote:
| 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.
| 2OEH8eoCRo0 wrote:
| 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.
| Aperocky wrote:
| This is why you have a bot to comment and reinforce the same
| language in the ticket if information are not explicitly
| provided.
| fezfight wrote:
| 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.
| sacrosancty wrote:
| 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 wrote:
| My favorite is the "Unexpected error". You know, because all
| the other ones are "expected".
| ryandrake wrote:
| 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.
| 9dev wrote:
| Weeeelp... I See both sides of this. There's some things
| you anticipate to go wrong, like a disk being out of space,
| or an API to not respond. Those are the type of things you
| can (and should strive to!) provide meaningful error
| messages for.
|
| 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.
| [deleted]
| SkyPuncher wrote:
| 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 wrote:
| > _At the point of contacting support, I 've probably already
| done my research_
|
| ... then you're already not part of the problem.
| renewiltord wrote:
| 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.
| EntropyIsAHoax wrote:
| I work on the Platform team at my company, and so we do a lot of
| internal tech support. It's a daily struggle to get people to ask
| good questions, provide details, provide links when possible,
| etc...
|
| 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
| jon-wood wrote:
| I see way too many questions in the Slack channels for teams
| that manage common services at work which are just "Is there a
| problem with [service]?"
|
| 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.
| thenerdhead wrote:
| I am more than willing to help if someone has shown the due
| diligence or curiosity.
|
| 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.
| nomel wrote:
| I pushed all of my support to an issue tracker, at work. The
| only requirement is to put a basic description of what's going
| on, the version that they're using, and include the error text,
| in full.
|
| 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.
| thenerdhead wrote:
| I've been there. I don't like barriers personally, but I do
| understand they can deter people to the point of the problem
| solving itself or at least the urgency of the problem.
|
| People will go through hell and back to not fill out a quick
| form for help.
| valenterry wrote:
| I thought the right way to get answers quickly is to ask them and
| post a wrong answer (under a different name) which will then
| cause people to correct you quickly :^)
| WastingMyTime89 wrote:
| I am going to strongly dissent on that one.
|
| 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.
| EvanAnderson wrote:
| Different people have a different "style" for this. I prefer to
| work people whose style is similar to mine. I think most people
| are the same way. That's all this comes down to, sadly. There's
| no formula to that will ever solve this mismatch.
|
| 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.
| KronisLV wrote:
| Working remotely day to day, I've seen some patterns of
| communication that feel like they could be slightly better for
| this mode of work.
|
| 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.
| burnished wrote:
| The pleasantries description feels out of alignment with the
| practice outline as an example. The good message still starts
| with 'hello', it just doesn't treat it as a statement that
| requires individual acknowledgement. Which is great, that
| practice is great, but I think the framing could use some work.
|
| 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.
| tpolm wrote:
| http://aka.ms/nohello
| KronisLV wrote:
| That is an even better link that I missed, thanks!
|
| 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/
| i_like_apis wrote:
| "Don't ask to ask" is also relevant for chatrooms:
| https://sol.gfxile.net/dontask.html
| sam_lowry_ wrote:
| No one said it better than Robert Sheckley in Ask a Foolish
| Question:
|
| https://www.gutenberg.org/ebooks/33854
| bananamerica wrote:
| It is regretable that a lot people takes these kinds of
| "questions manuals" as an incentive or an excuse to feel
| justified for being a total asshole.
| sacrosancty wrote:
| Yep. In general, advice on how to treat people better is often
| used as an excuse to be an asshole to people who aren't
| following it. Which is kind of ironic, really.
|
| 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.
___________________________________________________________________
(page generated 2022-08-31 23:00 UTC)