-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Request: Improving the support modal #21073
Comments
I don't think things like a character counter are great for a litany of reasons. Placeholder text is maybe an idea. But is there a common theme where people aren't providing enough detail? A certain cohort of users or a certain type of issue where this tends to happen? Regardless, less arbitrary requirements that will only aggravate our core audience, more of things that encourage them to give us what we need. |
I'm not set on this idea, happy to defer. We just want to get more detail from users up front. One alternative is that it's not a char limit, but instead a rolling encouragement as per Product Hunt? char.mp4
I feel more strongly that this is a good idea. I'm open to other solutions, but I think the alternative of adding discrete fields is more cumbersome and falls on the wrong side of the aggravate/encourage barrier.
Having shadowed support heroes for a little while it's clear that they often have to spend time looking through session replays and impersonating users to find where issues occur and that a lot of 1st replies involve asking users for more info. That's definitely a problem we need to solve, but I've not been able to see a trend in user groups here. Community questions tend to have less info, potentially, but those are also lower prio for us. |
Just had a chat with @slshults on this and he thinks adding in placeholders for the following could be especially beneficial:
|
Yes, what @joethreepwood said I said. 🙂 (placeholder text asking "what did you expect to happen?", "what actually happened?" and "the full and exact text of any error messages", could cut down on a lot of back-and-forth.) Other thoughts:
Possibly still-relevant thoughts I had while reading the related closed issue #17513:
|
Think we can close this out as all remaining discussion on it is on other issues. |
Is your feature request related to a problem?
I've been looking at support.
Part of that involved shadowing people who are support heroes.
One of the things that I noticed was that the vast, vast majority of tickets engineers get are only a sentence or two in length. Often this is fine, as we have session replays and stuff to help guide the engineer. Very often though, we have to go back and our first response is just asking for more information.
If we can ensure we get more information up front, that will potentially unlock a big speed improvement for support issues.
Describe the solution you'd like
The simplest solutions I think we can move forward with is:
The minimum character count should be low, so that it doesn't add too much friction. A 30 char minimum, for example, could help force users to add extra detail instead of useless "insight broken" or "can't log in" tickets. If a user tries to submit a ticket with fewer than 30 tickets, we could show an error to ask them to add more detail.
The placeholder text could be similar to the existing GitHub issue templates, so users know what sort of info we need. E.g., for feature request tickets we could show the following placeholder text:
For bug reports:
And for questions:
We could probably work on the copy, but you get the idea.
Describe alternatives you've considered
The other alternative would be more discrete fields. But I'd rather avoid that.
Additional context
@MarconLP has tried to solve this before, but feedback from @Twixes and @tiina303 led to this being closed. I'm hoping @PostHog/team-growth can help us find a solution we can move forward with.
Thank you for your feature request – we love each and every one!
No, thank you.
The text was updated successfully, but these errors were encountered: