Tbis - Spoc Customer Service and Support Model - 2014 06 18

Tapstorm SPOC Service Desk model
- Requests: Customer service for requests from customers and BUs/resellers.

- Incidents: Support for platform availability and technical incidents.
- Change: change and work orders to services and platform
Telenor Business Internet Services AS.

Snaryveien 30 1360 Fornebu Norway +47 67890000 www.tapstorm.com
Page 1 of 30
Table of contents
PURPOSE ................................................................................................. 3
SCOPE ..................................................................................................... 3
GOVERNING INFORMATION .......................................................................... 3
Roles and definitions ..................................................................................... 4
Introduction ................................................................................................ 6
LEVEL 0: Self-service .................................................................................... 7
LEVEL 1 Service Desk: SPOC for end customers (Requests and Incidents) ................... 8
LEVEL 2 Service Desk: SPOC for 1. line (requests, incidents and change) .................. 11
LEVEL 3: TBIS, ISV or hosting provider support .................................................. 13
APPENDIX 1: Severity levels for Parallels platform incidents ................................... 15
APPENDIX 2: Severity levels for spesific Incidents on Paralells platform ..................... 17
APPENDIX 3: SLA for incidents on Parallels platform ............................................ 18
APPENDIX 4: ISV SLAS .............................................................................. 19
APPENDIX 5: Governance structure ................................................................ 21
APPENDIX 6: Reporting ............................................................................... 23
APPENDIX 7: Contact information ................................................................... 24
APPENDIX 8: Process for handling incidents ...................................................... 26
APPENDIX 9: Process for Change/work orders ................................................... 28

