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?
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.
The task window includes two parts, the form area, and the action bar, similar to the other objects within the tool.
The title of the work item. A short summary of what is needed.
A more detailed description of the request. Exact action item for Tier II/III to take.
The team that the task is completed by.
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.
The date by which the task must be completed.
Used for logging total hours manually.
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).
A description of work done, including any notes that may be important.
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.
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.