Stanford Remedy Demo

On Monday, February 23, Santi, Jon, and Jai met with Tracy Neil, the Remedy ticketing system administrator, Chris Lundin, Director of the IT Service and Operations Center, and Adam, an employee at the Tier 2 IT Service Desk.  The purpose of this meeting was to further discuss the Remedy ticketing system as well as to present and gain feedback on another iteration of prototypes.  As a double bonus, we also got a brief walkthrough of the Remedy ticketing system and Chris offered to send some sample ticket data our way!

Probably the single biggest annoyance that Adam faces daily is user error when filling out and submitting a ticket.  This user error could be improper categorization of the issue which leads to a misrouted tickets.  Additionally, deficient user-written descriptions can make it nearly impossible for IT admins to determine what the issue is.  Even though issue reporting falls outside of our intended scope (ticket resolution), this observation gave us an idea.  A chat feature or at least an fast and easy way to contact the user reporting the issue would be convenient for the problem solver to find out more about the problem.

Another problem that occurs when using Remedy is that users forget to check the audit log, a log that keeps track of all the departments a ticket has been routed to, before re-routing a ticket.  Because of this, tickets sometimes get re-routed to the same department twice.  This made us think of providing a pop-up feature that warns when a ticket is about to re-routed to the same department.

When walking through our prototype, Chris and Adam provided some good feedback.  One important point was that routing a ticket to a specific person is usually not desired as it is against “etiquette”.  Routing a ticket to a group and then letting the group decide where the ticket should go is generally the desired behavior.  Additionally, many admins at Stanford use canned templates they send back to the user to help the user resolve an issue, so including this could be a helpful feature.  They also were not fans of our use of stars to denote priority, which we agreed with.  The last huge insight from the prototypes was that in order to get admins to post useful information and links for solving an issue, there needs to be some tangible benefit.  Or at least, they need to know that their work is helping others.  Chris suggested creating a good citizen score that would based on the number of people that found information an admin posted as helpful. We liked this idea a lot.

We left this meeting feeling good about our next iteration of prototypes while also ready to actually start some of the software development.  Oh and finally, we were going to have our hands on some data.