***WORK IN PROGRESS***

This article outlines the expectations for working tickets from the DISPATCH report in TeamDynamix. The purpose of DISPATCH is to be a central hub for tickets coming into TeamDynamix. Working tickets in TeamDynamix is like that of a traffic controller; making sure tickets go in the right direction and get to their destination. Below you will find common information when moving tickets out of the DISPATCH report.

NOTE: When assigning tickets, always assign to a TEAM, rather than an individual. If an individual is out of the office, they may not see the ticket and it will go untouched until they return.

Sensitive & Restricted Data

Many times, customers will put sensitive or restricted data in their email to it@purdue.edu. This could be a PUID, password, social security number, credit card information, etc. When this ticket comes into DISPATCH, the Service Desk needs to remove this information before moving the ticket along. This can be removed in the 'Description' Field after pressing 'Edit' on a ticket. If a customer replies to a ticket with a comment containing sensitive information, the ticket will need to be recreated without the sensitive information on the user's behalf. The original ticket will need to be sent to IT_PWL_ITSMO for deletion.

To remove this information, highlight the sensitive or restricted information and overwrite it with the word 'REDACTED'. Once this information has been removed, you may continue to work the ticket.

Assigning Tickets

Tickets should always be assigned to a team only and never to an individual. This way, anyone on a specific team will receive notice of the ticket, not just the individual. If that person is out of the office, the ticket will go untouched until they return to the office.

Ticket History to assist in identifying appropriate team

A (perhaps the) primary concern of ticket dispatch is the identification, assignment, and distribution of tickets to the appropriate team. The first thing to look at is the ‘History’ tab of the ticket. On this tab, you can locate the email address to which the ticket was originally sent (aka the ‘To:’ entry), as well as other information about the user that may assist in appropriate dispatch. The screenshot below shows a ticket that was in the dispatch queue and was addressed to itap@purdue.edu.

Although they appear in the general dispatch queue, this ticket was initiated by the customer as a Krannert Computing Center request (kcchelp@purdue.edu).

This ticket was addressed to CLA IT (ithelp@purdue.edu).

The History tab also provides useful information that may assist with determining the ultimate assignment of the request.

This user's department is College of Liberal Arts (CLA), and they are classified as faculty (this information can also be found in the "Contact" tab). Depending on the nature of the request, it would be appropriate to expect this ticket to be dispatched to CLA support (ITAP_CLA_SUPPORT) if the request is not something handled by the CSC directly, or ITaP generally.

If the nature of the request, or how such a request is fulfilled, is unclear or unknown, it will either be escalated to the ITAP_CSC_REPRESENTATIVES queue or the ITAP_CSC_SPECIALISTS queue based on the customer's affiliation. This information can be found on the Contact Information tab.

For Faculty and Staff (excluding those related to Krannert), assign tickets to ITAP_CSC_SPECIALISTS.
For tickets originating from kcchelp@purdue.edu, involving Krannert or KCC services, or requesting assistance from Krannert IT (KCC), assign ticket directly to ITAP_KRAN_HELPDESK
NOTE: Staff listed with the Position Title Student Service should be assigned to ITAP_CSC_REPRESENTATIVES.
For Students, assign tickets to ITAP_CSC_REPRESENTATIVES.

Categorization & Priority

Tickets are to be categorized based on the customer’s explanation of the issue. The recommendations for Category and Services fields are documented in the attached PDF in KB Article #791500. This document includes descriptions for Category and Service, along with examples of associated Service Owners and Technology.

Urgency and Impact fields should reflect the current understanding of the issue and can be updated as the situations warrants. More information can be found in KB Article #724547.

Issues of a time sensitive nature need to be indicated as such using the Priority Increase field prior to being dispatched. Examples of such issues:

“I need this by tomorrow.”
“We are giving a presentation next week.”
“This is scheduled for 9:00am on Thursday.”

**Compromised Account/Password Scrambled: username [STEAM-CIRT]**

For dispatch tickets with the above label:

Apply the CSC.Steam Cirt quick issue template
Clear the Contact Information currently in the ticket and replace with the username found in the Title of the ticket
On the Assignees and Notifications tab, remove any CC: on the ticket

Voicemail

When customers leave a voicemail after calling 4-4000, a copy of this message is sent to itap@purdue.edu and it generates a ticket. These voicemail tickets will come into DISPATCH. As such, the attached message should be listened to, with a description of the issue written up in the tech notes, a brief description updated in the ticket title, and the customer information updated, if possible. Please precede these ticket titles with "VM - " to indicate that it is a ticket that originated as a voicemail. Ex: "VM - BoilerKey setup"

SPAM

Occasionally, emails/tickets will be generated that are spam. These tickets are not usually submitted using a Purdue Career Account (i.e. sent by a random email address). Most of them are pretty obvious that they are spam, but if you are ever unsure, follow up with leadership.

To label a ticket as spam, open the ticket, then apply the PM.CSC SPAM quick issue template.

Returned Tickets

If a ticket to returned to Dispatch for the CSC, the original Representative or Specialist TEAM should be assigned as the owner and then dispatched from those queues as appropriate.

AgIT Tickets - Ticket types with exceptions from normal protocol

Since the CSC functions as Tier 1 support for AgIT users, we will often have AgIT tickets in our system.
However, just because a ticket is FOR an Ag user, doesn't mean it's an AgIT issue. It's the ISSUE that makes it an AgIT ticket, not the user.
For example, an Ag user with a BoilerKey issue, is still a BoilerKey issue. An Ag user with a Password issue, is still a password issue.
For the most part, unless the issue revolves around an Ag specific piece of hardware, Ag specific piece of software, or some sort of Ag managed service... probably still a CSC issue and should be categorized as such.

Here are some examples of 'Ag Issue' tickets, and how they should be handled:

"Avecto Privilege Guard - User request for application"
- This is a request by an Ag user for an Ag piece of software to be installed on an Ag machine (Ag issue)
- Classify it as: IT Professional Services >> Training & Consultations >> Technical Support
- Assign to ITAP_CSC_SPECIALISTS
Some form of a Quicken issue reported by someone from a County Extension Office
- Quicken is the software used by the County Extension Offices to manage their finances (Ag issue)
- Classify it as: IT Professional Services >> Training & Consultations >> Technical Support
- Assign to ITAP_CSC_SPECIALISTS

Browser not supported