HACKER Q&A
📣 jernkalv

What is the best way for Technical Support to submit bug tickets to dev?


I recently took over the management of our technical support team. We're primarily a web-based team. We have a number of web products, ranging from a CRM tool to some APIs via AWS.

I'm wondering, for any of the IT Managers, Developers, Product Owners or Engineers out there, is there a set of best practices for submitting bug/ER tickets to engineering?

Our goal will be to decrease as much friction in the ticketing process as possible.

We'd like to know what to include on bug tickets. What can we provide so engg. can hit the ground running?


  👤 DrScump Accepted Answer ✓
What conceptual model are you using?

Where I used to work, we wanted a process by which problems, or apparent problems, with products could be submitted by anybody in the company with any sort of a technical nexus, including technical support, pre-sale support, technical publications, field consultants, QA, and r&d itself.

We came up with a bug database system that provided two pathways for conceptual problem reports to be accepted as bugs. R&d itself could enter bugs directly for products within their own purview. For the rest of the company, however, we would we wanted some filtering and independent analysis before necessarily accepting an unexpert opinion about an apparent misbehavior to be logged as a bug directly.

Therefore, we had a parallel problem reporting system that was available to all technical personnel outside of r&d. Problems would be evaluated by technical support and or r&d personnel before being escalated to a bug. Also, since a given bug could reveal itself in more than one apparent misbehavior, multiple problems could map to a single bug.

When there was any contention as to whether an apparent misbehavior was to be accepted as a bug in code, in documentation, or to be dismissed as a misinterpretation on the part of the customer and/or the reporting party within the company, the issue came before a Bug Committee which included representation from Support and R&D (at least). Then, it could be escalated to a bug or closed.

The benefit of this dual-path model was that there was a low-friction process that would capture problem reports from a broad population and document them for everyone to see paired with a more formal and rigorous process to identify, documents, and track agreed software defects.

Bug entries would include a source control system reference for each affected source version tree and comments by the fixer(s).