Page 2 of 30
PURPOSE
The purpose of this document is to describe how the end to-end Service Desk function from 1. Line interacting
with customers through 3. Line provided by ISVs, TBIS personell and hosting providers.
SCOPE
Service Desk inquiries in this context is classified into the following categories
Request ie helping customers set up and use the services available, including billing-related
questions.
Incident - ie the services does not function as they should (software bugs, operation downtime etc
Change when a change or configuration change to the solutions/systems are requested
Service Desk inquiries may arise at different levels in the value chain:
Level 0 Customer Self-service
Level 1 The function interacting directly with customers and users.
Level 2 the function providing help on issues that Level 1 cannot resolve.
Level 3 the function providing help on issues that Level 2 cannot resolve.
It is important to note that Customer Service and Support often times are organized into 2 separate entities,
the TBIS approach as defined in this document will handle Customer Service and Support within the same
organization, a so called SPOC approach Single Point Of Contact for all types of inquiries. For this purpose
the term Service Desk is used.
These 2 dimensions define the scope matrix of this document:
The document is organized according to the above matrix, that is into the following sections:
Section 1: How Level 1 Service Desk should handle requests and incidents.
Section 2: How Level 2 Service Desk should handle requests, incidents and changes.
Section 3: How Level 3 will handle requests, incidents and changes.
GOVERNING INFORMATION
Date/comment
Revision responsible
Revision date
Dag Rune Langehaug

dag.rune.langehaug@telenor.com
May 16, 2014
First version of merging Support

and Customer Service function
and routines into a common
framework.
Green text is coming from current
Managed Services contract with
Telenor Denmark.
Amber text is coming from current
Managed Services contract with
Telenor Norway.

Page 3 of 30
May 20, 2014;

May 21, 2014
June 18, 2014
Added input from Stian Alapnes

Revised process for incidents
outside business hours (Appendix
8)
Distribution list for reports updated
ISV SLAs updated
Notification matrix from TBIS to
resellers for planned/unplanned
service interruptions added.
ROLES AND DEFINITIONS

Term
Request
Incident
Change
Comment
Request fulfillment focuses on fulfilling Service Requests, which are often
minor (standard) changes (e.g., requests to change a password) or requests
for information, help to do something.
An event which is not part of the standard operation of a service and which
causes or may cause disruption to or a reduction in the quality of services
and customer productivity.
The objective of change management in this context is to ensure that
standardized methods and procedures are used for efficient and prompt
handling of all changes to control IT infrastructure, in order to minimize the
number and impact of any related incidents upon service.
Changes in the IT infrastructure may arise reactively in response to problems
or externally imposed requirements, e.g. legislative changes, or proactively
from seeking improved efficiency and effectiveness or to enable or reflect
business initiatives, or from programs, projects or service improvement
initiatives.
Change Management can ensure standardized methods, processes and
procedures which are used for all changes, facilitate efficient and prompt
handling of all changes, and maintain the proper balance between the need
for change and the potential detrimental impact of changes.The main aims of
change management include:
Minimal disruption of services
Reduction in back-out activities
Economic use of resources involved in the change
Service Desk
The term encompasses that this function has a broad responsibility:

- Handle calls and mails from customers (requests). Calls can be
outgoing or incoming.
- Handle incidents when the services are down, partially or fully.
- Be SPOC for change orders coming from BU/reseller.
TBIS platform
TBIS Platform is the name for the Parallels IS cloud broker platform. It is
based on off-the shelve functionality as well as functionality that may be
custom made for the Reseller. TBIS supports processes for ensuring
provisioning and operation of 3rd party ISV functionality within TBIS Platform.
Independent Software Vendor creating applications to sell in the cloud and
make them available on the TBIS platform.
Single Point of Contact.
ISV
SPOC
The customer(s) should only be required to interact with one entity (1. line
support). Towards the end customer 1. line will own the ticket.
Similarely, 1. line should only interact with 2. line, irrespective of who is
actually providing the solution. 2. line will own the the ticket towards 1. line.
Page 4 of 30
BU/reseller
The entity responsible for the sales channel where the services are sold (BU
= Telenor Denmark, Telenor Hungary etc / reseller = a reseller (within the BU)
or independent from Telenor).

Page 5 of 30
INTRODUCTION
The picture below depicts the process flow of customer service and support. For the most part,
Requests and Incidents follow the same processes, while Change is somewhat different but is using
the same Level 2 function and ticketing tool (Kayako) to tie the processes together.

Page 6 of 30
LEVEL 0: SELF-SERVICE
Description
Level 0 is characterized by self-help/service, meaning
that the customer solves the issue at hand by themselves,
without interaction with 1. line customer service/support.
Responsibilities TBIS
The following will be available from TBIS to the
BU/reseller to facilitate Level 0 customer service:
Control panel Parallels control panels for
customer end customers and administrators
where they can administer their services
Video tutorials short videos on how to use the
services.
Manuals instructions on how to set up, use and troubleshoot the services.
Technical specifications specifications and systems requirements for hardware and software.
Downloads the latest software updates for the services.
Responsibilities BU/reseller
The BU/reseller will be responsible for localization of the material and exposure at the relevant BU/reseller web
pages/support forum. This will be handled through the BU/reseller onboarding project.
Processes
Implementation will be handled through the particular project organization.

Page 7 of 30
LEVEL 1 SERVICE DESK: SPOC FOR END CUSTOMERS (REQUESTS AND INCIDENTS)
Description
If the customer has a request or wants to report an
incident, the customer will contact the BU/reseller
through the communication channels provided by
the BU/reseller. The BU/reseller defines the
channels and opening hours.
The BU can choose to provide this using
internal/excisting resources or purchase this as a
managed services from TBIS.
If the BU/reseller is using internal/excisting
resources to provide this service, TBIS will provide training of the BU/reseller Level 1 agents in
ISV product use and administration
ISV administration portals
processes (request, incidents)
needed tools (ticketing system)
TBIS will also provide documentation on the most common inquiries to Customer Service and corresponding
solutions/processes.
or
For BUs/resellers that does not want/is not able to provide customer support/service themselves, TBIS can
provide Level 1 customer service on behalf of the BU/reseller as a managed service.
In these cases, the BU/reseller sells the SaaS/IaaS offering , but will not provide support/customer service.
To be specified in commercial terms/part of contract between reseller and TBIS, TBIS can provide these services
white-labelled by answering/responding to the inquiries by the name of the BU/reseller. TBIS will be able to
provide this service in most major languages, but the final setup will be subject to agreement between the
parties. Depending on the chosen setup, the BU/reseller must cover expenses related to additional language
capabilities and the extra costs this implies for TBIS, as TBIS will have to provide more of the customer service
value.
If the BU/reseller does not want to leverage internal/excisting customer service functions, TBIS strongly suggests
that the BU/reseller use the TBIS customer service function as partner for outsourcing the 1st line Service Desk,
given that TBIS can provide the service at competitive and comparative cost.
The BU/reseller must provide training for support in all internal billing, sales and support systems and ensure
these are made available and configured in a way suited to the particular purpose.
The BU/reseller will also be responsible to define the customer journeys applicable:
Sales
Order/order confirmation
Activation
Payment/billing
Support/customer service
Change (up/downgrade)
Cancel/termination
Service level
Level 1 must be able to handle at least 80% of the most frequent inquiries, as defined by the different ISVs.
Typically, they fall into the following categories;

Page 8 of 30
Pre-sales questions
Ordering-related
Provisioning/activation of service ((most customers will call about this the first month in their
subscription).
Account administration
Billing and payment (if system access and authority allows)
ISV service administration
ISV service usage (how to)
Training
The agents representing the BU/reseller must attend the offered training on the products they will handle. This
implies adhering to the required training and pass certification exams provided by TBIS, including
go trough the offered self-study material
attend training on the Parallells platform.
attend training on the specific XaaS offerings to be marketed and sold by the BU/reseller.
TBIS encourages all agents to undergo the training and certifications (where applicable), but a train the trainer
approach can also be used.
Governance
The Governance structure is defined and described in Appendix 5.
Reporting
Standard reports for requests and incidents should be provided by the entity providing the service. These should
contain:
Status on service delivery compared to agreed SLA/KPIs
Volume of the different inquires (requests and incidents).
Staus on open and closed tickets.
Overview over most recurring issues.
Processes
Requests
It is recommended that all requests are logged in the appropriate ticketing tools, either provided by BU/reseller or
TBIS.
Requests that the BU/reseller customer cannot resolve due to restricted authority or that the customer service
agent is not skilled enough, shall be forwarded to Level 2 customer service/support through the provided
channels. See Appendix 7 for contact information to Level 2 customer service/support.
Incidents
It is expected that the Level 1 Customer Service agents are able to differentiate an incident from an request and
accordingly handle in accordance with the defined procedure (described below):
Differentiate an Incident from a Request (there is a real problem, not only that the customer does
not know how to do things).
Determine what part of the service the Incident is related to (Parallels platform or a particular product
or other).
Be knowledgeable about know bugs, errors or planned outages or know where to find such
information so tickets are not raised for known problems.
Able to classify the Incident according to prescribed guidelines (Severity 1, 2, 3, 4 etc.)
Forward or escalate the Incident to the correct recipient according to defined procedures (could be to
TBIS Level 2 support or to hosting partner.
Inform the customer(s) about the status and progress of the Incident.
It is not expected that Level 1 Customer Service should start troubleshooting and fixing errors for Incidents. For
Incidents outside regular opening hours, a 24/7 service via phone is provided by TBIS, but will only be available
for the most severe Incidents (Severity Level 1 and 2). During a call to this 24/7 service, the level of severity and
actions to be taken will be determined.
Severity level 1 and 2 must be called in (no mails accepted).
The following detailed information is relevant for Incidents

Page 9 of 30
Appendix 1: Severity levels on Parallels platform incidents

Appendix 2: SLA on Parallels platform incidents
Appendix 4: ISV SLAs
Appendix 7: Contact information to TBIS Service Desk and escalation
Appendix 8: Process for handling incidents
1. line Service Desk as standalone product

TBIS encourages the BU/reseller to evaluate whether Service Desk should be embedded in the ISV offering or
sold as optional services as this can become a major revenue stream. Although product mix and marked
considerations define the final model, a typical model looks like the following:

Page 10 of 30
LEVEL 2 SERVICE DESK: SPOC FOR 1. LINE (REQUESTS, INCIDENTS AND CHANGE)
Description
Level 2 Service Desk is provided by TBIS as a
SPOC service (Single Point of Contact) for all
Level 1 Service Desk functions. Generally Level
2 Service Desk will handle tickets that are of the
more unusal character and possibly needs to be
forwarded to Level 3 support or escalated.
Handling of requests and incidents is included in
the monthly service fees. The BU/reseller will
have an agreed number of hours included in the
monthly service fee to spend on changes/work
orders. This is to be regulated in the commercial agreement.
Level 2 Customer Service/support will be provided 8:00-17:00 (CET). 2nd level customer service/support will be
provided English.
For normal requests, TBIS will provide the following service level:
Phone: 90% within 120 seconds
Web forms/e-mail: 95% within 8 working hours.
TBIS is responsible that operational and support procedures are made available to BU/reseller and kept up-todate.
TBIS is responsible for making available a ticketing tool enabling the requestor to follow the status and update of
a particular ticket. TBIS will maintain updated processes and procedures on how to escalate tickets to Level 3, an
updated knowledge base in Kayako and links to to ISV/provider knowledge bases.
Request
For Requests not handled by BU/reseller customer service function, TBIS will provide subject matter experts on
all XaaS products/services and will as well have in-depth knowledge of how to operate the control panels on the
Parallels platform.
Incidents
TBIS is responsible to provide 2nd line technical support for the platform in accordance with the agreed
resolution times set out in this SLA; in relation to platform and 3rd party ISV issues.
TBIS support responsibility is limited to what the TBIS platform can control or has possibility to monitor. This
means as an example that TBIS is not responsible for the time it will take Microsoft to provision a service once
the provisioning call has been sent from TBIS Platform to Microsoft. TBIS will however pro-actively work with the
partner network of resellers and ISVs to ensure that the experienced end-2-end managed service quality is
satisfactory and improving.
For severity 1 and 2 incidents 24x7 coverage is provided. This function will register, aid classify the incident and
escalate to Level 3 as needed, but will not be able to provide solution directly. For severity 1 and 2 incidents
Level 3 will provide the actual solution, level 2 will only act as an dispatcher but will own the ticket and be SPOC
until resolved.
Request
-
The BU/reseller agent shall in writing provide all needed and mandatory information to give a good
description of the inquiry.
Use the provided contact means to raise the ticket.
Check the status on the ticket by monitoring the status update on the ticket

Page 11 of 30
Incident
differentiate an Incident from a Request (there is a real technical problem, not only that the
customer does not know how to do things).
determine what part of the service the Incident is related to (Parallels platform or a particular product
or other issues).
be knowledgeable about know bugs, errors or planned outages or know where to find such information
so tickets are not raised for known problems.
able to classify the Incident according to prescribed guidelines (Severity 1, 2, 3, 4 etc.)
forward or escalate the Incident to the correct recipient according to defined procedures.
inform the customer(s) about the status and progress of the Incident.
Resolution of faults and restoration of services within BU/reseller scope and access level.
Ensure that all incidents are reported via the agreed trouble ticketing system or telephone help desk.
Providing a single support contact interface so that TBIS may report proactively events and submit
event status reports, as necessary
Providing continual cooperation throughout event resolution on Level 1 and 2 incidents
Identify BU/reseller personnel authorized to open incident tickets with TBIS.
Using reasonable endeavours to provide details of scheduled maintenance relating to elements of the
Reseller system which interfaces with or would affect the performance of the Service in advance to
TBIS.
Service level
TBIS Customer Service/support is SPOC and owns and is responsible for all requests and incidents until
resolved towards 1. line. Change/work orders will be owned by the TBIS delivery organization and after initial
registration in the ticketing system, further communication will be done directly between requestor and TBIS
(non-standard changes) or through Kayako ticketing system (standard/simple changes).
TBIS Customer Service/support function shall supply the needed tools to register inquiries and enable 1. line to
keep track of the inquiry.
Governance
Level 2 customer service/support will adhere to the tactical and strategic meetings/initiatives as defined in
Appendix H.
Reporting
Standard reports for requests and incidents will be provided and will contain:
Status on service delivery compared to agreed SLA/KPIs
Volume of the different inquires (request, incident and change).
Staus on open and closed tickets.
Overview over most recurring issues.
Processes
Requests
Requests can be raised by e-mail or phone during regular office hours (8.00 17.00 CET). Outside regular
business hours requests can be raised by e-mail. See Appendix D for contact information.
Incidents
For severity level 3 and 4 incidents, help can be requested either by mail or phone according to contact
information listed in Appendix D.
For Incidents with severity level 1 and 2 , support outside regular business hours shall be requested by calling
Level 2 customer service/support..
The following detailed information is relevant for Incidents
Appendix 1: Severity levels on Parallels platform incidents
Appendix 2: SLA on Parallels platform incidents
Appendix 4: ISV SLAs
Appendix 7: Contact information to TBIS Service Desk and escalation
Appendix 8: Process for handling incidents
Change
Change will follow the process decribed in Appendix G. See Appendix D for contact information in where to direct
change orders.
Page 12 of 30
LEVEL 3: TBIS, ISV OR HOSTING PROVIDER SUPPORT

Description
Level 3 support implies support for requests and
incidents that neither Level 1 nor Level 2 is able to
answer or resolve. Level 3 support will be provided
by the ISV, TBIS Operation team and Datacom.
The below responsibilities are listed separately
between TBIS, ISV and Datacom to provide
distinction between the organizations. However,
overall responsibility remains with TBIS:
ISVs (requests and incidents)
In general the service levels will follow the response times and service levels provided by the different ISV
support organizations.
The response times/service levels will be communicated on an continuous basis to the BU/reseller, as they are
dynamic in nature. If a request/incident is forwarded to the XaaS provider, TBIS shall inform the BU/reseller
about this with the corresponding expected response time.
3rd party (ISVs and vendors) monitor their functionality in order to automatically detect incidents. When incidents
are reported to TBIS 3. line, TBIS 3. line is responsible to notify BU/reseller Support by mail within 15 minutes after
detection. The notification shall, if possible, include time the incident occurred, ticket number (where applicable),
likely cause of incident, suggested severity level, actions to be taken.
A summary of some relevant SLAs that TBIS has in place with its partners/vendors are listed in Appendix I.
Datacom1 (requests and incidents)
Datacom shall monitor the TBIS Platform functionality in order to detect incidents (outage or non-optimal
performance of process) within 30 minutes during business hours and within 2 hours outside business hours.
TBIS (change)
Reseller Support shall provide TBIS Support with sufficient information in the trouble ticket. In the period where
Reseller Support is asked for supplementary information, and TBIS Support is unable to continue solving the
trouble ticket, the time waiting for supplementary information may be deducted from the SLA-time. However, any
supplementary information needed must be requested before the target of the Resolution simple/Status-time has
expired (meaning that requests done after Resolution simple/Status-time has expired will not be deducted from
SLA-time).
Reporting
TBIS will provide Reseller within 10 business days in following month a report showing whether the SLA-targets
have been met, which will include:
Excel-list of all incidents (incl. information, ticket number, SLA level, how it was raised (channel), SLA
level, SLA-relevant target, actual SLA performance)
KPI performance: How many incidents were handled per channel per Severity Level
o Detection (only for incidents monitored by TBIS)
o Resolution simple/status
o Resolved time
Processes
Requests
It will be the TBIS and TBIS customer service provider that interacts with the ISVs. The end customer or the
Level 1 will never interact with the ISVs, platform operator or infrastructure hoster, unless this is explicitly agreed
between the parties.
Hosting provider for the Parallels platform

Page 13 of 30
There will be specific procedures that needs to be followed for each of the 3 rd line support providers).
However, for the BU/reseller, the procedure will be the same for all issues (Single Point of Contact). A complete
overview over ISV support, support procedures and SLAs is found on the TBIS knowledge base in Kayako.
Incidents TBIS platform
When incidents are detected, TBIS shall notify Reseller Support by mail within 15 minutes after detection. The
notification shall include time the incident occurred, ticket number (where applicable), likely cause of incident,
suggested severity level, actions to be taken.
Monitoring Tasks
Outage of TBIS Platform
Non Optimal Performance of Process
Order status Failed/In progress
Response Time of TBIS to OMT

15 min after detection
15 min after detection
No response, auto fix
The incident is categorized according to the severity level table in Appendix 1 and is handled further according to
its severity level.
Change
All changes/work orders will follow the process(es) as described in Appendix 9.
There are two kinds of changes/work orders:
Predefined: These changes/work orders have a predefined lead time and predefined amount of effort
to complete. Note: Lead time and effort is indicative/advisory
Non-predefined: These tasks have a case by case lead time and amount of effort to complete
After the requestors initial submittal of changes/work orders in Kayako, Level 3 support (TBIS platform and
product team) will give a first response within 2 working days. The first response will classify the Changes/Work
orders as predefined or non-predefined, and also include a first scope evaluation, and how to proceed. When to
deliver is part of first response for Predefined changes.
The further dialogue between requestor and Level 3 support (TBIS platform and product team) will follow the
process described in Appendix 9.

Page 14 of 30
APPENDIX 1: Severity levels for Parallels platform incidents

Incident priority is formed out of it's Impact and Urgency according to the below table. Ie, if an incident has
Impact = High and Urgency = Medium, the Severity level is 2. The lower the value - the higher the Priority,
thus Priority=1 is the highest one, and Priority=5 the lowest.
Definition of incident urgency and impact in ISV services

Urgency
High (value 1)
The damage caused by the Incident increases rapidly.
Work that cannot be completed by staff is highly time sensitive.
A minor Incident can be prevented from becoming a major Incident by acting immediately.
Several users with VIP status are affected.

Medium (value 2)
The damage caused by the Incident increases considerably over time.
A single user with VIP status is affected.

Low (value 3)
The damage caused by the Incident only marginally increases over time.
Work that cannot be completed by staff is not time sensitive.

Impact
High (value 1)
A large number of staff are affected and/or not able to do their job.
A large number of customers are affected and/or acutely disadvantaged in some way.
The financial impact of the Incident is (for example) likely to exceed $10,000.
The damage to the reputation of the business is likely to be high.

Medium (value 2)
A moderate number of staff are affected and/or not able to do their job properly.
A moderate number of customers are affected and/or inconvenienced in some way.
The financial impact of the Incident is (for example) likely to exceed $1,000 but will not be more than
$10,000.
The damage to the reputation of the business is likely to be moderate.

Low (value 3)
A minimal number of staff are affected and/or able to deliver an acceptable service but this requires
extra effort.
A minimal number of customers are affected and/or inconvenienced but not in a significant way.
The financial impact of the Incident is (for example) likely to be less than $1,000.

Page 15 of 30
Spesific definition of incident severity on Parallels platform

Severity level
1 (high)
Mission critical service is down and no workaround is immediately available:

a)
b)
2 (urgent)
The production Parallels Automation system is down or unavailable.

