ISO 20000 Service Acceptance Criteria Template

What are Acceptance Criteria?

One of the main outputs of the planning process group is the product acceptance criteria. The criteria define when a product is completed and accepted by the client. Getting Acceptance Criteria from the client at the start of the project is essential as it sets the measurable success criteria.
Acceptance criteria ensure that the customer or stakeholder’s requirements are met and that the service or deliverable is fit for purpose.

Acceptance criteria should be specific, measurable, achievable, relevant, and time-bound (SMART).
Examples of acceptance criteria could include:

• The service must be available 24/7
• The service must meet the agreed SLAs
• The service must be compatible with existing systems
• The service must be able to scale to increase demand

The acceptance criteria should be agreed at the start of a project or engagement. They can be used to create acceptance tests which can be used to verify that the service or deliverable meets the criteria.

The standard is structured around two key concepts:

• The Service Lifecycle, which describes the iterative process for planning, designing, transitioning, delivering, and improving IT services; and
• The Service Management System (SMS) is the framework of processes and practices used to plan, deliver, operate, and control IT services.

Organizations must implement an SMS covering all Service Lifecycle aspects. Organizations must also undergo an independent assessment to ensure that their SMS meets the standard's requirements.

The standard is relevant to all organizations, regardless of size or type. However, it is particularly important for organizations that rely heavily on IT services and those that provide IT services to other organizations.

Few traits of effective acceptance criteria

A few traits of effective acceptance criteria in ISO 20000 are as follows: -
1. Acceptance criteria should be measurable and testable.
2. They should be clearly defined and agreed upon by all stakeholders.
3. They should be achievable and realistic.
4. They should be relevant to the scope of the project.
5. They should be timely so that they can be used to monitor and control the project effectively.

Who is Responsible for Writing Acceptance Criteria?

Under ISO 20000, the Service Provider provides acceptance criteria for any new or changed services. This includes specifying both functional and non-functional requirements.

The Service Provider should work with the customer to agree on the acceptance criteria before service delivery. This will help to ensure that the service meets the customer's expectations.
The customer must agree with the acceptance criteria before the service is designed or delivered.

The customer or client is the party who will be using the product or service, so it makes sense that they should be the ones to define what they consider to be an acceptable outcome. The service provider should then use these criteria to guide the development and delivery of the service.

The Customer is responsible for approving the acceptance criteria defined by the Service Provider.
Once the service is operational, the Service Provider is responsible for monitoring the performance of the service against the acceptance criteria and taking remedial action if necessary. The Customer is responsible for monitoring the performance of the service against the acceptance criteria and escalating any issues to the Service Provider.

How Should You Format Acceptance Criteria

The service provider shall define acceptance criteria for each type of service, which shall include the following:

1. transition objective criteria
2. criteria against which the achievement of transition objectives shall be measured.
3. agreed with acceptance criteria for new or changed services.

The service provider shall use the acceptance criteria to assess whether the services delivered are fit for purpose.
When creating acceptance criteria for ISO 20000, it is important to consider both the structure and content of the criteria. The structure should be designed to make it easy for everyone involved in the project to understand and follow. The criteria should also be specific, measurable, achievable, relevant, and time-bound (SMART).

There are a few different ways that acceptance criteria can be formatted. One option is to create a separate document outlining the criteria that must be met for the project to succeed. Another option is to include the acceptance criteria as part of the project plan. This can be beneficial as it ensures that everyone is aware of the criteria that need to be met from the start of the project.

The most important thing to remember when formatting acceptance criteria is to ensure they are clear and concise. They should be written in plain language and should avoid using technical jargon. Each criterion should be independently testable so that it is clear whether it has been met. Some examples of acceptance criteria for ISO 20000 include:

• The system must be able to store and retrieve customer data accurately and securely.
• The system must be able to generate reports on customer data as requested.
• The system must be able to generate invoices and process payments.
• The system must be accessible by authorized users from anywhere in the world.
• The system must be able to handle concurrent users without performance issues.

Acceptance criteria types

There are four different types of acceptance criteria that organizations should consider when implementing ISO 20000. These are:
1. Service Level Objectives (SLOs)
2. Operational Level Agreements (OLA
3. Underpinning Contracts (UCs)
4. Service Level Requirements (SLRs)

1. Service Level Objectives (SLOs): Service Level Objectives define the specific goals that a service is trying to achieve. For example, an SLO might state that the uptime for a particular service should be 99%.

2. Operational Level Agreements (OLAs): Operational Level Agreements define the agreements between different parts of the organization to deliver a service. For example, an OLA might state that the support team will respond to incidents within 2 hours.

3. Underpinning Contracts (UCs): Underpinning Contracts are agreements with external suppliers that are necessary to deliver a service. For example, a UC might state that the organization will receive support from a particular supplier during office hours.

4. Service Level Requirements (SLRs): Service Level Requirements are the requirements that a service must meet to be delivered. For example, an SLR might state that the service must be available 24/7.

• The system must be accessible by authorised users from anywhere in the world.
• The system must be able to handle concurrent users without performance issues.