Ticket Life-Cycle
1. New
A ticket is being created for the first time, or has been newly entered. This state usually means no one has 'touched' the ticket yet.
2. Assigned
Assigned is a state for when a ticket has been given to another team, but no one in particular is actively working on it.
3. In Progress
A ticket is to be in progress when someone is actively working on it. A ticket can go from new to in progress if the technician creating the ticket, is also the one working on it. To do so they can click "begin work".
4. Resolved
A resolved ticket is when all of the work is done. Users receive notification that their ticket is resolved, and can choose to close it, or mark it as not completed yet.
5. Closed
If a user is satisfied with the resolution of their ticket, or enough time has passed a ticket will enter a closed state. Once a ticket is closed, we generally do not reopen them. A user can enter a new ticket for new issues or requests.
*Pending
The pending state is where a ticket is set when we are awaiting something. This can be a response from an end user, data from a third party, arrival of an order for parts or software, or other things that would have us not actively working on a ticket.
*Reopened
The reopened state is for when a user chooses to reopen a ticket from the closure email. This state is similar to new/assigned but should be avoided where possible.
Incident vs. Service Request
An incident is when something is unexpectedly broken, or not working as intended.
A service request is a repeatable, and capturable request for a defined service. This means that there shouldn't be any surprises.
Incidents
The goal of incident management is to restore the agreed upon service to a level that is acceptable to the business unit and IT as quick as possible.
That's a lot of words to say, fixing whats broken!
The reason we use that specific language is because restoring the service may not always be as simple as 'break fix'.
As an example: our resolution to an incident where a user reports that their printer is broken, may be to temporarily help them connect to another printer (restoring the service of printing) while we dispatch a tech to troubleshoot their usual printer.
An example of a service request: is someone requesting a new laptop. ITS provides computer equipment on a periodic basis to all eligible FTEs, in order to provision one we need certain info such as account numbers, the specific computer configuration, and information about the user's eligibility. Because we know what we need to fulfill this request, and it is routine, we can capture that info as a service request.
Emailing Customers
If you are not the Communication Team
In Cherwell, your team may not own a ticket, but still receive a task on a ticket. In those cases you may not need to directly communicate with the end user.
If your team is handling a task, and you need more info to complete the task, feel free to complete the task and fill out the resolution details of that work-item with your request for info. The communication team can then work with the customer to get the info you need and then they can create an updated task that has what you need to get your work done.
If you are the Communication Team
If you are the communication team, e-mailing the customer is as simple as clicking on their e-mail address in the Information Bar.
Ticket Workflow
We covered the Status options for a ticket, but why does this matter?
This flow chart covers the ticket lifecycle and its order, but also when to work on it throughout its lifecycle