Crucial Parallels Automation component is not functioning, resulting in a halt of all
operations and critical business impact.
c) The issue affects a significant number of end-users.
d) No workaround or immediate solution is available.
A customer is unable to use the entire program component and the issue affects a significant
number of customers. A temporary workaround may be available as TBIS or Parallels attempts to
resolve the issue.
a)
b)
3 (normal)
A business-critical feature described in the documentation is not available or functioning.

A significant performance degradation of the control panel/storefront that causes a high
impact on business operations.
A customer is able to use the software; however, there is a non-critical loss of functionality.
a)
4 (low)
Issue affects some but not all users (inability to manage a single account, domain,
database or Parallels Virtuozzo Container, provisioning of a particular subscriptions fails,
or an order or task failing to complete).
b) Functionality of some components are impaired, but allows the users to continue using
the software.
A minor cosmetic issue or general usage questions.
c)
d)
e)
f)
Requests for information about software usage.

Enhancement requests or recommendation for a future product improvement.
Missing or erroneous documentation.
Minor problems not impacting delivery of service.

Page 16 of 30
APPENDIX 2: Severity levels for spesific Incidents on Paralells platform

Below table are examples of which severity level is to be given to different kinds of incidents.
Area
POA/PBA
Online Store
Orders/sync
Service Request
Process
Process
Systems
Sync
Sync
Sync
Sync
Non-performance
Process
Process
Incident Example
Severity Level
Reseller cannot load the PBA, POA or Customer Control Panel

