SERVICE LEVEL MANAGEMENT

Important Factors to structure SLA

1. Will the SLA structure allows flexibility in the levels of service to be delivered for various customers?
2. Will the SLA structure require much duplication of effort?
3. Who are the stakeholders who will sign the SLAs?

Service Level Management, or SLM, is defined as being responsible for ensuring that all its service management
processes, operational level agreements, and underpinning contracts, are appropriate for the agreed upon service
level targets.

A service level agreement (SLA) is a commitment between a service provider and a client.
Particular aspects of the service quality, availability, responsibilities are agreed between the service provider and the
service user.

The most common component of SLA is that the services should be provided to the customer as agreed upon in the
contract.

Different providers combine low level services such as network and server administration, database tuning etc. to
deliver high level services to customers. Therefore, service processes are progressively crossing organizational
boundaries. Service processes must be very flexibly adaptable to the customer’s requirements. These requirements
are more quickly changing than in traditional business processes, where material products are created. The
customer does not “see” a physical product and therefore often expects, that all changes can be implemented
immediately.

Flexibility is the capability to implement changes of the requirements in the business process model and instances by
changing only those parts of the business process model and instances that reflect the change.

Criteria of
Change

Abstraction Subject of Properties of

Level of Change Change Change

Type Functional Extent Duration Swiftness Anticipation

Instance Organizational Incremental Temporary Immidiate Planned

Behavioral Revolutionary Permanent Defferred Ad-Hoc

Informational

Operational

➢ The functional perspective describes what the process has to do; particularly it defines the process goal.
➢ The operational perspective describes activities executed during the process.
➢ The control perspective defines, when and under which preconditions activities are performed.
➢ In the informational perspective the information that shall be exchanged between activities is defined.
➢ The organizational perspective describes who participates in which roles in the process.
First, service processes show a high degree of division of labour, requiring many interactions between the service
provider, the customer and third party service providers.

Second, service processes extensively use external resources both from the customer and third party service
providers that have to be appropriately obtained, integrated and administered.

Third, not only the execution but also the potential to execute the service process is important to the customer.

These properties of service processes require, that the subjects of change for business processes described in have
to be extended. This will be done be introducing three new perspectives: the interaction, the resource and the
service level perspective.

Interaction perspective

A characteristic of service processes is their high degree of division of labour with a high involvement of external
participants. In traditional production processes the customer is only interested in the outcome of the process but
not the process itself. In service processes, there are many interactions between the service provider, the customer
and third party service providers. Both need to be integrated during the whole process, not only at the beginning
and the end of the process.

The customer has to be asked for further details about the incident report.

Advice is sought from the third level support.

In the example of there are problem solving interactions between all levels of support and the customer.

As service processes contain many interactions, it is necessary to provide flexibility in changing and integrating new
interactions into the process.

Interactions need to be adapted to changed customer requirements and new interactions have to be integrated due
to new customer requirements.

To achieve this, a new perspective has to be created when defining the metamodel for service processes.

This perspective is called interaction perspective.

Resource perspective

Service processes differ from traditional business processes also because they extensively use external resources
both from the customer and third party service providers.

Resources have to be appropriately obtained,

integrated and administered.

The computer system in Fig. 2 is such a resource.

For example, before the customer’s computer system

can be configured, one has to have administrative
privileges.

Finally customer resources have to be given back at

the end of the service provision.

To properly represent changes in the resource

perspective, it must be simple to add, change and
remove resources.

Service level perspective

Not only the execution but also the potential to execute

the service process is important to the customer.

It is important for the customer that his staff may call

the service desk and get a reaction within a predefined
reaction time.

Therefore service providers have to make available a predefined potential to perform a service process.

This potential is measured as service level.

In the example above, a service level defines the maximum reaction time.

To reach a certain service level as defined in a service level agreement, resources have to be kept ready, as services
cannot be stored as material products.

In the example, one has to keep ready properly trained staff available in the service desk, regardless of whether
there are calls or not.

The service level perspective is needed to define the potential to perform activities.

It describes the rights and duties for the customer and the service provider, the service performance indicators
(SPIs), the measurement of the service performance indicators and change procedures.

Service levels agreements have to be easily adaptable to changing business requirements.

Here the service process is split up into perspectives and perspective elements, to show the additional subjects of
change found in service processes. Each perspective is shown as separate layer.

Criteria of
Change

Abstraction Subject of Properties of

Level of Change Change Change

Type Functional Extent Duration Swiftness Anticipation

Instance Organizational Incremental Temporary Immidiate Planned

Behavioral Revolutionary Permanent Defferred Ad-Hoc

Informational

Operational

Interaction

Resource

Service level
Service processes have special properties:

They show a high degree of interaction with external participants such as the customer and subcontractors.

Another difference to standard business processes is the integration of external resources, for example the
customer’s computer system into the process.

Finally, service processes not only have to produce a defined process output but they have also to provide a defined
potential to provide the process output called service level.

These properties elicit new kinds of flexibility necessary to properly support service processes.

Furthermore, there is a conflict between the need for flexibility of service processes and the product nature of
service processes.

It can be reduced by using component-oriented approaches.

KEY AREAS

Your business to adapt your customer experience strategy.

Helps companies to turn their complaints into customer satisfaction

Take the opportunity to improve the customer service process

Employees that are not able to be flexible within a customer experience process are naturally inclined to begin a
customer interaction on the defensive. So, being met with such stern opposition to what they feel is a reasonable
request, customers tend to increase their demands, and around and around we go.

Conversely, employees that know they have been given the ability to decide upon each situation themselves means
starting interactions open, flexible and giving. Creating in return customers that feel inclined to be reasonable.

