Skip to content
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

Closed
joethreepwood opened this issue Mar 21, 2024 · 6 comments
Closed

Request: Improving the support modal #21073

joethreepwood opened this issue Mar 21, 2024 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@joethreepwood
Copy link
Contributor

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:

  • Introduce a minimum character count for support tickets
  • Add placeholder text for each of the three ticket types to help guide users in giving more information
  • Potentially update the 'upload image' guide text to encourage users to add images

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:

If your request is due to a problem, please describe the problem as best you can. 
Please also describe the solution you'd like to see, and any alternatives you considered.
You can add images below to help illustrate your request, if needed!

For bug reports:

Please describe the bug you saw, and how to reproduce it. 
If the bug appeared on a specific insight or dashboard, please include a link to it.

And for questions:

Please explain as fully as possible what it is you're trying to do, and what you'd like help with. 
If your question involves an existing insight or dashboard, please include a link to it.

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.

@corywatilo
Copy link
Contributor

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.

@joethreepwood
Copy link
Contributor Author

I don't think things like a character counter are great for a litany of reasons.

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

Placeholder text is maybe an idea.

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.

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?

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.

@joethreepwood
Copy link
Contributor Author

Just had a chat with @slshults on this and he thinks adding in placeholders for the following could be especially beneficial:

  • What did you expect to happen?
  • What did happen?
  • What errors did you see?

@slshults
Copy link
Contributor

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:

  • I agree that a minimum character count could be quite useful if we keep it low. If 30 chars seems high, maybe 20? (The number of characters in "broken. please fix." is 19.) Tickets with very little content like will cost more money as we scale, because at least one back-and-forth exchange will be needed to find out what the user actually wants help with. ("Help us help you" kind of a thing.)

Possibly still-relevant thoughts I had while reading the related closed issue #17513:

  • Paginating the form in the modal might reduce friction up front (but it also might just shift the friction to the subsequent pages. worth A/B testing maybe?)
  • "What area does this best relate to" could be confusing for newer users. The 'current url' sent to ZD by the support modal seems sufficient (but I defer to Marcus on that, since he's actually got experience with it, and I'm just a newb.)

@mariusandra
Copy link
Collaborator

I don't think a counter will increase the quality of the support requests we get. Perhaps only slightly, but at the expense of a yucky looking and gameable panel.

The better way is to align interests. It's in the users own interest to write a long message, since we'll be able to get back to them quickly. Do they know that? Should we just say it? As someone asking for help, if I was told "short message = 2 day round trip, long message = 8h resolution", I'd write a long message.

So is there a clean way we can integrate "the better your message, the better the service" into this panel?

image

Some thoughts

  • Under the response times: "These times are estimates and depend on how much context you give us"
  • When clicking "submit", always have one confirmation step/popup that asks "is your message detailed enough? [change] [send it]"
  • ...?

@joethreepwood
Copy link
Contributor Author

Think we can close this out as all remaining discussion on it is on other issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants