APPLICATION SUPPORT

TICKET MANAGEMENT

Table of Contents
Introduction................................................................................................................................... 2
People............................................................................................................................................ 2
Structural Model............................................................................................................................2
RACI Matrix................................................................................................................................... 3
Priority Definition and SLA.............................................................................................................3
JSM Workflow................................................................................................................................4
Annex A: Labels........................................................................................................................... 14
Document Version History...........................................................................................................14

1
Introduction
Per ITIL definition, Incident Management process ensures normal service operation is restored
as quickly as possible and the business impact is minimized. This means responding
immediately to Incident (INC) like service interruption or any unplanned event.
The overall process includes necessary steps from submitting INC (issue type) to ticket closure.

The same goes for other issue type such as Service Request (SR); defined by ITIL as a request
from a user or a user's authorized representative that initiates a service action which has beenc
agreed as a normal part of service delivery.

And Problem (PRB) which is defined as the underlying cause of one or more incidents.

People
The core stakeholders involved are:

Business – Super User/L1

Application Support – ActiveDesk/ L2 Support
Platform and Solution Architect – ITS/L3 Support
Vendor – L4 Support
Project Delivery

Structural Model
The standard template of a broker type support (Active Desk) and how it interfaces between
business and support.

2
RACI Matrix
R – responsible; A – accountable; C – consulted; I – informed
Business Active L2 L3 L4 Project/
Step Activity
- L1 Desk Support Support Support Delivery Team
1 Submitting issue R

Initial Assessment
-symptoms analysis
2 R/A
-categorizing/ prioritizing
-assignment

Resolution
3 -diagnosis I I R/A C C
-identifying resolution to be undertaken
Approval
-Service Request requiring authorization*
4 R* R**/A**
-CAB approval for the resolution (as
needed)**
Delivery
5 I I R/A I A
-Applying fix
Confirmation
6 -Service is restored as confirmed by the R A I
reporter
7 Root Cause Analysis I A R C C

8 Ticket Closure I R/A R

Priority Definition and SLA

Response Time (ticket is acknowledged) and Resolution time (ticket is resolved) are part of the
SLA and must be considered as part of ticket management.

Priority Level Definition Priority Response Time Resolution Time

P1 An incident is designated to be a Major Priority One– 15 minutes 98% in 2 hours
Incident when: Major Incident 100% in 4 hours
we have a complete business down
situation or a single critical system is down
with high financial impact
P2 An incident is designated to be a Priority 2 Priority 2 30 minutes 95% in 4 hours
when a critical functionality or network 100% in 8 hours
access is interrupted, degraded or
unusable, having a severe impact on
services availability. However employees
can continue to perform their work using a
work around or delay work for up to 1
business day.
Any identification of security vulnerabilities
are to be considered as P2.

3
P3 An incident is designated to be a Priority 3 Priority 3 4 hours 2 days
when A non-critical function or procedure
is unusable or hard to use having an
operational impact, but with no direct
impact on services availability.. A
workaround is available
P4 An incident is designated to be a priority 4 Priority 4 8 hours 4 days
when employees can continue to perform
their work and there is little damage
caused by the incident

The above SLA Resolution Time applies:

 To all Incidents and Service requests (P3 & P4 only) related to L2 application support. Problem,
Enhancements and Maintenance tasks are not subjected to SLA
 From the moment a ticket is created and assigned to the vendor support team and from the
moment the contractor starts his contractual opening hours; awaiting Business/ITS Feedback +
closing hours freezes the SLA calculation
 For L2 application and IT operations support services the SLA is between IATA ITS and the
vendor, not between the end user and IATA or its 3rd party vendors.

JSM Workflow
1. INCIDENT

OPEN – an incident is raised by the user

4
 Status Next Status When to move to this status
WORK IN PROGRESS The incident is being worked on the by the support team

PENDING BUSINESS Further information/clarification/confirmation is

