We’re about to start writing a feature for a ticketing system currently implemented in Rails.
I want to be able to provide approximated matches for the current ticket being opened, based on existing answers/knowledge base. This feature would display, based on the contents of the current ticket being submitted (subject and body). Those matches would then be displayed and the user could opt to pursue one of the suggestions and ignore them and continue submitting the ticket.
I am looking to achieve two goals with this:
- in our end, lowering submitted ticket volume and therefore lowering support staff load, and;
- in the customer’s end, making the answer turnaround time lower for simple and common asked questions.
One thing I don’t want to do is disallowing the user to submit the ticket like some ticketing systems do, just present options and let him/her decide.
I look for advice in terms of:
-
General implementation design of the solution, like what kind of tables you would use to back up the answers database, using real responses from previous tickets or a separate knowledge base, or a mix of the two and;
-
Implementation details like helpful Ruby and/or Rails libraries that you think would help me writing this portion of the app.
Just keep in mind that the ticketing system already exists and works today, and we can’t rewrite it, just add this new feature to it.
EDIT: Someone suggested me offline (in Twitter) that they hate suggestions when opening ticket, so I am thinking of offering a “don’t suggest me anymore” feature as well.
I would look into using Apache Solr + the Sunspot gem, since this problem sounds a lot like generalized full-text search.
Do you have search functionality over existing tickets + knowledge base articles already? If so, a basic “Related Tickets” implementation could be retrieving the results from a search using the body/title of the ticket. How to tweak Solr to give the most relevant results totally depends on your data.