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.

Prototype V2 Demo

On Tuesday, February 17 at way too early in the morning (9:00 am) we met with Stephen Wong, the Director of IT at the Graduate School of Education.  Despite the team’s collective sleep deprivation, this was an extremely fruitful meeting as we learned about the ticketing system in place at Stanford (Remedy) and its annoyances, we discovered that there is a need for a smart ticketing system like the one we were prototyping, and we were given another contact within Stanford to discuss our ideas with further.

After introductions, Stephen briefed us on IT in academia and its difficulties by touching on the many different layers as well as the discrepancies in IT departments due to budgetary differences.  After this, Stephen told us about Stanford’s ticketing system — Remedy.  There were many important takeaways from Stephen’s discussion of Remedy.  First, the most common problem in issuing tickets is the routing of tickets to the wrong group.  Once assigned to a group, tickets are hand assigned to a particular person.  During our earlier brainstorming, the team had come up with the idea of auto-allocating tickets.  Stephen pointed out that this is an extremely difficult problem as there are hidden personal and political factors that go into assigning a ticket.  For example, tickets from certain faculty members who are known to be difficult to work with are assigned to IT personnel who are very patient.  Another idea that we thought of during brainstorming was automatically assigning a priority to a ticket based on learned features extracted from the ticket.  Stephen grounded us once more by mentioning the difficulty in this task.  With ticket prioritization political factors heavily influence the order in which a ticket is resolved.  For example, if the person who submitted the ticket is the dean or someone known to complain a lot, the ticket is handled quicker.

Despite finding out that two features we were excited about after brainstorming would be too hard to implement, we were not discouraged.  After elaborating more on our ideas and beginning to show the prototypes that Santi drew up, Stephen mentioned that to his knowledge, a system that learns from previous tickets does not exist and it would be pretty awesome for a system to automatically suggest resolutions.  This was extremely good news to hear!

After walking Stephen further through the prototypes, he pointed out some key insights.  First, many IT workers rely heavily on Google when troubleshooting so providing the ability to search Google and retain helpful links would be a great feature.  Additionally, Stephen mentioned that issues fall broadly into two categories: problems that are quick fixes taking less than 5 minutes to resolve and problems that the IT worker doesn’t immediately know how to fix and require more than 5 minutes.  If a problem fell under the 5 minute or less category, Stephen was a firm believer that the ticketing system should be as unobtrusive as possible allowing the user to dedicate his time to solving the problem and not navigating some feature-filled pages.  For problems requiring more than 5 minutes to solve, Stephen believed more information could be extremely helpful out streamlining the resolution process.

At the end of the meeting, Stephen put us in contact with Tracy Neil, the Remedy Administrator, another excellent person we could pick the brain of to advance our project.