In these type of flexible interactions whether an employee actually fulfils a customer’s request has far less impact on
the overall experience for the customer than in situations where the employee is uncompromising. For the
employee’s choice of action results not from mindlessly repeating company policy but out of a reasoned and fair
discussion where the customer actually feels heard.

The multi-level SLA prevents unnecessary duplication effort and can be very effective approach. It is important that
the SLM understand the relationship between the various services and customers

Corporate Level SLA

Business Unit Level SLA
Corporate level SLA

ITIL focuses on three types of options for structuring SLA

1. Service-based
2. Customer-based
3. Multi-level or Hierarchical SLAs.

1. Corporate level:
All of the general issues relevant to the organization are covered, and they are the same throughout the entire
organization.

For example, with security SLA at the organization level, every employee needs to create passwords of 8 characters
and must change it every thirty days—or every employee needs to have an access card with an imprinted
photograph.

2. Customer level:
Those issues specific to a customer can be dealt with.
Security requirements of one or more departments within the organization are higher. For example, the financial
department needs more top security measures by virtue of its crucial role and handling of financial resources.

3. Service Level:
All issues relevant to a specific service (in relation to the customer) can be covered.

Applies to all customers that contract the same service — for example, contracting IT support services for everyone
who uses a particular IP telephony provider.

Activities

1. Identifying business requirements by working with business units

2. Establishing the scope of services, timeliness, hours of operation, recovery aspects, and service
performance
3. Translating business requirements into IT requirements
4. Developing and maintaining a service catalogue, including costs for different tiers of service performance
5. Performing gap analysis between business requirements and available services.
6. Determining the costs related to services such that service goals satisfy business needs at a price the
business can afford
7. Drafting, negotiating and refining SLAs with the business units, ensuring business requirements are met
and agreement from all parties involved
8. Implementing SLAs
9. Measuring SLA performance, reporting results and adjusting as necessary

Identifying Business Requirements

This is the process of discovering, analysing, defining, and documenting the requirements that are related to a
specific business objective. And it's the process by which you clearly and precisely define the scope of the
project, so that you can assess the timescales and resources needed to complete it.
A good business requirements analysis helps you achieve this objective. It leads you to better understand the
business needs, and helps you break them down into detailed, specific requirements that everyone agrees
on. What's more, it's usually much quicker and cheaper to fix a problem or misunderstanding at the
analysis stage than it is when the "finished product" is delivered.

Five-step guide to conducting your own business requirements analysis

1. Identify Key Stakeholders

a. Identify the key people who will be affected by the project
b. who the project's sponsor is
c. identify who will use the solution, product, or service
2. Understand Your Key Stakeholders
a. What interest do they have in the outcome of your work?
b. Is it positive or negative?
c. What motivates those most of all?
d. What information do they want from you, and what is the best way of communicating with them?
e. What is their current opinion of your work? Is it based on good information?
f. Who influences their opinions generally, and who influences their opinion of you?
g. Do some of these influencers therefore become important stakeholders in their own right?
h. If they aren’t likely to be positive, what will win them around to support your project?
i. If you don't think that you’ll be able to win them around, how will you manage their opposition?
j. Who else might be influenced by their opinions?
k. Do these people become stakeholders in their own right?
3. Prioritize Your Stakeholders
4. Capture Stakeholder Requirements
a. Understand these different perspectives and gather the different requirements to build a complete
picture of what the project should achieve.
 b. Be clear about what the basic scope otherwise end-users may be tempted to describe all sorts of
functionality that your project was never designed to provide
i. Technique 1: Using stakeholder interviews
ii. Technique 2: Using joint interviews or focus groups - good idea to keep asking "Why?" for
each requirement. This may help you eliminate unwanted or unnecessary requirements, so
you can develop a list of the most critical issues.
iii. Using "use cases"
iv. Technique 4: Building prototypes
5. Categorize Requirements
a. Functional Requirements – These define how a product/service/solution should function from the
end-user's perspective. They describe the features and functions with which the end-user will
interact directly.
b. Operational Requirements – These define operations that must be carried out in the background to
keep the product or process functioning over a period of time.
c. Technical Requirements – These define the technical issues that must be considered to successfully
implement the process or create the product.
d. Transitional Requirements – These are the steps needed to implement the new product or process
smoothly.
6. Interpret and Record Requirements
a. Once you have gathered and categorized all of the requirements, determine which requirements
are achievable, and how the system or product can deliver them.
b. Define requirements precisely – Ensure that the requirements are: •Not ambiguous or vague.
c. Clearly worded.
d. Sufficiently detailed so that everything is known. (Project over-runs and problems usually come
from unknowns that were not identified, or sufficiently well-analysed.)
e. Related to the business needs.
f. Listed in sufficient detail to create a working system or product design.
g. Prioritize requirements – Although many requirements are important, some are more important
than others, and budgets are usually limited. Therefore, identify which requirements are the most
critical, and which are "nice-to-haves".
h. Analyze the impact of change – carry out an Impact Analysis to make sure that you understand fully
the consequences your project will have for existing processes, products and people.
i. Resolve conflicting issues – Sit down with the key stakeholders and resolve any conflicting
requirements issues. You may find Scenario Analysis helpful in doing this, as it will allow all those
involved to explore how the proposed project would work in different possible "futures".
j. Analyze feasibility – Determine how reliable and easy-to-use the new product or system will be. A
detailed analysis can help identify any major problems.
7. Sign Off
a. Make sure you get the signed agreement of key stakeholders, or representatives of key stakeholder
groups, saying that the requirements as presented precisely reflect their needs. This formal
commitment will play an important part in ensuring that the project does not suffer from scope
creep later on.

