USD Best Practices

Ticket Documentation

1. Information obtained from the customer upon ticket creation should include enough information to be actionable by the receiving analyst without the need to contact them for additional information. 
2. Closing comments should fully detail what was done to resolve the issue.  Closing comments are often utilized to determine ticket ownership, identify recurring issues, and provide resolution steps.  Consistently listing detailed closing comments will reduce the number of easily resolvable issues routed to second tier support groups.
3. By default customers are notified via email on ticket creation and closure.  Well written and grammatically correct text helps to present the department’s professionalism.
4. When work has been performed on a ticket it should be documented utilizing the ‘Log Work’ feature available from the ticket’s Activity window.   When a customer is notified by external email or via a phone call it should be tracked using this feature.
5. Additional information provided by the customer after ticket creation should be documented utilizing the ‘Log Comment’ feature available from the ticket’s Activity window.
6. When transferring a ticket to another group or analyst the reason for the transfer should be thoroughly articulated.
7. Incident tickets should be updated within one business day of the task being completed.  Request tickets should be updated at a minimum of once per week.
   

   ---

Priority Assignment

1. When creating an Incident within the system utilize the Impact and Urgency to determine the appropriate Priority.

2. When creating a Request or Change order assign the ticket Priority based on the Priority Definitions policy.  The Priority Definitions policy can be found at https://home.mcis.washington.edu/amcis/services/sla.asp.  If there is any doubt or question on priority assignments refer the ticket to the IT Services Help Desk.

3. Incident priorities are set based on the customer impact and urgency as listed on the SLA definitions webpage.   Impact and urgency fields should not be artificially raised or lowered to adjust the perceived response time or default activity notification method.  If a response rate is required that is outside the defined SLA the receiving analyst or group oncall should be contacted for escalation coordination.
   

   ---

Closing Confirmation

Confirmation from the customer that an incident has been resolved should be obtained before closing a ticket.  In the event that the customer does not respond after repeated inquiries it is permissible to close a ticket after giving adequate forewarning that details what is being done and why. 

Critical Incident Help Desk Notification

Critical Incidents by nature are urgent and affect the UW Medicine organization in its entirety.  This class of Incident typically requires the initiation of downtime procedures which may include mass notifications, updating customer facing voice response, and conference call coordination.  When a critical Incident has been identified report it to the Help Desk by phone at 206.543.7012 as soon as possible.

Group Ticket Queue Management

The manager of each group is accountable for maintaining their ticket queue.  Queues must be monitored diligently to prevent tickets from being open in the queue without receiving attention.

Ticket Transfers

1. A formal communication must take place to agree on the transfer between the original owner of the ticket and the new assignee; this can be done via the Comments section within the ticket (preferred), email, phone, or direct conversation. 
2. If there is a question regarding the appropriate category or whom the ticket should be transferred to, you should refer to your group manager for a decision.  If it is still unclear then direct the ticket back to the IT Services Help Desk for the correct assignment.
3. If a there is a disagreement about a misrouted transfer the first step is to discuss the issue with the original owner.  If it cannot be resolved escalate it to your group manager for a decision on who should own the ticket.  Until the disagreement is resolved the new assignee remains the owner of the ticket and has the responsibility to contact the customer and tactfully let them know that the issue is being addressed.
   

   ---

Escalations

Tickets should only be escalated if, after an assessment, an issue is determined to have a broader scope than first thought (Server Down, Network Outage, More customers affected).  Conversely, tickets should be de-escalated if the impact is less than originally conveyed or at the request of the Affected End User.