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:
- 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)
- 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.
- 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.
- 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.