FEEDBACK requested from the business
PENDING EXTERNAL
Awaiting input from third party vendor
OPEN SUPPLIER FEEDBACK
PENDING ITS
Awaiting input from ITS Team
FEEDBACK
Issue is resolved:
COMPLETED -with reporter’s confirmation
-proven solution applied
CANCELLED Ticket is cancelled or no longer required

WORK IN PROGRESS – setting the ticket to this status means a group member is assigned and
the effort is started e.g diagnosis, investigation, applying fix, etc.

Status Next Status When to move to this status

WORK IN PENDING BUSINESS Further information/clarification/confirmation is

PROGRESS FEEDBACK requested from the business

5
 PENDING EXTERNAL
Awaiting input from third party vendor
SUPPLIER FEEDBACK
PENDING ITS
Awaiting input from third ITS team
FEEDBACK
Issue is resolved:
COMPLETED -with reporter’s confirmation
-proven solution applied
CANCELLED Ticket is cancelled or no longer required

PENDING BUSINESS FEEDBACK – more info/clarification/confirmation is required from the

business

Status Next Status When to move to this statis

The incident is being worked on the by the

WORK IN PROGRESS
support team

PENDING EXTERNAL
Awaiting input from third party vendor
PENDING SUPPLIER FEEDBACK
BUSINESS PENDING ITS
FEEDBACK Awaiting input from ITS team
FEEDBACK
Issue is resolved:
COMPLETED -with reporter’s confirmation
-proven solution applied
CANCELLED Ticket is cancelled or no longer required

6
Note: During this stage, we follow the 3-strike rule should no response is received from the
business. Please refer to:
https://iatasfdc.atlassian.net/wiki/spaces/2AD/pages/4317708311/Activedesk+-+3+-
+Strike+Rule

PENDING EXTERNAL SUPPLIER FEEDBACK – when a third-party vendor requires involvement

and feedback is awaiting from them, the ticket is set to this status. Please make sure we add the
following details in Jira (left side portion):
1) External provider – third party/vendor e.g Trevipay, FeatureSpace, etc
2) External reference – ticket # from the vendor that we can use as reference in following
up

Sample:

Status Next Status When to move to this status

The incident is being worked on the by the support
PENDING WORK IN PROGRESS
team
EXTERNAL
SUPPLIER PENDING BUSINESS Further information/clarification/confirmation is
FEEDBACK FEEDBACK requested from the business

7
 PENDING ITS
Awaiting input from ITS team
FEEDBACK
Issue is resolved:
COMPLETED -with reporter’s confirmation
-proven solution applied
CANCELLED Ticket is cancelled or no longer required

PENDING ITS FEEDBACK - when ITS team requires involvement and feedback is awaiting from
them, the ticket is set to this status.

Status Next Status When to move to this status

WORK IN PROGRESS The incident is being worked on the by the support team

PENDING PENDING BUSINESS Further information/clarification/confirmation is requested

ITS FEEDBACK from the business
FEEDBACK

PENDING EXTERNAL
Awaiting input from ITS team
SUPPLIER FEEDBACK
COMPLETED Issue is resolved
CANCELLED Ticket is cancelled or no longer required

8
COMPLETED – the issue is believed to be resolved

Status Next Status When to move to this status

Ticket is automatically closed after 5 days of setting to

CLOSED
COMPLETED.
COMPLETE
D
OPEN Ticket is re-opened upon unsatisfactory resolution of the incident

In completing the ticket, we need to make sure we select the proper “Close Code”.
It is also important that we indicate the Root Cause and Resolution made in the close comment.

Close Code When to select

Associated to Problem If this related to a problem as repetitive issue or major incident
Cancelled invalid incident or technical support no longer required
Duplicate If there is any duplicate, keep one ticket and link the other
Moved to Should the request is addition to the existing feature, this has to
enhancement be moved as enhancement
No Business Feedback Following the 3-strike rule, select this close code if no feedback
receive from the business
Not solved (not Unable to solve the case and no longer able to replicate the issue
reproduceable)
Solved (permanently) Fix was applied providing permanent solution
Solved (workaround) Resolved by applying workaround
User Guidance** Non-technical and can be resolved by L1/business by providing
guidance

