In EriZone, processes that require the involvement of multiple responsible persons and different competence centers are often implemented by using the concept of child ticket.
Child tickets are independent tickets that are created from and linked to their so-called parent tickets. Depending on the specific use case, it is possible to copy data and properties (as for example title, service, ticket type or customer) from the parent ticket, or to newly set them for the child ticket. The special linking guarantees that the parent ticket cannot be closed before the closure of all linked child tickets.
Why using child tickets, if it were possible to move a ticket back and forth among the queues of the involved competence centers until it can be closed?
The creation of child tickets assures a central service management principle: It prevents that with the ticket, also the responsibility for its successful closure is moved to someone else. You know what that means in practice, right?
Let us consider for example an incident ticket. Instead of moving the ticket to the experts on the 2nd level, a new child ticket will be created and put to a queue that isn’t visible for the customer. In this way, internal processes can be completed, while the parent ticket remains at the 1st level support. The service desk keeps to be the single point of contact (SPOC) for the customer, mediates between customer and experts, guarantees a customer oriented answer, and always holds the control of the ticket in the ITSM Monitor-Control-Loop, avoiding also that the ticket gets lost somewhere on the way through 2nd level. Moreover, this control function is essential for the revealing of unclear responsibilities and bottlenecks – common problems, especially in growing structures.
Furthermore, parent/child tickets allow a simple creation of statistics regarding the number of tickets, states, time requirements and the compliance of SLAs and OLAs for different support levels and competence centers.
With its new extensions, EriZone 3.6 simplifies the management of child tickets on three sides:
A new dashboard provides to the service desk employees and to the service manager an overview about the number of opened and closed child tickets for each 1st level ticket. Moreover, notes on child tickets can automatically be transferred to parent tickets and can change the parent’s status for requesting an action of the 1st level.
Thanks to the enhanced automatic ticket dispatcher, child tickets can be distributed by applying own rules: In this way, the tickets can be routed differently to the 1st and 2nd level competence centers (queues), for example depending on the service.
A new process module, called ChildTicketCreate, allows the automatic creation of a child ticket from a process ticket at any time. The module is highly configurable, thus e.g. the child ticket can be created directly in a certain queue, with its own process, for a specific customer and/or with a copy of a selected article. The flexibility during the selection of the ticket customer makes a variety of processes possible: For 2nd level tickets the customer will remain the same, the ticket however will be shifted to a queue invisible for the customer. For authorizations the service owner (read from the service properties), the customer’s direct line manager (from customer information in ActiveDirectory) or a manually selected contact from the customer database, can be defined as customer.
In this way, authorizations remain assigned to the authorizing person and can be easily accepted or rejected by it directly from the customer interface.
Interactions between child and parent tickets are possible through Transition Actions, which are able to change dynamic fields or the process state of related tickets: TicketSetDynamicFieldValueToParent and TicketGetDynamicFieldValueFromParent. Thereby, the parent ticket can be forwarded or closed, for example during the acceptance or rejection of an authorization. This allows for a flexible and maintainable composition of manageable processes.