page
Online store is not available
Stop in TBIS order flow
Password/users for platform users

Any ticket in priority 3 or 4 passing its SLA time limit
High profile (VIP-) customer transactions are in process or failed
(profile defined by number of licenses purchased)
Store, TOSS or Reseller CP unavailable after business hours but
need to be made available for next business hour
Users not synced from MS to TBIS after the agreed time
(currently 6 minutes to 48 hours) for more customers
Order failure - for more customers
Customers, Licenses, domains, L2P-numbers
Users not synced from MS to TBIS after the agreed time
(currently 6 hrs) for one customers
Order failure - for one customer
Customers, Licenses, domains, L2P-numbers
Non persistent slow response of pages
Error on order cancellation
Investigation on a suspicious behavior of TBIS solution but not
customer critical
1
2
2

1
1
2
2
2
3
3
3
3
4
Page 17 of 30
APPENDIX 3: SLA for incidents on Parallels platform
Parallels platform operation critera and SLA

Total loss of critical service
The issue/error is critical the user has stressed the importance
of having this functionality/application working ASAP because of
business impacts/cost/risk
Nor workarounds found or possible
Partial loss of services
Official escalation by Customer Management
Any incident deemed by management to result in a monetary
loss to organization effecting more than one user.
An issue that requires urgent attention once business hours
resume possible escalation of the issue to Severity 1 at the
start of the next business day.
User advises that the issues can wait until business hours
resume.
Single/limited user loss of service
A non-priority issue that can be dealt with as per the SLA during
business hours, effecting one or a limited number of users (within
the platform).
Standard ticket
Systems maintenance task or service request. Investigate noncritical failed task (within the platform).
Severity
Priority
Resolution simple/Status
Status for 80% of Incidents within 15