The key to a successful business requirements analysis is identifying what the new system or product will do for
all appropriate end-users/stakeholders – and to understand what they WANT the new system or product to
do.
You can use various techniques to gather requirements, but make sure those requirements are clear, concise,
and related to the business. This process also helps you identify and resolve any conflicting requirements
issues early on.
Once you complete your analysis, record it in a written document. This becomes the "contract" for creating the
product or system that addresses all the needs of your business or your client.

Impact Analysis. This technique is a useful and severely under-used brainstorming technique that helps you
think through the full impacts of a proposed change. As such, it is an essential part of the evaluation
process for major decisions.
Impact analysis is the proverbial "look before you leap," the “what if” that stops a foolhardy move that can
come from knee-jerk reactions to change.

If some aspect of your business is disrupted, what are the consequences? How will it affect your team, your
budget, your profit, your losses and your future? An impact analysis is a formal way of collecting data and
supposition in support of the pros and cons in any change or disruption to your business. Good impact
analysis will help you identify recovery strategies, prevention methods or means of mitigating impacts to
the business.

1. Conduct an Evaluability Assessment

➢ An evaluability assessment is an initial appraisal of whether an impact assessment should be

conducted on the project and, if so, what is the most appropriate methodology to do so.
➢ An important part of the evaluability assessment involves sitting down with project staff to work
through a causal model for all the project activities to be covered in the impact assessment.
➢ This means determining what exactly the project is doing or will do, over what time period, and
with which expected outputs, outcomes, and impacts.
➢ If this discussion indicates that the hypothesized relationships between project activities and
impacts are unrealistic, or if the project time frame is unsuitable (as a general rule, a minimum of
two years is necessary for sustainable impacts to occur), then the impact assessment is not
worthwhile.
➢ The evaluability assessment should also consider the purposes that would be served by the impact
assessment, its potential audience, its cost-effectiveness, and its potential credibility, along with
the best timing for conducting the impact assessment.
➢ The evaluability assessment is conducted prior to conducting the baseline impact assessment. It is
also important, however, to conduct a modified evaluability assessment prior to conducting the
follow-up impact assessment.
➢ The purpose in this case is to determine
o Whether it is worthwhile to invest in the follow-up assessment at all or
o Whether to reduce the scope of the impact assessment light of events that have occurred
since the baseline.

2. Prepare a Research Plan

The research plan should include the causal model of the impact assessment and a practical plan for
carrying out the study. The causal model is used to generate a set of hypotheses about outcomes and
impacts that will be tested in the study.

Typically, impacts of several different types will be anticipated at three levels:

➢ In the value chains and markets involved, including product markets and sometimes also
supporting markets for inputs, business services, and/or finance
➢ Among participating MSEs
➢ In the households associated with participating MSEs

Once testable hypotheses have been identified, the next step is to define measurable indicators that
can be used to determine whether impact has been achieved.

After that, sources of information for measuring the indicators must be identified.

This involves selecting a sample of project participants (explicitly defined in a manner consistent with
the project’s structure and approach) and matching it with a sample of non-participants who are as
similar as possible to the project participants in all relevant characteristics (the control group).

This must be done carefully to minimize the effect of selection bias—the tendency for people who
would have done better anyway to become project participants—which leads to overstatement of the
project’s impact.
 The research plan should also include detailed specifications for the questions to be asked on the
survey questionnaire and guidelines for the interviews and focus group discussions.

➢ Define the extent of the change proposed

