Ticket Assignment & Escalation
While a ticket can be assigned to a team for processing, we ask that you use the following paradigm when considering who should own a ticket.
The owned by team should be the team controlling the communication. This will most likely be your tier 1 team. For most cases this will be the Service Desk. The reason for this is a best practice called the Single Point of Contact.
A major issue with many IT departments is that by assigning tickets, and putting the onus of communication on higher tier teams is:
- Users learn who is completing their tickets, and start to skip right to those tech emails, losing reporting and tracking data, and making it very difficult to plan for demand.
- Time is taken away from those teams who are very busy.
- Communication is inconsistent.
To help mitigate this, we are asking that Team ownership and Technician ownership be the team or person who will be the primary communication desk.
How will you receive work?
Cherwell Tasks
Using the aforementioned Service Catalog Templates, and manually generated tasks, we can better track the work that we are doing within the tool. Tasks represent finite increments of work that can be tracked as a process within a larger ticket.
A major difference between tickets and tasks, is that tasks can have both upstream and downstream dependencies. This allows us to automate and capture complex workflows, and to better manage resolution to tickets that interact with many teams.
ex: if we want to get someone into ARGOS we might create an overall ticket to track the request, but tasks for the service desk to help them install the plugin, and to the Enterprise team to provision the access.
Task Object
The task window includes two parts, the form area, and the action bar, similar to the other objects within the tool.
The Form
Title
The title of the work item. A short summary of what is needed.
Description
A more detailed description of the request. Exact action item for Tier II/III to take.
Assigned Team
The team that the task is completed by.
Assigned To
The individual who will be completing the task.
Scheduled Start Date
If a task has a specific start date that is important to its fulfillment it can be captured here.
Due Date
The date by which the task must be completed.
Hours Worked
Used for logging total hours manually.
Close Code
The resolution of the task: completed (work was done), declined (I or my team will not do this work), reassigned (this task should goto another team), withdrawn (we no longer need this).
Completion Details
A description of work done, including any notes that may be important.
Status
As with many other objects in Cherwell, a task has a life-cycle. To begin you will want to choose acknowledge, you can then set it to in progress, then closed.
Actions
Assign to Me
Take Ownership of the current task.
Link to Upstream Task
Link task as a dependency to another task.
Add a Downstream Task
Create a child task that depend on this task.
Visualize Task Dependency Workflow
Visualize the workflow and critical path.