Service Definition - Template

 

Fig. 1: Service definition
(YaSM checklist / document template)

Definition: A service definition specifies the service properties, in particular the offered functionality and the guaranteed service levels. Service definitions also describe how the organization's resources are used in order to provide the service. A service can be provided using one or several other (internal or external) supporting services.

Related YaSM service management process: Design new or changed services

More checklists and document templates: Service management checklists

 

A service definition typically contains the following information:

Note: Some service properties may not need to be described for particular services (for example, if a service is not customer-facing, there may be no need to deal with complaints).

 

Service Definition - Contents

Content	Description
Service name and identifier	This should include a version or release identifier to specify which release of a service is defined in the service definition document. Typically, services evolve over time, so there might be a service definition for the currently active release of a service, and another one for the next release.
Service owner	The service owner is the individual with ultimate responsibility for supplying the service as defined in the service definition.
Service type	This section specifies the service type (I.e. customer service vs. supporting service; for a supporting service, it should be stated whether the service is provided with internal resources or by an external party).
Service status	The current service status (e.g., "projected", “under development”, "activated", "retired").
Service description	Short description of the service.
Value proposition	Provide a description of how the service creates value for its customers.
Utility	A description of the service functionality, outlining the available functions, features, and capabilities that enable customers and users to achieve their desired outcomes. The functionality offered by the service should be described on a somewhat high level of detail in the language of the service customer. Example: “Field staff can access enterprise applications xxx and yyy without being constrained by location or time”. More detailed specifications may need to be created during the service design stage, especially if software applications are to be developed for providing the service.
Warranty	A description of the desired service outcome in terms of warranty (guaranteed service quality or service levels). This relates in particular to Service availability Service capacity/ performance Service continuity in the case of critical events. The section on service availability will typically contain the following information: Service times Times when the service is required to be available Times when the service may be interrupted, for example for planned maintenance work. Availability target (e.g. “99.9%”) Definition of how availability will be calculated (a service may be unavailable, for example, in certain locations only, so an exact definition of unavailability is needed to make sure all parties involved have a common understanding) Rules for the implementation of emergency changes (a description of the circumstances under which emergency changes are permitted; this is required as the implementation of emergency changes may lead to unplanned service interruptions). Depending on the nature of the service, the section on service capacity/ performance should specify Required service capacity (lower/upper limits including daily, weekly or seasonal variations), for example in terms of Numbers and types of transactions Numbers and types of users Amount of available storage space. Required service performance, e.g. in terms of response times Service scalability (allowed medium and long-term increase in workload and service utilization). The section on service continuity in the case of critical, disruptive events should specify Types of critical events covered Time within which an interim operational mode must be established, including a description of the interim operational mode and its limitations Time within which normal service operation must be restored.
Service interface	A description of how customers and users interact with the service. This can be presented, for example, in textual form or as flowcharts depicting the “customer journey”. If the service has a technical interface, any mandated technical standards must be specified.
Customer / user duties	This section should state any duties to be observed by the customer and the service users, for example security guidelines to be observed when using the service. If applicable, relevant security policies should be referenced from here.
Customer / user support	If customer/ user support is provided as part of the service, at least the following aspects should be described: Nature of support being provided (also state if support is provided remotely or on site) Types of users that are supported (for example, in terms of user roles, technical skills or languages) Types of infrastructure to be supported Hours of operation. Furthermore, rules should be specified for the handling of service interruptions (incidents)and service requests, including Procedures for raising incidents or service requests Definitions of incident and service request priorities (these should include a definition of what constitutes a high-impact or “major” incident; definitions should be in line with those used in the incident and service request resolution processes) Response and resolution times (as a function of incident or service request priority) Escalation hierarchy Rules for communicating planned or unplanned service outages.
Reporting and communication	It must be specified how customer and service provider communicate, for example by specifying Rules for measuring customer satisfaction (e.g. by carrying out regular customer satisfaction surveys) Intervals of service review meetings with the customer Rules for submitting complaints and compliments (e.g. details to be included in formal complaints, rules for assigning priorities, agreed response times, escalation hierarchy) Contents and intervals of service reports to be produced by the service provider.
Service locations	If the service is offered in a number of different locations, the locations should be stated here.
Service variations and packages	If the service is offered in a number of variations, the differences between the variations should be stated here. If the service is offered in combination with other services, the various packages on offer should be described here.
Charging scheme	If there is a charge for using the service, describe the scheme used for calculating the charges.
Dependency on supporting services	If the service depends on other (supporting) services, the dependencies should be specified here.
Limitations to service scope	For some services, it may be helpful to explicitly describe which outcomes or features are not supported, especially if the service portfolio contains a number of similar services.
Security and compliance	This section should provide an overview of any relevant security and compliance aspects and how they are addressed in the context of the service, for instance by stating What critical data are processed by the service and how are they protected How access is restricted to authorized service users What legal obligations or enterprise policies are relevant and how compliance is ensured.
Service changes	If the service defined in this document is a modified or enhanced version of a previous release, the differences to the previous release should be described.
References to other related information	This section may include references to other relevant information, for example the definitions of related services.
Additional information	Notes and additional information.

Document control information

As service definitions are controlled documents, they must contain document control information, as in the following example:

Service definition: Document information
Document name	...
Status	...
Storage location	...
Distribution list	...

 

Version history

Ver­sion	Ver­sion date	Author­(s)	Modi­fica­tions	Autho­riza­tion date	Autho­rized by
...	...	...	...	...	...

 

Status values and lifecycle

(This information is included in the lifecycle diagram for the service definition contained in the YaSM® Process Map.)

Remark

• For each service definition, there will typically be a corresponding item in the service portfolio.
• For customer services, service definitions describe the service properties which are independent of specific customers using the services. This is especially important in cases where several customers may sign up to a particular service. Service definitions are typically attached to customer service agreements, which provide a means for the service provider and the customer to enter into a binding contract.
• In the case of supporting services, service definitions describe the service properties which are independent of the internal or external parties providing the services. This is especially important in cases where several parties provide a particular supporting service. Service definitions are typically attached to operational service agreements and external service agreements, which provide a means for the service provider and an internal or external supplier of supporting services to enter into a binding contract.
• Some organizations use dedicated applications instead of a set of documents to manage their service definitions.

 

Notes

Is based on: YaSM "Service definition" template from the YaSM Process Map.

By:  Stefan Kempter   and  Andrea Kempter , IT Process Maps.

 

Definition  › Contents  › Utility  › Warranty  › Remark