➢ Determine key differences in the changed state (proposed) from a point of reference or the
original state
➢ Focus on the possible effects of the key differences from step #2
➢ Sort and prioritize the possible effects (#3) from the key differences (#2) based on risk and
possibility
➢ Make a decision using the results

To define a project scope, you must first identify the following things:
➢ Project objectives
➢ Goals
➢ Sub-phases
➢ Tasks
➢ Resources
➢ Budget
➢ Schedule

Once you've established these things, you'll then need to clarify the
1. Limitations or parameters of the project
2. Clearly identify any aspects that are not to be included.
In specifying what will and will not be included, the project scope must make clear to the stakeholders, senior
management and team members involved, what product or service will be delivered.
The project scope should have a tangible objective for the organisation that is undertaking the project.
The basis of the project scope should entail your goals and objectives to be one that follows a SMART guideline.
That is, to be Specific, Measurable and Achievable. It should also be Realistic and completed within a specific
Timeframe.

➢ Specific–This involves stating accurately what the project wants to achieve. That is, what, why and how
these will be done. Clarity will reduce the chances of ambiguities and misunderstandings.
➢ Measurable –Are your goals and objectives able to provide feedback and be accountable for?
➢ Achievable –Can your project’s goals and objectives be achieved, given the resources on hand?
➢ Realistic –Are the goals and objectives easy to deliver, especially if you face problems or complications.
Will these reduce the overall quality of the project’s outcome and cause running over budget and not
meeting the set deadlines?
➢ Time Frame –Can your project goals and objectives be met within the allocated time frame? Is it a key
criterion to meet these deadlines?

Translating business requirements into IT requirements

➢ Need to have a very good document about what the client wants. Good gathering of information, clear
objectives, scope well defined. This is what is called the Business Case
➢ Collect the business requirements and rules.
➢ Have a clear understanding of the end-product.
➢ All documented in the Business Requirements Definition (BRD)
➢ Involve the BSA in the business requirements gathering process and the definition of what needs to be
done
➢ Involve people with knowledge of the system you are going to update early in the process.
➢ The Business Analyst should prepare all interview questions before the requirement gathering session,
based on experience and also should inform the stakeholders about getting back to them at a later
point of time with more questions specific to functionalities and features
➢ For translating business requirements to system specifications would be to try the describing of the
business goals into the user stories, which are small and very concise statements of functionality
needed to deliver a very specific value to a particular stakeholder.
Mistakes
➢ Error is when the BSA responsible of doing the translation wasn’t involved in the processes mentioned above
and he is going to start asking more questions answer he is not going to be involve in the subject. BSA to do
the translation as he is the one with technical knowledge.
➢ If the BSA is new, then give him a good and extensive training of the current application (this is another big
usual mistake).
➢ BSA’s not considering the future state or considering that client needs may possibly evolve in the future.
➢ Making assumptions – Business Requirements are essentially high-level requirements provided by the
business and mostly consists of what they want to resolve – ‘Business Problem’
➢ Do not make assumptions about requirements and functionalities expected.
➢ To avoid asking the client the finer aspects related to functional specifications and elements of design of the
proposed software solution. This should be avoided at all costs as if you assume incorrectly – the entire
solution development process could be affected and efforts wasted.
➢ System Specifications should be Implementation Neutral – meaning it should be free of design details unless
the design has been already finalized. This restricts the development team and the Design (UX/UI) team
from designing the application as per Industry standards and might result in improperly designed systems
which are not intuitive at all.
➢ New to the project process stakeholders is that they would, when asked about their requirements, start to
give the technical solutions in the forms of the steps of a software they already have been using previously.
The easiest remedy to get on track quickly is to ask them what the project doesn’t need to be doing after a
quick brainstorming session to start transforming the “not to do list” into the valid requirements.
➢ The business requirement is used as the system requirement as well. Though this means there is one less
document but it can cause problems as both documents are intended for different audiences and need
different levels of detail.
➢ System specification are sometimes created by someone who hasn’t interacted with the client directly, like a
system architect or a BSA. It can happen that the non-functional requirements requested by the client may
get missed; or, the document can be prepared by the BA who prepares the business requirements, but he
might not have the same level of expertise as a system architect. So, there needs to be a sign-off between
the system and business requirement.
➢ Quality of system requirements document – the system requirements can be inconsistent in their conversion
or copy-pastes of the business requirement documents.
➢ When translating the Business Requirement document to System Requirements is talking about only
functional requirements and missing non-functional and hardware-software parts.
➢ One other big one is Load Testing or performance tuning of the application.
➢ The functional requirement document does not provide cross reference to the Business requirement of the
same item. This happens primarily due to bulk of changes keep happening on the BRD. Close monitoring of
the problem will help provide a clear reference between the two documents.
➢ Not elaborating the requirements while scripting it. E.g. writing one liner descriptions in the user stories and
not mentioning the minor details
➢ Accepting the requirement without knowing the impact can break the system.

What is the IT / ITIL Service Catalog

The service catalogue is at the core of IT service delivery and contains a centralized list of services from the IT
service portfolio (the service portfolio includes the entire lifecycle of all IT services – services in
development, services available for deployment, and retired services) that are available for customer use.
Within the IT service catalogue, you will find an organized, digitized presentation of all of the IT services
that your company provides – from resetting a lost password to accessing a financial system.

The typical service catalogue is composed of two views:

1) The customer view

This is how the end-customer experiences the service catalogue. Usually presented using an IT self-service
portal, this view presents services in customer terms and gives them the means to initiate service requests.
 2) The technical view

This is intended for internal IT resources and includes technical information that is required to effectively deliver
a service, including important relationships, approval processes, and impact on related services.
The service catalogue should be designed with the end customer in mind. Most importantly, the information
necessary to request a service needs to be clearly defined with easy to understand instructions. Some of
the key service information includes:
➢ Name of the service
➢ Description of each individual service
➢ Service category (i.e. Infrastructure, Software, Hardware, Video, Support, etc.)
➢ Supportive and related services
➢ Service Level Agreement (a contract between the service provider and end-customer defining the
expected level of service)
➢ Who can request the service
➢ Service owner
➢ Costs associated with the service
➢ Delivery expectations
➢ Who to contact with questions
The service catalog should be tightly integrated into the customer-facing IT self-service portal, through which
business users can request IT services that are defined within the service catalog. In other words, the service catalog
powers the options displayed within the portal’s user interface (UI). Services are pre-defined (and bundled when
necessary) and associated with automated workflow processes that notify approvers and staff of the tasks or
activities that need to be performed in order to deliver the requested service(s). The business user can then monitor
and track the status of their service request throughout the approval and delivery process.

1. Select the right team

Include people from throughout the IT department to develop the service catalog—this will ensure that you have
support from senior staff and the stakeholders responsible for providing each of the services.

2. Scope out services

To determine what to include in your service catalog, consider the services IT currently provides, the services IT is
capable of providing, and finally, the services IT might provide in the future. Be as inclusive as possible: Speak to
team leaders and managers, and all levels of support staff. Group services into service categories (such as Email,
Applications, Hardware, etc.).

3. Define the services

Take the list of service categories from step two, and define the types of support available to customers in each one.
You can set up workshops with customers to get a view into the required and expected levels of support—these
workshops will help you gain consensus from service users.

4. Establish who supports the services

Identify the IT service owner for each service category, as well as the first, second, and third levels of support, and
what support each of these levels provides.

5. Review supporting services and levels of support

The service catalog is a living document: during its lifecycle, you may need to retire a service based on feedback from
support services. Always back up this decision with evidence to counteract any objections.

6. Produce two versions

The service catalog has two audiences—customers and the business. The customer version of the service catalog
contains only relevant top-level information. Keep it brief, and avoid techy talk. The technical view service catalog
should include information relevant to IT and service providers.

7. Agree on a review process

Establish a process for reviewing and updating the service catalog to add and remove services and support levels as
necessary
Purpose and Objectives of Service Catalog Management

The purpose of the service catalog management process is to provide and