minutes
Status for 80% within 30 minutes
Status for 90% within 4 hours
Status for 90% within 8 hours
Priority
Initial
response
Diagnosis/
resolution
SLA
target
80% within
15 minutes
4 hours
90%
resolved
within 4
hours
80% within
30 minutes
8 hours
90%
resolved
within 8
hours
90% within
4 hours
2 business
days
90% within
8 hours
3 business
days
90%
resolved
by 2
business
days
90%
resolved
by 3
business
days
Resolution
Post- resolution time update
90% resolved within 4 hours
Every 4 hours during business day
90% resolved within 8 hours

90% resolved by 2 business
days*
90% resolved by 3 business
days*
Daily
Daily
Daily
* Example: ticket raised Monday at 10 has a target resolution of Wednesday at 10

Page 18 of 30
APPENDIX 4: ISV SLAS

Microsoft
SLA
Phone
E-mail
Tickets through ticketing
system
Online chat
Jotta
SLA
Phone
Comment
Phone number same as above for each
country.
Outlined in Partner Playbook
1. Catastrophic - 15 min
2. Critical
- 1 hour
3. Urgent
- 2 hours
4. Important
- 4 hours
5. Advisory
- NA
Vary by support agent
Microsoft Online Portal (MOP)
https://portal.microsoftonline.com/
Not available
Partner Playbook page 48. During the

service request creation process, the
partner technical support agent is asked to
assess the scope and impact of the issue
via a series of prompted requests. Initial
(Please see appendix L) this determines the
severity level of the support issue submitted.
Please see above comment

Please see aove comment
Not available
Comment
Business hours
Severity Level 1 [Critical] 0,5 hour
Severity Level 2 [Major] 1 hour
Severity Level 3 [Minor] 1 work day
Request for Information [RFI] 3 work
days
Off hours
Severity Level 1 [Critical] 1,5 hours
Severity Level 2 [Major] 3 hours
Severity Level 3 [Minor] 1 work day
Request for Information [RFI] 3 work
days
E-mail
As above

system
Online chat
Mozy
SLA
Phone
Comment
Priority 1:
95% <= 4 Hours
98% <= 8 Hours
Priority 2:
75% <= 18 Hours
85% <= 24 Hours
Priority 3:
85% <= 48 Hours
98% <= 72 Hours

P1:
a. An end-user(s) experiences a complete
or substantial loss of critical service.
b. A Reseller mission critical business
process is not working.
c. A complete outage of critical service.
d. An outage of a critical service impacting
>10% of the Resellers end-user base using
the Resellers rebranded backup product (by
Deliverable Recipient).
e. End- user data/confidentiality is or may
be breached.
P2:
A defect results in a significant consumer
impact, but can be circumvented.
b. Certain functions within the software are
disabled, but critical services remain
operable.
c. There are repeated periods of product
instability or severely reduced performance
affecting more than 10% of users.
d. An outage of a critical service impacting
between 1 - 10% of the Resellers end-user
base using the Resellers rebranded backup
product (by Deliverable Recipient).
Page 19 of 30
e.
Impacts partners revenue collection
P3
a. The end-user experiences no loss of
critical service and the incident has no
significant effect on the usability of the
Application.
b. Critical service performance or failure
affecting less than 1% of the users (by
Deliverable Recipient).
P4
All other incidents or problems not covered
within the above (Low impact on the enduser and no urgency on fixing the defect)
E-mail
system
Online chat

Page 20 of 30
APPENDIX 5: Governance structure

The Goverance structure for Customer Service is illustrated below. The governance structure is designed to
support one BU/reseller, but more BUs/resellers can be combined into the same governance model (ie the
issues for more than one BU/reseller are discussed in the same meetings).
(Illustration to be updated)
The following meetings constitutes the governance model for requests and incidents. Change has its own
Governance process though the project governance established for non-predefied changes. Predefined
changes is handled through the meetings specified below:
Weekly/bi-weekly operational meetings
This meeting is designed to follow up on the operation of the 1. line function. The objective is to follow up on the
defined SLAs/KPIs. It is based on the weekly SLA/KPI reports and will address any deviation to the SLA/KPIs. If
the BU/reseller is responsible for the 1. line customer service/support themselves, TBIS will only participate upon
request.
Actions coming out of this meeting should be addressed and solved within the time frame until the next
operational meeting (1 2 weeks). An operation meeting action point report should be maintained to follow-up
actions defined in the meetings. TBIS will be responsible to plan, execute and provide needed input/outputs from
these meetings.
Monthly tactical meetings
This meeting governs more tactical issues that not necessarily is covered by the SLAs/KPIs and it has a broader
audience. The main purpose of this meeting is to share the insights collected in 1. line customer service/support
with a broader audience (sales, product and marketing people) the benefits of these can be incorporated into
future products and campaigns.
Similarely, the meeting will act as an arena for sales and product managers to inform about upcoming campaigns
and initiatives that directly will affect the Service Desk function in 1. line.
Actions coming out of this meeting should be addressed and solved within the time frame until the next tactical
meeting (1-3 months). TBIS will be responsible to plan, execute and provide needed input/outputs from these
meetings.
When an identified improvement requirement cannot be decided in the operational review meeting, it will be
proposed for further discussion in the strategic meeting. These meetings can be incorporated as part of the
regular status meetings between the BU/TBIS KAM and project meetings. Frequency can be
increased/decreased upon need (more frequent during startup, less frequent later.)

Page 21 of 30
Bi-annual strategic meetings

