How Stages Work

Stages are designed to model the flow of work a business performs to process support issues. They are defined by desk definition. One stage is defined as a Begin stage and multiple stages can be defined as an End stage. There are usually several Middle stages.

Stages are sequenced by selecting one or more "to" stages. The sequence of stages is user-defined. It depends on the policies defined by the service organization and the judgments of individual users using the system. A sequence of stages is graphically represented by the View tab within a desk definition.

An event procedure runs as soon as a ticket transitions from one stage to the next. A scheduled procedure, such as an escalation procedure, is triggered to run based on how long a ticket remains in a stage. For example, escalation procedures typically run when a ticket has remained too long in a stage, instead of being resolved and moved to another stage.

When a desk definition is created, stage sequences are populated by the template used to create the desk definition. Once a desk definition is created based on a template, these default stages can be modified to suit your business requirements.

Example - The Stages of Customer_SD_Automation

The description of each stage below assumes the VSA users discussed are not Service Desk administrators, and so have their views of tickets limited by their user role and scope.

Note: See the Desk Templates topic for instructions on how to create this and other predefined service desks automatically.

New Ticket - A newly created ticket in Customer_SD_Automation starts out in the New Ticket stage.

• A CS Incident enters New Ticket stage entry procedure assigns the ticket to a Tier1Support pool of service ticket technicians. VSA users see any tickets assigned to them, plus any tickets assigned to pools they belong to.
• A VSA message and an email message is created for these same users. The submitter of the ticket is also sent an acknowledgment email that a ticket has been created.
• An escalation procedure is linked to this stage. If the ticket has not been moved out of the CS Incident enters New Ticket stage within 1 hour, the escalation procedure runs. The escalation procedure notifies the assignee of the ticket and the Tier1Support pool of users. The intent of the escalation procedure is to ensure that all newly created tickets are reviewed immediately.

Two other factors can automate the behavior of tickets at any stage:

• Automatic Ticket Assignment from a Pool - The first time the ticket is opened by any member of the Tier1Pool, that member is assigned the ticket. Other members of the Tier1Pool no longer see the ticket in their view of tickets.
• Ticket is Changed - This not a stage, but a Ticket Change procedure. The same CS Incident is Changed procedure is run each time the ticket is saved, even if a minor change to the ticket does not include switching the stage. This ticket change procedure tests for the following:
  • If the ticket is new, the ticket is immediately moved to the Tier1 stage.
  • If the ticket has an assignee, the assignee also becomes the "owner" of the ticket. An owner of a ticket typically continues to be responsible for the ticket, even if the ticket is assigned to a series of different assignees over the course of its life cycle. Ticket views can be filtered by owner, enabling owners to manage tickets that may have been forgotten about by their current assignees.
  • If the ticket has been solved, the ticket is closed.
  • If a ticket was already closed, but a customer sends an email referencing the ticket, the ticket is reopened.

Tier1 - The assignee of the ticket is now tasked with working with the ticket in the Tier1 stage.

• The assignee is sent an email message.
• An escalation procedure is also linked to this stage.
• A ticket can be manually assigned to either the Tier2 stage or the Solved stage, as indicated by the two red arrows coming out of the Tier1 bubble in the graphic above.

Tier2 - Moving a ticket to the Tier2 stage typically means the ticket requires a person with more experience to resolve it, perhaps providing a special area of expertise.

• A CS Incident Enters Tier2 stage entry procedure automatically assigns the ticket to a Tier2Pool of users, so that Tier1 personnel don't have to guess who to assign it to.
• A VSA message and an email message is created for these same users. The submitter of the ticket is also sent an acknowledgment email that the ticket has been assigned to the Tier2Pool for further investigation.
• An escalation procedure is also linked to this stage.

Solved - Resolved tickets are sent to this stage to wait for acknowledgment back from the submitter after being notified.

• The CS Incident Enters Solved stage sends the submitter an email notification that the ticket has been resolved.
• Solved tickets are either re-opened when the customer sends back an email reply, or the customer is never heard from again. Eventually the ticket is manually closed.

Closed - Resolved tickets are set to the Closed stage.

• The CS Incident Enters Closed stage entry procedure notifies the submitter of the ticket that the ticket is closed.