maintain a single source of consistent information on all operational services
and those being prepared to be run operationally and to ensure that it is
widely available to those who are authorized to access it.

The objectives of the service catalog management process are to:

•Manage the information contained in the service catalog
•Ensure that the service catalog is accurate and reflects the current details,
status, interfaces, and dependencies of all services that are being run,
or being prepared to run, in the live environment, according to the defined
policies
•Ensure that the service catalog is made available to those approved to access it in a manner that supports their
effective and efficient use of service catalog information
•Ensure that the service catalog supports the evolving needs of all other service management processes for service
catalog information, including all interface and dependency information.

Scope of Service Catalog Management

The scope of the service catalog management process is to provide and maintain accurate information on all services
that are being transitioned or have been transitioned to the live environment. The services presented in the service
catalog may be listed individually or, more typically, some or all of the services may be presented in the form of
service packages.

The service catalog management process covers:

•Contribution to the definition of services and service packages
•Development and maintenance of service and service package descriptions appropriate for the service catalog
•Production and maintenance of an accurate service catalog Interfaces, dependencies, and consistency between the
service catalog and the overall service portfolio
•Interfaces and dependencies between all services and supporting services within the service catalog and the CMS
•Interfaces and dependencies between all services, and supporting components and configuration items (CIs) within
the service catalog and the CMS.

The service catalog management process does not include:

•Detailed attention to the capturing, maintenance and use of service asset and configuration data as performed
through the service asset and configuration management process.
•Detailed attention to the capturing, maintenance and fulfillment of service requests as performed through request
fulfillment.

Value to the Business

The service catalog provides a central source of information on the IT services delivered by the service provider
organization. This ensures that all areas of the business can view an accurate, consistent picture of the IT services,
their details and their status. It includes a customer-facing view (or views) of the IT services in use, how they are
intended to be used, the business processes they enable, and the levels and quality of service the customer can
expect for each service.

Through the work of service catalog management, organizations can:

•Ensure a common understanding of IT services and improved relationships between the customer and service
provider by utilizing the service catalog as a marketing and communication tool
•Improve service provider focus on customer outcomes by correlating internal service provider activities and service
assets to business processes and outcomes
•Improve efficiency and effectiveness of other service management processes by leveraging the information
contained in or connected to the service catalog Improve knowledge, alignment and focus on the ‘business value’ of
each service throughout the service provider organization and its activities.
Types of Service Catalog

The structure and presentation of the service catalog should support the uses, to which it will be put, taking into
consideration the different, sometimes conflicting needs of different audiences. Not every service is of interest to
every person or group. Not every piece of information about a service is of interest to every person or group.
When service providers have many customers or serve many businesses, there may be multiple service catalog views
projected from the service portfolio. When initially completed, the service catalog may consist of a matrix, table or
spreadsheet. Many organizations integrate and maintain their service portfolio and service catalog as part of their
CMS.
By defining each service as a CI and, where appropriate, relating these to form a service hierarchy, the organization
is able to relate such things as incidents and requests for change to the services affected, thus providing the basis for
service monitoring and reporting using an integrated tool (e.g. ‘list or give the number of incidents affecting this
particular service’).
It is therefore essential that changes within the service portfolio and its constituent service catalog are subject to the
change management process. It is advisable to present more than one view of the information in the service catalog
to accommodate the different needs of those who will use it.

In order to ensure that both the customer and IT have a clear understanding of the relationship between the
outcome-based, customer-facing services and the business processes they support, it is recommended that a service
provider, at the minimum, defines two different views, each one focusing on one type of service:
•a view for customers that shows the customer-facing services,
•a second view for the IT service provider showing all the supporting services.

The data stored in the service catalog regarding relationships and dependencies between items would allow
information in one view to be accessed from another when deemed appropriate.

Service catalog has two views.

•Business/ Customer Service catalog view and
•Technical Service catalog view.

The business/customer service catalog view:

This contains details of all the IT services delivered to the customers (customer-facing services), together with
relationships to the business units and the business processes that rely on the IT services. This is the customer view
of the service catalog. In other words, this is the service catalog for the business to see and use.

The technical/supporting service catalog view

This contains details of all the supporting IT services, together with relationships to the customer-facing services they
underpin and the components, CIs and other supporting services necessary to support the provision of the service to
the customers.

Benefits

1. Enabling a better understanding between business units and IT

2. Setting more accurate service quality expectations and effectively measuring, monitoring and reporting
service quality
3. Clearly delineating roles and responsibilities
4. Providing the necessary flexibility for business to react quickly to market conditions
5. Creating more accurate infrastructure sizing based on clearly defining service levels
6. Avoiding or mitigating the costs of excess or insufficient capacity
7. Providing discipline in supporting internal or external sourcing of IT services

Document Structure

1. An introduction to the SLA, what does this agreement propose

 2. A Service description, what service this SLA supports and details of the service
3. Mutual responsibilities, who’s responsible for what part of the service
4. Scope of SLA
5. Applicable service hours, from what time till what time is the service available according to the agreement
6. Service availability, how much is the service available during the service window and outside of the service
window
7. Reliability
8. Customer support arrangements
9. Contact points and escalation; a communication matrix
10. Service performance
11. Security
12. Costs and charging method used

Steps for implementing ITIL Service Level Management:

1. Gather the data.

Identify a SLM manager and form a team to spearhead the implementation. The team must perform several
duties:
o Assess current state. Discover where and to what extent CM work is being performed today and
document current reports, distribution lists, policies and procedures.
o Inventory tools and software currently used for monitoring, capacity planning, performance
management, and charge back, all of which support SLM processes.
o Collect budget details that pertain to capacity management work.
o Perform a gap analysis to reveal areas that require process improvements, training, or software.
o Develop a project plan to migrate to the new organization based on required changes you uncovered.

