If you were going to create a support ticketing system from scratch – what would you put in it?
My initial list of needs (some of which derive from my book, Debugging and Supporting Software Systems, and other from my experiences in ticket smashes):
- “long” title support (HP truncates at 80 characters – give me at least 255)
- “long” field update support (HP truncates at 4k characters – that’s not enough for some stack traces)
- clear contact fields for both filer and support case owner
- allow updates to be made via email or web ui
- allow attachments (for log files, screenshots, etc)
- have “private” updates visible only to support personnel
- clear date/time stamps for updates
- ability to turn case “result” into a KB article
- clear resolution field
- web ui should be highly responsive – and run usably on any modern browser (mobile, desktop, tablet, etc)
- ability to cross-link to other cases filed by same customer
- clear indication of who has made updates (maybe alternating colors for customer vs support updates?)
- as few hoops as possible to open new cases & to update existing ones
- simple way to close a case if you’re the opener
- easy means to transfer ownership of a case – both for the customer and for the support technician
- ability to search previous cases – both for customers and engineers
What else would you add? What would you change?
Ability for the customer/person responsible for the bug to reject a proposed fix or suggestion to close as being insufficient.
Integration with the backlog of other development work (i.e. if a bug is created, it should show up as new work in the same place as new feature requests).
Ability to combine reports (for de-duping or grouping of related issues).
Though I think bugs and support cases should be separate, there does definitely need to be ties between them.
to quote my friend Steven (http://theexceptioncatcher.com/blog), “an easily-accessible API for interacting with other tools”