what should an “ideal” support ticketing system provide?
January 9th, 2015
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?