2. Build the plan.

The implementation plan should:
o Establish the three major components of capacity management - people, processes and tools.
o Outline the costs necessary to sustain the new organization and build a preliminary budget.
o Determine where the service level manager should be placed in the organization, ideally reporting
directly to the CIO, IT Director or within the service management group.
o Describe workflow, including data inputs, information outputs, and work processes.
o Allocate sufficient time for training the people performing the work.
o Identify any necessary work to acquire, consolidate and/or implement capacity and performance
tools.
Be sure to communicate the organization and its processes to the rest of the company, preferably through
your internal corporate communications team.
Once the project plan and budget are complete, they should be submitted for approval.

3. Execute the plan.

You will want to execute the project plan in a series of steps:
o Assign the staff.
o Document and publish the processes. This is an important step that will likely take considerable time
during initial implementation.
o Acquire and implement the tools. Ideally, a single tool would be used to provide the data and reporting
necessary for accurate reporting of service performance.
o Inventory IT services and build a service catalogue. Be sure service definitions meet Financial
Management's requirements, such that utilization data can be obtained and associated to a particular
service.
o Identify, develop, negotiate and implement SLAs and OLAs. Close work with business units is required.
SLAs and OLAs should be a page or two in length and include:
✓ Parties involved
✓ Start, end and review dates
 ✓ Scope of the agreement
✓ Description of the services provided
✓ Roles and responsibilities of each party involved
✓ Hours of operation
✓ Service availability
✓ Service reliability
✓ Support
✓ Throughput, transaction times and/or response times
✓ Change turnaround targets
✓ Security requirements and considerations
✓ Service continuity
✓ Service costs and how they are charged
✓ Service reporting
✓ Service incentives and penalties

o Identify any required services not currently provided by IT and resolve any contradictions in service
requirements vs contingency recovery time, for example.
o Define metrics to measure success. Be sure to tie your metrics to business value, not technical
measures. Metrics should be few in number, yet succinct and to the point.
o Build training materials and execute the training plan. Develop the training materials based on the
processes you drafted and test staff members to ensure retention.
o Implement reporting and exception processes and procedures. Two types of reporting are necessary.
High-level reporting, used to keep management informed, often takes the form of a dashboard, using
colours to depict service quality. Be sure to report both current status and how it is trending. The
second type of reporting is more detailed for use by the SLM team to identify problematic service areas.

4. Initiate the ongoing work of SLM.

Begin the reporting process. Include the ability to:
o Automatically alert the SLM team when services are in danger of missing performance targets due to
bottlenecks or sudden spikes in demand.
o Automatically alert the SLM team when trends show performance is approaching agreed-upon limits, so
that corrective actions can be taken to prevent service outages or poor service performance.
o Schedule monthly or quarterly review meetings to discuss service performance results. Initiate any
changes required as a result of unforeseen business events or changes in business priorities.

5. Post implementation review.

o Document lessons learned and identify any changes that should be made to the process to facilitate
future process migrations.
o Perform a post-implementation audit 6-12 months after completion to determine if the new processes
are being adhered to and if you're getting expected results.

An ideal service management solution will

1) Benefits for Your Customers
o Getting reports on all completed projects.
o Online self-service task registration
o Increased customer satisfaction and goodwill

2) Benefits for Your Employees

o No more filling out tiresome paper reports
o Convenient task scheduling with mobile app
o Better structured daily work schedule with lunches and breaks considered
o Decrease in travel time
 3) Benefits for Your Project Managers
o Automatic work order planning and allocation
o Automated regular task scheduling
o Real-time data on work progress, action plan and location of employee
o Faster response time for calls
o Increased work efficiency and report management

4) Benefits for Your Overall Business Operations

o Central database, easily accessible by all employees
o Analysis of activity clusters made possible
o Decrease in drive time, and overtime for field employees
o Better customer service.
o Increase in transparency, decrease in fraudulent instances
o Increased cash flows by encouraging efficiency

Key Responsibilities:
1. Own end to end service.

2. Customer relationship
Understands, develops, builds, maintains and improves the customer relationship for one or a small number of
strategically important customers, with regular reviews at a strategic level.

3. Delivers
Delivers contractual SLA performance, resolves customer contractual issues and continually drives improvements in
customer satisfaction.

4. Participate
Participate in NPS survey process and associated closed loop process

Participate in Your Say Care forums, practice lead forums, performance management, people programmes &
personal development plans & all hands calls at all levels within GS

5. Capitalises
Capitalises on all opportunities to improve the overall customer experience and to own the overall service
relationship on behalf of BT at mid to senior level within the customer business base.

6. Acts
Acts as the primary service interface between the customer and BT

7. Provides
Provides stakeholder management within BT, customer and/or third party supplier’s organisations.

To provide the Lead/Senior Service Interface into the BTGS Account & Contract Teams by building and maintaining
excellent relationships.

8. Builds and maintains

Builds and maintains collaborative relationships with key suppliers.

9. Works
Works effectively with offshore Service Management support aligned to their accounts

10. Creates and drives

Creates and drives change within the business via service improvement and cost reduction plans.
 11. Responsible
Responsible for managing the Service Costs for defined Accounts including monitoring budgets and input into
DMS/BRF builds

12. Optimises
Optimises the cost profile of the Service Management roles on their accounts

13. Creates value

Creates value, acts as a trusted advisor, manages expectations and can negotiate mutually beneficial outcomes and
resolve conflict.

14. Possess
Possess an in-depth working knowledge of the customer’s business and understand the competition environment.

15. Influences
Influences business decisions and outcomes at mid to senior management level.

16. Supports sales

