Ticket State Model

This topic presents the SQI process model for Ticket states. The process model is layered. Initial usage can implement the basic "support track". Over time additional tracks - bug and feature request - can be implemented.

The process model also covers activities outside of the day-to-day support engine interaction with IM. These include spam detection, processing and garbage collection.

Basic "Support Track" Process Model

As a new Request arrives a Ticket is created. During the support cycle the Ticket moves through a number of States. Each State identifies a specific milestone in the resolution of the Request.

The left side of the state diagram below shows the basic "support track" state flow: New to Open to Resolved. Each state is described in the text on the right. An additional state - Verify - is also presented for organizations that want the client to confirm the resolution of the issue.

Figure #: Description

• New
  

  • The Ticket is automatically placed in the New state by IM when it is created.
    
    Operational Note: A ticket in the New state has been entered into IM but has not been responded to by the support staff. Thus, to be responsive to the client, it is important that Tickets not remain in the New state very long.

• Open
  

  • The first response by a support staff member changes the status of the Ticket to Open.
    
    The Ticket remains in the Open state as the support staff and the end user correspond on the incident. This process may involve many interactions or may be resolved with the first correspondence from the support staff.
    
    When the support staffer sends the final correspondence to the end user that staffer will also change the Ticket status to Resolved or Verify.

• Resolved
  

  • The Resolved state signifies the Incident is closed and will not be worked any further. Resolved does not imply that the client is satisfied or not satisfied, simply that the Incident is closed. The client would most likely be satisfied by receiving a bug fix. On the other hand, a response that the issue as hand is a basic design feature that can not be change may close the issue but not satisfy the client.
    
    Operational Note: If a Ticket in the Resolved state receives an additional client response, the Ticket's states is changed back to Open.

Expanding the states to track the client interface process in more detail is normal as the organization becomes familiar with the IM proceeds. The Verify state is frequently the first addition. The Verify state provides the means to get direct client conformation hat the Incident is resolved.

• Verify
  

  • This state gives the client time to test the fix. If no client response in 3 weeks the Ticket is automatically moved to the Resolved state.
    
    

    • Operational Note: The New-Open-Verify-Resolved track is usually used only for complex problems where the final resolution could be an issue of interpretation or field testing. For simple incidents, such as a basic help request where there is little question of resolution, the New-Open-Resolved track is used.

"Software Modification Tracks"

The Ticket state diagram below adds "Software Modification Tracks" - "Failure Track" and "Feature Request Track." Each track deals with an Incident that requires a change to the software. The Failure Track is used when critical software failures require an immediate patch or fix be release to the client. The Feature Request Track is used when the software modification or enhancement is done as part of a normal release process.

"Failure Track"

The Failure Track introduces Ticket states to track the progress for the point that a software failure is established to the fix being verified by the client. In the SQI process model a software failure is different than a software bug. The software failure is specific to a client and that clients execution steps that create the failure. A software bug is the root cause of the associated software failures. Thus many failures can map to one bug.

• Open

  • The Failure Track branches from the basic support model at the Open state.

• Failure

  • A Ticket's state is changed to Failure when the support engineering staff can reproduce the problem. Prior to that point the problem is held in an Open state. Even if it seems very clear that a software problem is the probable cause the Ticket is not classified as a Failure until all external influences can be ruled out, i.e. the problem can be reproduced within a controlled environment.
    
    

  • A Failure is mapped, and in most cases linked, with a bug in the engineering bug database. A Failure can point to only one bug, but a bug can have many Failures mapped to it.

• Fixed

  • A Ticket's state is changed to Fixed when engineering believes it has developed the solution to the bug. This is an "internal" state used to make the client aware of progress.

• Released

  • A Ticket's state is changed to Released when the patch or update with the software fix is released to the client. Because of release policies there may be a significant time gap between the Fixed and Released states.

• Verify

  • The Ticket state model now rejoins the basic support process model.

"Feature Request Track"

The Feature Request Track introduces Ticket states to track the progress of a new feature request from the point of the request to a client verifying the feature works.

• Open

  • The Failure Track branches from the basic support model at the Open state.

• Feature

  • A Ticket's state is changed to Feature when it is determined that the request does not involve understanding how to use the product or a failure of the software but in fact a request for a new feature. Moving a Ticket to Feature status does not commit to the client that the requested feature will be implemented.

• Scheduled

  • A Ticket's state is changed to Scheduled when the requested feature is scheduled into a future release of the software. This is an "internal" state that is used to communicate progress to the client.

• Released

  • A Ticket's state is changed to Released when the patch or update with the software fix is released to the client. Because of release policies that may be a significant time gap between the Fixed and Released states.

• Verify

  • The Ticket state model now rejoins the basic support process model.

Full Process Model for Ticket States

The full Ticket state process diagram introduced "administrative" states to the basic, failure and feature tracks presented above. These state effect are associated with the system function and not the day-to-day support functions.

• Spam

  • A Ticket's state is changed to Spam by the support staff if the incoming email cleared the spam filter and created a new Ticket. Tickets with Spam states are "garbage collected" and removed.

• Rejected

  • A Ticket's state is changed Rejected by the support staff if it is not a valid support issue. Tickets with Rejected state are "garbage collected" and removed.

• Delete

  • A Ticket's state is changed to Delete when its history and "how handled" information is of no further use. This status change can be made by the support staff or can be implemented by an algorithm. Tickets with Deleted state are "garbage collected" and removed.
    
    Operational note: It is SQI's recommendation that all Tickets be held for at least a couple of years. This helps build the experience base that can be searched. This base can also provide the basis for knowledge formation.

Figure #: Description