These meetings has the perspective of initiatives that takes longer to implement and typically are more complex
in nature. The objective of the meeting is to define an overall improvement plan for customer service/support the
coming 6 12 months.
TBIS will be responsible to plan, execute and provide needed input/outputs from these meetings.
Summary governance structure

Meeting/scope
STRATEGIC
Improvement meeting
Freq
2x year
Resp
TBIS Service Desk
Manager
Agenda:
Development plan,
commercial issues
Input/
output
In:Ticket report past 6
months
In: KPI report past 6
months
Subjective
evaluations
Out: strategic plan
coming 6-12 months
Participants
BU
SPOC
Product manager
TBIS
KAM
TBIS product
manager(s)
TBIS Customer
Service Manager
TBIS delivery
CS (2. line)
Teamleader CS or
KAM
TACTIC
Performance meeting
Monthly
TBIS Service Desk

Manager
Agenda
Incidents (KPIs, how
to avoid incidents)
Changes/work orders
(status, accounting of
hours included
service fee vs CRs)
Operational
evaluation
Evaluation of
performance
In:Ticket report
In: KPI report
Out: Work plan
coming 1-3 months
BU
SPOC
Product manager
(Project manager)
TBIS
KAM
(project manager)
TBIS product
manager(s)
TBIS Customer
Service Manager
TBIS delivery
representative.
CS (2. line)
Teamleader CS
OPERATIONAL
Current issues in
Service Desk
Weekly
TBIS Service Desk

Manager
In:Ticket report
In: KPI report
Out: Action tasks
TBIS
TBIS Customer
Service Manager
CS
Teamleader CS
(Project members/BU
participants as
needed.

Page 22 of 30
APPENDIX 6: Reporting
Ticket reporting
For Requests and Incidents, the following will be reported upon (from Kayako ticketing tool):
Type of inquiry (support or customer service)
severity level (for support issues)
what product/ISV it is related to
type of inquiry (request, incident, changetc)
Grouping of recurring inquiries (what questions seem to be most frequent)
Response time, resolution time
Where does the inquiry come from (BU/reseller) in what marked (NO, SE, DK, HU etc)
Frequency: Weekly and monthly.
Call statististics
In addition to ticket reporting , regular contact center statistics will be available for calls:
AHT (Average Handling Time how long the agent works on the inquiry)
Waiting times (measured against SLA on mail, phone, chat etc)
Dropped calls
Frequency: Weekly and monthly.
Operations report on Parallels platform
For the Parallels platform, the following report will be provided on a monthly basis (within 10 business days
following a month):
System uptime KPIs
Infrastructure KPIs for data center availability
Platform KPIs for application element availability
Process KPIs covering key processes between Broker Platform and Microsoft
o order flow from Broker Platform to Microsoft
o covering backward synchronization from Microsoft TBIS Broker Platform
Frequency: Monthly.
Distribution of reports
Reports or links to reports will be distributed according to the distribution list in Appendix 7.

Page 23 of 30
APPENDIX 7: Contact information

Contact information
Same number during regular business hours as outside business hours (24/7).
Type
Request
Function
BU
Phone
E-mail
2. line Service Desk
+47-21004879
+46-101992261
+45-88166600
+36-19876846
Level 3 and 4
incidents
heretohelp@tapstorm.no
heretohelp@tapstorm.se
heretohelp@tapstorm.dk
heretohelp@tapstorm.hu
heretohelp@tapstorm.rs
Level 1 and 2
incidents
Change
Norway
Sweden
Denmark
Hungary
Serbia
Norway
Sweden
Denmark
Hungary
Serbia
Norway
Sweden
Denmark
Hungary
Serbia
Norway
Sweden
Denmark
Hungary
Serbia
+47-21004879
+46-101992261
+45-88166600
+36-19876846
+47-21004879
+46-101992261
+45-88166600
+36-19876846
Escalation contact information

If an request, incident or change is not handled within the specified SLA, it may be escalated through:
Type
Request
Incident
Change
Function
Name
Phone
E-mail
Customer Service
Manager
Delivery Manager
Change Manager
Dag Rune
Langehaug
Kevin Bellinger
Stian Alapnes
+47 93234904
+47 94133702
+47 99286851
kevinb@tapstorm.com
stian.alapnes@tapstorm.com
Notification matrix from TBIS to resellers for planned/unplanned service interruptions

Type
Sweden
Function
Norway

Medlingstjenester
toss365@telenor.com
tech.support@telenor.com
vidar.boge@telenor.com

Wunderman
skyen@telenor.dk
MS365@wundertracker.com
Product Manager:
Carsten Helmuth
CRM Campaign
Manager: Marlene
Tolstrup,
Project Manager: Peter
Scholdan,
cah@telenor.dk
mtol@telenor.dk
psk@telenor.dk
Hungary

SPOC Hungary
jpasti@telenor.hu
EMayr@TELENOR.HU
Serbia
SPOC Serbia
Milan.Markov@telenor.rs
Denmark
N/A
Phone
E-mail
Ownit: +4682502969
TN SE:
Office365.se@telenor.cm
Ownit: networks@ownit.se

Page 24 of 30
Distribution matrix for weekly and monthly ticket reports

Type
Sweden
Function
N/A
N/A
Michael F Berglund,
Process Manager,
Enterprise
E-mail
Michael-F.Berglund@telenor.com
Daniel.Hansson@telenor.com
Patric.Larsson@telenor.com
Daniel Hansson,
Operative Product
Manager VAS,
Enterprise
Patric Larsson,
Operative Product
Manager VAS, Mobile &
SME
Norway
Denmark
Product Manager:
Carsten Helmuth
CRM Campaign
Manager: Marlene
Tolstrup,
Project Manager: Peter
Scholdan,
cah@telenor.dk
mtol@telenor.dk
psk@telenor.dk
jas@telenor.dk
reth@telenor.dk
Jacob Steen, Business

Manager
SME Market, Business
Division
Hungary
Serbia
Other
Rene Thejsen, Digital

Services
SPOC Hungary
SPOC Hungary
Service Desk Manager
Marked Manager/TBIS
Delivery Manager/TBIS
Team
Manager/GoExcellent

jpasti@telenor.hu
EMayr@TELENOR.HU
Milan.Markov@telenor.rs
henrik.bentzen@tapstorm.com
kevin.bellinger@tapstorm.com
Johan.Soderberg@goexcellent.com
Page 25 of 30
APPENDIX 8: Process for handling incidents

Needed information to raise tickets for incidents:
Contact information (Customer name/customer number, name of person, e-mail, phone)
What products/platforms are affected?
Initial evaluation of the Ticket severity (Priority 1-4)
Number of impacted customers
Actions that caused issue. If you performed any actions that could cause the issue, please describe
them in details.
Error message(s). Did you receive an error message while performing this task? If so, please copy and
paste it below (please provide the exact error message if available.
Reproducibility. What are the steps to reproduce this issue/error (the more specific you are, the faster
we can troubleshoot the issue).
Initial technical fault diagnosis on notification of fault from the end customer
describe actions already taken to find a resolution.
does the 1. line and/or the customer allow direct contact between customer and 2nd and/or 3rd line?
Process for incidents handled within business hours
The Incident may originate either by a) an end customer or b) Level 1 Service Desk c) BU/reseller
Operations.
TBIS Customer Service (2. line) will receive the inquiry by mail or phone.
TBIS Customer Service (2. line) will classify the incident (Level 1 4) and register the incident in
Kayako ticketing tool.
The requestor will receive a confirmation by e-mail with a reference id enabling the requestor to follow
the status of the incident continuously.
Any incident that TBIS Customer Service (2. line) cannot resolve (due to knowledge or authority/access
level), will be forwarded to appropriate entity, including:
o Datacom
o the ISV in question
o Telenor Operation
o TBIS operation team
Upon completion, TBIS Service Desk (2. line) will update ticket status in Kayako to closed and
requestor will be notified (by e-mail for level 3 and 4, by phone and/or mail for level 1 and 2 incidents).
Process for incidents handled outside business hours
The Incident may originate either by a) an end customer or b) Level 1 Service Desk c) BU/reseller
Operations.
The requestor will call the same number as for Service Desk during business hours.
When calling this number outside business hours, the requestor will be informed in local language that:
o Service Desk for normal inquiries is now closed and the corresponding opening hours.
o If the call is about a severe incident, the call will be forwarded to our 24/7 that will respond in
English.
o If the 24/7 does not answer, it is because traffic is high. However, they will call back at the first
possibility.
The 24/7 function will classify the incident (Level 1 4) and register the incident in Kayako ticketing tool.
The requestor will receive a confirmation by e-mail with a reference id enabling the requestor to follow
the status of the incident continuously.
If the incident reported is classified as either Severity 1 or Severity 2, it will be forwarded to the
appropriate entity, including:
o Datacom
o the ISV in question
o TBIS operation team
If the Incident is classified as Severity 3 or 4, the customer will be informed (during the call) that it will be
handled by the Level 2 Service Desk the following business day and resolution time will be calculated
from start of that business day..
The Incident will be resolved according to the agreed SLA with the ISV or Datacom.
Upon completion, TBIS Service Desk (2. line) or the 24/7 function will update ticket status in Kayako to
closed and requestor will be notified by e-mail.
Planned and unplanned service interruptions detected by 2. line and/or 3 rd line Service Desk
In the case where a planned or unplanned service interruption is initiated/detetected by 2. line or 3rd line, all
resellers will be informed through the specified contact matrix in Appendix 7.