Supports sales activities such as bids, by assisting with setting Service Level Agreements, reviewing and agreeing
service schedules and service designs

17. Involved
May also be involved in new business initiatives, providing service information to support Bids.

18. To lead
To lead and deliver formal work programmes in line with business and customer requirements

Leads and manages virtual/ matrix teams of experts/specialists/BT service staff.

May have line management people responsibilities.

CONTRIBUTIONS
To Drive
➢ Improvement of CSAT/DISAT & customer loyalty for their assigned customers
➢ Improvement of BT’s overall service performance through programmes, (e.g. GS Customer Experience
programme, RFT, SIP/SDP, Challenge Cup, Personal Objectives, etc.)

To Understand
➢ Baseline costs on allocated contracts. Produce “cost to serve” forecast and actuals, for managed contracts
that have dedicated resources.

To Manage
➢ Manage BT money as if it were your own by driving costs/transformation initiatives to reduce spend,
enhance revenue and increase margin, (e.g. Cost to serve, reduced ticket volumes, etc.)

To Support
➢ Support your manager, peers and colleagues across BT to ensure we are operating a single cohesive team
focused on customer service and a cost base that is competitive in the market place.
➢ Delivery against agreed personal objectives and team/BT scorecards.
➢ All achievements will be measured through BT Group, GS and CS&CIO SCORECARD objectives and the
standards set for the unit.
PERSONAL MEASURES
SMART WAY
➢ Re-record personal greeting on your mobile/team phone voicemail on a daily basis, advising of any potential
delay in responding.
➢ Maintain your email signature to reflect BT standards in terms of disclaimers, information to display.
➢ Whereabouts published on directory.
➢ Advertise all contact details on the directory, including mobile/team phone number.
➢ Ensure an Out Of Office notification is recorded on MS Outlook and voicemail detailing an alternative contact
while you are away.
➢ Accurately complete your timesheets on GS Prime by COP each Friday.
➢ Effectively manage your A/L allocation across the fiscal year to ensure all is taken within that period unless
agreed with your line manager.
➢ Ensure your Expenses claims are submitted each calendar month.
➢ Travel authority process followed where required.
➢ Complete/maintain all mandatory training/accreditation without receiving line manager reminders.

CUSTOMER FOCUSED
➢ Actively/regularly maintain all customer documentation and processes storing on the appropriate BT
SharePoint and customer repository. This should include all customer reports, meeting minutes, customer
handbooks and handover documents.
➢ Own and maintain a customer risk register that highlight associated BT and Customer risks, mitigate where
possible and gain sign off of acceptance of risks.
➢ Record and drive customer complaints through the standard GS Complaints process.
➢ Own and drive Customer Satisfaction, Dissatisfaction and Loyalty activities, using the tools available, to
deliver improvements year on year. This should include regular checks/use of Customer Dashboard & use of
NPS closed loop process
➢ Update customer dashboard on a regular basis. Updates to be clear & concise so that issues are clearly
understood, with agreed actions & owners defined and clear timelines set. Updates to be appropriate for the
senior leadership team who have visibility of all issues raised via the customer dashboard.
➢ Ensure, where appropriate, that all your customer contacts are available on Salesforce for NPS surveys.
➢ Develop, drive and regularly maintain Service Improvement Plans and or Service Development Plans for all of
your customers, which drive/deliver tangible benefits.
➢ Manage contracts within the boundaries of their contractual commitments and cost builds and provide
tangible tracking and real-time management to reflect this.
➢ Manage SLA performance to target or better across all of the contractual commitments.
➢ Demonstrate cost control/ management across discretionary spend, customer contract activity, mobile use,
time booking, etc., to ensure maximum revenue and minimum expenditure.
➢ Grow your ITIL capability by ensuring you have completed both the V3 Awareness and Foundation courses
on BT’s Route to Learn.

BEHAVIOURAL
➢ Adopt and deliver a proactive approach to dealing with day to day customer activity, including owning,
driving and keeping people informed in the pursuit of service excellence. This includes identifying root
causes, driving remedial activity and sharing best practice.
➢ Manage contracts within the boundaries of their contractual commitments and manage SLA performance to
target or better.
➢ Track and manage contract costs by investigating/taking action initiatives to improve efficiency, reduce work
volumes and improve cycle times.
➢ Actively demonstrate and drive team work and collaboration internally and externally whether with
customers, suppliers or colleagues.
➢ Drive the deployment and use of self-help and portal mediums to both reduce cost and enhance the
customer experience.
 ➢ Complete and document an annual service review with each of your clients where you present the overall
performance and value add of BTGS to that client.
➢ Demonstrate inspiration by suggesting, owning and driving transformation of customer contracts.
➢ Make every effort to attend and participate in Team meetings and All Hands calls, whether your own team
or delivered by senior managers.
➢ Actively lead/participate in Your Say Forums to ensure accurate reflection of issues/concerns.
➢ Support business transformation & change whether local or broader initiatives by using your
skills/knowledge to advantage BTGS and its customers
➢ Demonstrate change by suggesting, owning and driving transformation of customer contracts you manage.
To deliver tangible reductions in the cost to serve for BT, improvements in CSAT, DISAT & Loyalty, etc.
➢ Recognise sales opportunities and engage appropriate account/business personnel to realise tangible
improvements to revenues and margins.

❑ Demonstrate a balance view in terms of both positives and negatives when presenting/communicating to
customers whether in Service Reviews or reports. Actively articulate the value adds and benefits BT bring to the
table.

❑ Respond to messages left in a timely manner.

❑ Meet deadlines for any information requested or respond appropriately if these are likely to be missed.

❑ Treat people (customers, suppliers, colleagues) with the same honesty and respect that you would want to
receive yourself.

