Do community members do more than paid staff on Ask?

Really appreciate hearing all of your perspectives. We think a lot about how to make support as effective as possible and ensure users can get the help they need, but it will never be perfect, and so are constantly iterating to make it better.

On this topic, we just welcomed the wonderful @yerhot to our team to lead Support (Please welcome him and say hey! He’s doing cool stuff!). We’ve been brainstorming how to improve Support and thinking about how Ask fits into it, so stay tuned!

7 Likes

My own philosophy is similar, @whileTRUEpass!

Also agreed @9pfs1.

I def do not have a full answer or solution yet but do have some thoughts:

  1. Replit is for the users and our goal is always for folks to be able to talk to Replit support with as little friction as possible. Full stop.

  2. We are actively working on improving how we manage the bug report /feature request/question when it gets to us. Kinda like you talk to us => <stuff happens> => feature ships/bug fixed/problem solved. As Replit has gotten larger, both internally and externally, => <stuff happens> has become more complex for us. I suspect part of what y’all are feeling is a byproduct of this.

Some of #2 means we may need to change a little bit of how you talk to us works so that changes to the rest of the chain work and the whole thing is ultimately better/faster/more efficient/doesn’t fall over. That chain being efficient is in everyone’s best interest IMO.

I do not think anyone should read that as anything super drastic, but just an honest yeah Support wants it to be better too and we’re working on it. It’s going to be an ongoing thing we work on.

:v:

Side note: I absolutely adore that folks care so much that discussions like this happen.

14 Likes

Hi everyone, I greatly appreciate all of the responses. Apologies if I made it sound like Replit’s staff team did not interact with the community enough or their work was insignificant compared to the work that community members put in.


I personally feel the same way. However, people like @ShaneAtReplit and @IanAtCSTeach do take time to reply to these users and contact people that are able to fix these problems and provide support from the staff’s side of Replit. A good solution would be to have a Replit bug tracker separate from Ask, but I also feel that the rate of new Ask users would go down significantly if something like that was implemented.


If I am understanding this correctly, I feel like you talk to us should be simplified compared to what it is now (currently its @not-ethan or a TL4 pinging a Replit higher-up and getting problems solved, but it would be nice if there was a direct way to contact Staff members with bug report cases instead of a ping, which should make the process much more efficient and a lot nicer on mods/staff notifications :smile:)


A few ideas to make support a bit easier from a community member’s prespective:

  • A bit of inside on what the Replit team is currently working on and what bug’s are in the process of being fixed (maybe should be reserved for higher community members, because I bet some stuff isn’t known to the general public, and maybe under an NDA or something if really necessary. It would be nice to know what is in the process of being worked on/fixed though)
  • Easier way to ping staff members regarding bug reports and billing issues (see above)
  • Automatically notify staff members when a bug is recorded on Ask?
  • Make it much easier to contact Replit staff directly (some things on replit.com/support are not listed, and most options just direct to Ask even though we don’t have the power to fix some issues), I believe you can contact via contact@replit.com but I don’t think I’ve ever seen a mention of that on the main site

Sorry that this doesn’t directly relate to the OP, but it should make community and staff members’ lives a lot easier if some general improvements are made to support as said by many users.


Even though Ask users do provide most of the support for Replit, if Replit replaced us with an actual support team we wouldn’t really have much to do :laughing:. A lot of forums also are very similar to Ask, community members provide support for other users until they can’t, and a staff member steps in to finish the rest of the job, so I can’t say staff members don’t provide support at all.


My final thought: It would be nice to have some sort of mention on the main site, not even benefits but just acknowledgment of our involvement in the support community or something. Staff members get special badges, so why not give active Ask members a badge of some kind too?

Regardless though, Ask would not be anywhere near as active as it is today without staff members’ involvement, and I really do have a lot of respect for those who go out of their way, take time outside of their working hours (or put their current work on hold) so they can interact with the community and relay information.

10 Likes

Tickets are already automatically made internally but due to the quantity it takes some time.

2 Likes

There should be a separation between support as in platform issues and support as in programming or platform usage issues. The former should not be in Ask in my opinion, while they are today.

7 Likes

Hey all!

I’ll chime in here with hopefully some new context on these questions/ideas/etc. I would be happy to clarify anything directly, but for this first post, I’ll write down my current thoughts just to get on the same level.

I have been on the Replit Support Team for 2 years now and have seen it change drastically. We started out using an in-app support form that went to a shared email inbox tool. From there, we would go back and forth with the user via email. Once we had enough info to reproduce the issue, it would be sent to the team. And, for a while, this worked fine. However, the time it took from a user submitting a report to an actual engineering ticket being created (reproduced & triaged) was a while. This was due to many factors, but boiling it down, here are the ones that stood out:

  1. Communication was via email. Users either didn’t know that we had contacted them in the first place or the process itself was slow and unreliable (email delivery issues for school users)
  2. Everything went through the support team, ticket by ticket. If there was an incident, we got a flood of emails we needed to respond to and keep track of.
  3. The reports and resolutions were not public. Like #2, users relied on us to see, reproduce, and resolve their issues. Other users didn’t know if others were seeing the same issue or how it was solved.
  4. Due to the low-quality bug reports, we usually started 99% of our email threads with “send us the Repl link” or “send us a screenshot”. This significantly slowed down the process.

Now, with all of these issues, we slowly improved the workflow but were still tied to the email inbox. We explored building our issue tracker website, but after weeks of planning, building, and testing, we hit a wall where the time investment was too much for us to build on our own. We decided to explore other existing options for public issue reporting and resolution.

We noticed that Teams for Education reports were already coming in from Discourse, so we talked with the Community team to expand the scope of our forum to encompass all bug reports and feedback. Since we made the switch, the entire process had better efficiency and speed. All of the points made above were fixed. We didn’t need to waste time by asking users to follow directions. Instead, we could dig deeper into issues and give engineers better tickets.

With that pickup in efficiency, the engineers could pick things up quicker and solve issues faster. Plus, if the community knew a solution to an issue, they could simply jump in and solve the report without Support ever needing to intervene and involve engineering efforts if they weren’t needed (e.g. Nix or Framework configuration).

To conclude, we are always advocating for better methods of providing support, but we don’t really want to take any steps backward that could potentially penalize the efficiency and speed of our workflow.

12 Likes