Page 26 of 30
Escalations
In case an incident is not resolved within the defined SLA, requestor or the 24/7 function may escalate through
TBIS management. Contact information in Appendix 7.

Page 27 of 30
APPENDIX 9: Process for Change/work orders

Depending on the nature of the change inquiry, 2 differenet processes will be adhered to:
Predefined Changes/Work orders
Non-Predefined Changes/Work orders

The initial step for both processes will for both predefined or non-predefined be that the requestor registers new
changes/work orders directly in Kayako (if the requestor has a user id) or by sending and e-mail labelled
Change/work order to the relevant e-mail address supplied in Appendix D.
After the requestors initial submittal of changes/work orders in Kayako, Level 3 support (TBIS platform and
product team) will give a first response within 2 working days. The first response will classify the Changes/Work
orders as predefined or non-predefined, and also include a first scope evaluation, and how to proceed. When to
deliver is part of first response for Predefined changes.
Predefined Changes/Work orders
These changes/work orders have a predefined lead time and predefined amount of effort to complete. Note:
Lead time and effort is indicative/advisory
FAT passed
CAT passed
Delivered
+2
+2
+5
-
Development finished
+2
+2
+2
+2
+5
+5
-
Func./comm. Signoff
Name/description
Moving multiple users between TOSSes
Establishing new TOSS
Adding new standard MS products
Adding dealerID in bulk
New service plan
New basic reseller
*Minor CRs
Requirements agreed
Below is a table of predefined tasks with their respective lead time (SLA Business Days) and efforts (both
indicative, but should be confirmed by the first response to requestor.)
+3
+3
+8
+10
+10
-
+3
+3
+9
+3
+12
+12
-
+4
+4
+12
+14
+14
-
+5
+5
+14
+5
+14
+14
-
SLA
(Business Days)
< 5 days
< 5 days
< 14 days
< 5 days
< 14 days
< 14 days
< 5 days
Effort
(hrs)
6
7
39
4
31
39
2
Moving multiple users between BUs/resellers Upon request TBIS will move users between two
BUs/resellers. The requester is responsible for providing data identifying which users to move between
which BUs/resellers.
Establishing new BU/reseller Upon request TBIS will establish a new BU/reseller and enable this
BU/reseller to be chosen by customers during onboarding (i.e., selectable in the shop).
Adding new standard MS product Upon request TBIS will add additional MS products that can be
provisioned via MOSI. This includes making it available in the shop for either sales partners or
customers to buy.
Adding dealerID in bulk Some Bus/resellers makes use of dealerID to track sales to their sales
organizations/dealers. The TBIS system already holds an overview of many dealers, and upon request
TBIS will add more dealerIDs.
New service plan If the BU/reseller decides to add new products (i.e., other than MS products) to their
portfolio, a new service plan can be needed. Upon request TBIS will add service plans. The first step in
this process would be to work together on the scope, product definitions, pricing, etc., meaning this
should be run as a product involving both the requester and TBIS.
New basic reseller If the BU/reseller decides to approach different customer segments than they
currently do, one possibility is to set up a separate reseller for this purpose. Upon request TBIS will set
up a new sub reseller. The first step in this process would be to work together on the scope.
Non-Predefined Changes/Work orders

