This article contains the following topics:

As an analyst you work extensively with tickets. Besides working on a requested service, you can take multiple actions on a ticket. You can reclassify a ticket that is based on the nature of its request. You can determine the progress of the request, update solution details to the ticket, and more.

As an analyst, you must be aware of the ticket management concepts. This article provides the high-level concepts that are related to ticket handling in Serviceaide Intelligent Service Management.

Ticket Management Process    

You can log new requests by sending an email to the designated support ID or from the application user interface. You can log requests by using a relevant catalog item from the Service Catalog. Requests get routed to different support groups based on the following criteria:

The administrator manages and controls the permissions and workflow actions available to you. Based on  the request or issue you can create an incident, problem, change, or service request. You can also create a ticket of a different ticket type from an existing ticket. The outcome is to ensure that the request is handled using appropriate processes within the specified service delivery agreements.

Ticket and Ticket Life-cycle

A ticket is a transaction document that records all the information that is related to a request. The ticket fields contain information that is required to understand and fulfill the request from the end user. The administrator can configure and add custom fields to be available on the ticket and is based on the ticket categorization. Once a ticket is created, it gets assigned to a support group. The administrator configures the assignment rules. The three main aspects of ticket progression, which are used when building the workflow process are:

A combination of the ticket status and reason code is used to manage the workflow actions available and manage the ticket progression. As a ticket progresses, it grows to include activities toward resolving, fulfilling, and closing the request. Ticket progression also includes manual, automatic actions, and communications to and from the ticket. The administrator can configure different workflow actions to be available on the ticket to control the progression of the ticket.

Ticket Types

In Intelligent Service Management, there are five types of tickets:

Notes: A Task ticket is never logged as an independent ticket but as children of a request, incident, problem, or change. A Task ticket is always used to divide individual units of work that is done to resolve another ticket.

Workflow Actions and Auto Assignment of Tickets

Routing rules route newly created tickets to appropriate support group queues. Routing is based on matching conditions such as its source, priority CCTI.

As an Analyst, while using the conversion of ticket type from a Service Request to an Incident ticket or any other ticket type, the Impact, Urgency, Source, and Priority fields can be copied from the parent ticket. These fields can be copied only if the codes specified in the Value Lists, are the same. If the codes doesn’t match, the default value specified for the ticket in Configuration Parameter is considered. For example, for a Ticket type such as Change Request, default value for the Priority field is set to Medium, in Configuration Parameter. When the codes doesn't match, the value specified in Configuration Parameter is defaulted.

As an example, you can view the configuration for a ticket type such as Change Request, as follows:

  1. Navigate to MANAGE>Tools> Configuration Parameter

The administrator manages and configures the workflow actions and auto assignment rules responsible for the progression and assignment of tickets. This progression and assignment of tickets is based on the request handling process that is defined for each ticket type.

Notes: An assignment rule gets applied to a ticket only once, when a ticket is first created. All subsequent routing or changes are done manually from the options available in the Actions dropdown on the ticket.

Workflow actions can also be configured to send out notifications to stakeholders. Some values can be set as required fields before execution of the workflow action. Some action options have associated special functions; which further automate the execution of an extra action (such as Accept Assignment, Reassign).

Notes: The administrator controls the access and permissions to workflow actions. An action available to you could not be available to another analyst.

Change Types and Change Approval

Change is defined as an addition, modification, or removal of an existing IT system or service. Change could be part of software or hardware systems, configurations, access, and so on. A change can be reactive - in response to a problem or proactive - to prevent potential problems or improve service delivery. For example, adding or removing users from a system or group or provisioning systems for a new hire.

Change request can be classified into the following four types:

Configuration Items and Affected Services

A configuration item is any component of an organization and its IT infrastructure. A CI manages and delivers an IT Service. For example, hardware, software, networking devices, peripherals, and documentation. Intelligent Service Management creates and manages a record of all configuration items in the organization. For example, mail hosts, servers, and client machines with essential software are required to deliver an email service. A record of all such services is created and saved as a CI in Intelligent Service Management.

A configuration item can be related to one or more configuration items in different relationship domains, such as logical, network, power, or service domain. This information can be used to troubleshoot any issues with the configuration item. When a ticket is logged to report an issue about a configuration item, the CI can be related to the ticket. Thus, building a history of all the incidents, problems, and changes that are related to the CI which can be stored and retrieved. If a ticket is logged to report issues with a service, the relevant CI can be related to the ticket as 'Affected Service'.