❑ Show Pride. We are proud to make a difference however small, we continually strive for RFT, we stand up for BT
where ever we are and work to get people to become advocates for BT.
A service is an activity or series of activities of a more or less intangible nature that normally, but not necessarily,
take place in interactions between the customer and the service employees and/or physical resources or goods
and/or systems of the service provider, which are provided as solutions to customer problems.

Here are the 10 key benefits of ITSM:

• Lower costs for IT operations

• Higher returns on IT investments
• Minimal service outages
• Ability to establish well-defined, repeatable, and manageable IT processes
• Efficient analysis of IT problems to reduce repeat incidents
• Improved efficiency of IT help desk teams
• Well-defined roles and responsibilities
• Clear expectations on service levels and service availability
• Risk-free implementation of IT changes
• Better transparency into IT processes and services

The following steps are best practices that can help simplify the implementation and efficient use of ITSM processes
and workflows:

1. Audit your current ITSM operations and identify the gaps

a. It’s best to identify your organization's early goals and then work your way up.
b. Involve the right people
c. Deploy the relevant technology
d. Choose the right workflows
e. Be aware of what's at stake and the potential risks involved
f. Be prepared with strategies for recovery in circumstances where initiatives fall through the cracks.
2. Educate, communicate and involve stakeholders while implementing ITSM process
a. help employees embrace the change
b. create a culture that is receptive to change
c. ensuring that all stakeholders are convinced about the benefits of strategizing and implementing
d. ensure that everyone involved is on the same page
3. Outline critical success factors and keep tabs on KPI metrics
a. Monitor performance using metrics and KPIs to ensure continuous improvement.
b. Generate various reports containing both high-level and granular data
c. Aiding in performance analysis and decision-making.
d. Measure the right metrics and KPIs
i. Lost business hours vii. Cost per ticket
ii. Change success rate viii. Asset utilization rate
iii. Infrastructure stability ix. Incident response time
iv. Ticket volume trends x. Incident resolution time
v. First call resolution rate xi. Reopen rate
vi. SLA compliance rate xii. Problem resolution time
4. Use relevant tools to automate process
a. Identify key processes and their e. Plan ahead for the future
dependencies f. Evaluate tools available in the market
b. Consult with ITSM experts g. Don't stop with the capabilities of the
c. Choose a deployment option ITSM tool
d. Differentiate the "needs" from the
"wants" in your feature checklist
5. Develop a feedback loop from end users and other stakeholders
Where is ITSM headed?

• Rising focus on consumer experience • Demand for business intelligence to support

• Compulsion to automate critical decisions
• Coping with BYOD culture • Emphasis on enterprise service management
• Ascension of the "social IT" approach (ESM)

1. Focus on value
a. Know how service consumers use each service.
b. Encourage a focus on value among all staff.
c. Focus on value during normal operational activity as well as during improvement initiatives.
d. Include a focus on value in every step of any improvement initiative.
2. Start where you are
a. Look at what exists as objectively as possible, using the customer or the desired outcome as the
starting point.
b. When examples of successful practices or services are found in the current state, determine if and
how these can be replicated or expanded upon to achieve the desired state.
c. Apply your risk management skills.
d. Recognize that sometimes nothing from the current state can be re-used.
3. Progress iteratively with feedback
a. Comprehend the whole, but do something.
b. The ecosystem is constantly changing, so feedback is essential.
c. Fast does not mean incomplete.
4. Collaborate and promote visibility
a. The first important step is identifying and managing all the stakeholder groups that an organization
deals with.
b. The first and most obvious stakeholder group is the customers, as in service management the
organization’s main goal is to facilitate customer outcomes. Others are
i. Developers working with other internal teams
ii. Suppliers collaborating with the organization
iii. Relationship managers collaborating with service consumers
iv. Customers collaborating with each other
v. Internal and external suppliers collaborating with each other
c. The contribution to improvement of each stakeholder group at each level should be understood, as
should the most effective methods to engage with them
d. Insufficient visibility of work leads to poor decision-making, which in turn impacts the organization’s
ability to improve internal capabilities
e. Depending on the service and the relationship between the service provider and the service
consumer, the expectations about the level and type of collaboration can vary significantly
f. It is important to involve stakeholders, and address their needs at all levels
g. Collaboration does not mean consensus
h. Communicate in a way the audience can hear
i. Decisions can only be made on visible data
5. Think and work holistically
a. Recognize the complexity of the systems
b. Collaboration is key to thinking and working holistically
c. Where possible, look for patterns in the needs of and interactions between system elements
d. Automation can facilitate working holistically
6. Keep it simple and practical
a. Ensure value
b. Simplicity is the ultimate sophistication
c. Do fewer things, but do them better
d. Respect the time of the people involved
e. Easier to understand, more likely to adopt
 f. Simplicity is the best route to achieving quick wins
7. Optimize and automate
a. Understand and agree the context in which the proposed optimization exists
b. Assess the current state of the proposed optimization
c. Agree what the future state and priorities of the organization should be, focusing on simplification
and value
d. Ensure the optimization has the appropriate level of stakeholder engagement and commitment
e. Execute the improvements in an iterative way
f. Continually monitor the impact of optimization
g. Simplify and/or optimize before automating
h. Use automation to reduce toil: tasks which are manual, tactical, devoid of enduring value and/or
linearly scaling
i. Define your metrics
j. Use the other guiding principles when applying this one

Customer Relations
Customer relations describes the ways that a company will engage with its customers to improve the customer
experience. This includes providing answers to short-term roadblocks as well as proactively creating long-term
solutions that are geared towards customer success. Customer relations aims to create a mutually beneficial
relationship with the customer that extends beyond the initial purchase.