Non-predifed changes/work orders are all Changes requested that are not classified as Pre-defined
Page 28 of 30
There will be a great variety in the complexity and scope of non-predefined changes/work orders. Thus, these
have a case by case lead time and amount of effort to complete
The first response from TBIS (ref above) aim to include an evaluation of scope of the change/work order, when to
deliver and how to proceed. Note that a Non-Predefined change in many cases will imply a commercial process
with a sub-contractor, meaning that time and price cannot be confirmed before a commercial binding from subcontractor is available.
Below a further description of the process for non-predefined changes/Work orders follows.
Detailed process for non-predefined changes/work orders
The CR phased process is designed to ensure that the needed interactions and decisions points between TBIS
and Reseller is taken care of in a structured matter. Also the process will ease the status reporting and progress
tracking of CRs. To facilitate this there are some milestones built into the process.
Figure 1 Phases in the change/work order process .
Change/work
orderreceived
TBIS
by
REQ
Requirements
agreed
Proposal
1.
2.
3.
4.
Functional/
commercial signoff
Development
Development
finished
TBIS receives the CHANGE/WORK ORDER and categorizes it. If it is in a category that is
familiar and has an SLA connected to it, the Change/work order is taken forward according
to that SLA.
Requester gets a receipt within 1 working day, acknowledging that the Change/work order
is received. Requests are managed in Kayako, and a reference will be sent as part of this
mail, and be used in all further communication.
Requester gets the first response within 2 working days, suggesting how the Change/work
order will be delivered.
In this process the requester and TBIS agree on the scope and the requirements. For
smaller requests, such as moving customers between TOSSes this can be streamlined
and standardized by passing specifications along with the request itself e.g. by adding a
table with the relevant information. For bigger requests a workshop or other structured way
of collecting and agreeing on requirements should be used. Tapstorm solution architect(s)
will be available for technical discussions if needed.
Requester and TBIS
Milestone: Confirmation that requester and TBIS agree on the requirements.
Requester will receive a notification at this point.
Requester and TBIS
Requester is informed
In the proposal phase TBIS aligns internally, and if necessary with partners to find the best
way of delivering on the requirements.
Output will be presented to requester, and will in general hold this information:
Delivery model (who will deliver what)
Overview of which requirements can be delivered on, and which cannot be delivered on
Time estimate
Cost estimate
TBIS
Milestone: Requester agrees to the terms put forth in the proposal.
This means that the scope of work is settled, and that all additional requirements or
functionality that are put forth on a later stage are not to be delivered on, unless the
requester demands that a new time and cost estimate is given. (This can potentially delay
the ongoing work.)
If an agreement cannot be reached the Change/work order can be moved back to the REQ
phase (for changing the scope/requirements) or it can be stopped (e.g. if the cost is too
high to justify the functionality or if vital requirements cannot be delivered on).
Requester
During this phase the solution is being developed.
TBIS (and sub-contractors)
Milestone: The development has finished and is ready to be tested by TBIS.

Page 29 of 30
FAT
FAT
passed
CAT
CAT
passed
Production
Delivered
FAT: Factory Acceptance Test. In this phase TBIS runs internal testing to make sure the
solution delivers according to the requirements.
In general there is (at least) one test scenario per requirement. The testing itself is
facilitated by professional test manager(s) on TBIS side.
TBIS
Milestone: Passed TBIS internal testing, and ready for requester to do CAT (UAT).
TBIS
CAT: Customer Acceptance Test. In this phase the requester runs testing to make sure the
business requirements are met and that the solution is working in the integrated
environment in Telenor Norway.
Requester
Milestone: The requesters tests are passed and the (new) functionality is ready to be put
into production.
Requester
This is the final phase where the solution to the Change/work order is put into production.
Typically this involves technical enablement of the solution as well as regression testing to
make sure the production version behaves in the same way as the test version.
Milestone: Solution is verified to function and to be up and running in the production
environment.
TBIS

Page 30 of 30

Tbis - Spoc Customer Service and Support Model - 2014 06 18

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Tbis - Spoc Customer Service and Support Model - 2014 06 18

Caricato da

Copyright:

Formati disponibili

Tapstorm SPOC Service Desk model

- Requests: Customer service for requests from customers and BUs/resellers.

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

Dag Rune Langehaug

First version of merging Support

Telenor Business Internet Services AS.

May 20, 2014;

June 18, 2014

Added input from Stian Alapnes

ROLES AND DEFINITIONS

Minimal disruption of services

Reduction in back-out activities

Economic use of resources involved in the change

The term encompasses that this function has a broad responsibility:

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

Appendix 1: Severity levels on Parallels platform incidents

1. line Service Desk as standalone product

Telenor Business Internet Services AS.

Telenor Business Internet Services AS.

LEVEL 3: TBIS, ISV OR HOSTING PROVIDER SUPPORT

Hosting provider for the Parallels platform

Telenor Business Internet Services AS.

Response Time of TBIS to OMT

Telenor Business Internet Services AS.

APPENDIX 1: Severity levels for Parallels platform incidents

Definition of incident urgency and impact in ISV services

The damage caused by the Incident increases rapidly.

Work that cannot be completed by staff is highly time sensitive.

Several users with VIP status are affected.

The damage caused by the Incident increases considerably over time.

A single user with VIP status is affected.

Work that cannot be completed by staff is not time sensitive.

The damage to the reputation of the business is likely to be high.

A moderate number of customers are affected and/or inconvenienced in some way.

The damage to the reputation of the business is likely to be moderate.

Telenor Business Internet Services AS.

Spesific definition of incident severity on Parallels platform

Mission critical service is down and no workaround is immediately available:

The production Parallels Automation system is down or unavailable.

A business-critical feature described in the documentation is not available or functioning.

Requests for information about software usage.

Telenor Business Internet Services AS.

APPENDIX 2: Severity levels for spesific Incidents on Paralells platform

Reseller cannot load the PBA, POA or Customer Control Panel

Password/users for platform users

Telenor Business Internet Services AS.

APPENDIX 3: SLA for incidents on Parallels platform

Parallels platform operation critera and SLA

Status for 80% of Incidents within 15

Status for 90% within 4 hours

Status for 90% within 8 hours

Post- resolution time update

90% resolved within 4 hours

Every 4 hours during business day

90% resolved within 8 hours

* Example: ticket raised Monday at 10 has a target resolution of Wednesday at 10

Telenor Business Internet Services AS.

APPENDIX 4: ISV SLAS

Partner Playbook page 48. During the