Contacts can be related to configuration items as Owner, User, Change Approver, Change Reviewer, and Support Provider. The contacts that are associated as Change Approver and Change Reviewer are used as contextual approvers for change tickets that are related to that CI. The status of a configuration item indicates whether the CI is in use or not. The status also specifies what stage of its lifecycle the CI is at. Configuration Items in all statuses except Deprovisioned is visible to analysts when relating a CI to a ticket.

Ticket Relationships

Ticket relationships refer to the different types of records that can be related to a ticket. Tickets can be related to other tickets or to configuration items. Attachments can also be related to provide more information.

Notifications and Activity Log

A notification is received when an attachment is added to a ticket that is assigned to you. When the attachment is added, it also gets recorded in the activity log.  

SLA Compliance Monitoring

Service Level Management deals with the process of negotiating Service Level Agreements and ensuring that they are met. Service Level Management is ensures that all processes, agreements, and underpinning contracts are suitable for the agreed Service Level Targets. Service targets define the time that is allocated for a specified activity, are measured against set Service Metrics. A service target can have one or more threshold rules. One of the service targets can be set as Violation Threshold indicating that the SLA has been breached.

Factors such as support group business hours and service availability govern SLA measurement. The SLA target progression icon displays the target status progression. The SLA target progression icon also indicates whether a ticket is approaching violation or violated the SLA target.

The administrator configures the threshold rules and the SLA monitoring of tickets. The administrator can also configure actions to be executed when a threshold rule is breached. Actions include sending notifications to different stakeholders or escalating the ticket to the next escalation group.

Knowledge Articles and Knowledge Base

Knowledge management deals with gathering, analyzing, and storing of knowledge and information within an organization. A knowledge article contains information about troubleshooting frequently occurring or previously reported incidents, instructions for setting up or configuring an IT service. Knowledge articles also contain news, solution details and about a supported system or services. Knowledge articles can be made available to users by assigning permissions to appropriate support groups or roles.

The knowledge base provides you with information about how to handle an Incident or problem that has previously occurred. The knowledge base can be used to expedite the issue resolution process and improve service delivery.

With the required permissions, you can also create knowledge articles. All new articles are created in the Draft state. Once created as a draft all knowledge base articles can be reviewed, refined, and set as Approved. Once approved, an article can be made available to different support groups or roles. You can also suggest solutions from tickets to be included in the knowledge base. The solutions items get added to the knowledge base in draft state.

Support Groups and Roles

A support group is a grouping of contacts according to their geographical locations, skill sets, or relative tasks that perform. Such a grouping of contacts is used for functions, such as skill-based ticket routing, ticket assignment, ticket approval. Support groups are used for actions such as notifications, permissions, approvals, SLA escalations, and assignment.

A role is a grouping of contacts and support groups that is based on the broader functions they perform. For example, the incident management role could be used to manage all functions that are related to incident management. Support groups providing L1, L2 (or higher) support and supervisors who manage teams of analysts could be under this role.

The administrator configures permissions such as access to ticket templates, communication templates, workflow actions, knowledge articles. Permission is either given directly or by virtue of the support group the logged in User belongs to. A contact can be related to multiple support groups and roles. A contact inherits permissions that are assigned to each of the related support group or role.

Notes: A logged in user can access only those items that the user has permission to and that are in an Active state.

Organization and Organization Based Security

Intelligent Service Management supports three levels – Organization- Site-Location hierarchy for managing Organization information. An organization can have multiple sites and each site can have multiple locations. Multiple organizations, with their own sites and locations, can be configured within the same instance of the application.

Users can be related to an organization, a site, or a location level in the hierarchy. While Users can be related to multiple organizations, one organization must be set as a Primary Organization for that user. Several features available to a logged in user, such as the ability to participate in service feedback, are managed at the organization level.

You can view tickets that users of different organizations log. However, the application administrator can enable organization-based security to manage the ability to view and work with tickets and configuration items. When organization-based security is enabled, you can view the tickets and CIs that are related to the organization you belong to. You can also view tickets that are related to support groups that you are a member of.

Restrictions