9
**User Guidance:
General guidance from IATA: Data related issues should be fixed by the business, eg. Level 1.
However it is still the responsibility of the support to provide guidance/assistance.
Exemption: For AMS related data is – re-assignment to AMS L1 Support is sufficient. No need to
provide step by step guide.

In addition, if we are resolving data related cases that are not L1 responsibility (not a bug fix),
we use the field “Labels” in identifying this is as non-technical.
Naming convention = NonTech_[acronym of business service]
Sample = NonTech_GCS

Please refer Annex A for the complete list of Labels that we need to use

CLOSED – Ticket is automatically set to Closed after 5 days of completion.

Status Next Status When to move to this status

N/A - Once ticket is CLOSED, you cannot re-open
CLOSED N/A
the ticket

CANCELLED – invalid incident or technical support no longer required

10
 Status Next Status When to move to this status
Ticket is automatically closed after 5 days of setting
CANCELLED CLOSED
to CANCELLED

2. SERVICE REQUEST – this has the same workflow as above and all considerations must be
followed i.e 3 strike rule for status “Pending Business Feedback”

3. PROBLEM TICKET

A problem is triggered based on the following key concepts:

 Root Cause Analysis after a Major Incident (P1) is resolved. This problem ticket is created
automatically and linked to the Major Incident
 Repetitive Issues or coming from trend analysis . Example - the same issue is reported 3
Mondays in a row. Open a problem ticket, link the 3 Incidents to the problem , then work on
the problem ticket.
 Issue Resolved via Work Around . Example - running a report doesn’t work, and the solution is
to simply try again, and it works the 2nd time. That’s a work around, but why didn’t the report
work in the first place? Open a problem ticket to figure out why.

Who does what?

 Create a problem ticket – ActiveDesk, SalesForce Support L2, SharePoint Support L2
 Assign problem tickets and do follow ups –
o Problem Manager of SalesForce (Rui Jorge)
o Problem Manager of SharePoint (Joseph Maningas)
o Problem Manager of ITS (Jordi Balada Garcia) – follow up only

11
 STATUS Description
OPEN Problem is logged based on the above triggers
UNDER REVIEW Support acknowledged the problem for investigation
UNDER INVESTIGATION Root cause is being investigated
PENDING Action may be required from other parties to progress further
COMPLETED A permanent fix is found and problem is resolved (or fix is
rejected due to certain grounds e.g expensive, workaround is
very cost effective, transition to new service, etc).
It could also be that the permanent fix is not found.

Note: all the mandatory fields must have been filled in by this
stage:

• Investigation Reason
• Rootcause
• Workaround
• Solution
CANCELLED Invalid Problem
CLOSED Solution has been approved.
This is normally closed by PRB Process Owner Kaan Saldiraner

12
As there is no SLA applied for Problem ticket, it is difficult to ensure things are progressing.
Jordi, Problem Managers and ActiveDesk should do a regular periodic review to agree on the
prioritization.

The assignee of the problem should report on milestones already achieved or if something is
blocking the progress. In case of any barrier on the problem’s normal evolution, it should be
reported to the business to manage their expectations

Ref for Problem Management-

https://iatasfdc.atlassian.net/wiki/spaces/JI/pages/1139409055/SOP+for+Problem+Mgmt.

Annex A: Labels

Responsible Label Description

SFL2 SME/Assignee Low Low complexity (quick-wins, can be resolved under 1-2 hours)
SFL2 SME/Assignee Medium Medium complexity (can be done in 1 day)
SFL2 SME/Assignee High High complexity (takes more than 1 day to resolve)
SFL2 SME/Assignee governor_limits Platform limitation
SFL2 SME/Assignee; NonTech_BS
ActiveDesk e.g NonTech_GCS Non-bug/fix ticket
ActiveDesk Escalated Escalated by the business

Document Version History

Version Status Change Description Date Author(s) Reviewer(s) Approval(s)
0.1 Draft New 30 May 2022 Krish Fiedalan

13
14