VeriSM: VeriSM – Tutorial (about 60 minutes)

VeriSM is a service management approach for the digital age that looks at the whole organisation, not only the IT department, and shows how to combine many management practices into one flexible way of delivering products and services. It is used by service managers, IT and business leaders, product owners and anyone who has struggled to decide whether ITIL, Agile, DevOps, Lean or SIAM is "the right answer". After this tutorial you will be able to explain the VeriSM model, build a Management Mesh for a real service, walk a product through the Define, Produce, Provide and Respond stages, and judge where VeriSM fits next to other frameworks and standards.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: VeriSM stands for Value-driven, Evolving, Responsive and Integrated Service Management. Its body of knowledge is published by Van Haren Publishing in two volumes: VeriSM: A service management approach for the digital age (December 2017, by Claire Agutter, Rob England, Suzanne D. Van Hove and Randy Steinberg), which is the core reference, and VeriSM: Unwrapped and Applied (October 2018), which explains how to apply the model. The approach was created by the International Foundation for Digital Competences (IFDC), a non-profit founded in the Netherlands in 2017 with founding partners EXIN, BCS, APMG and Van Haren Publishing. No newer edition of the body of knowledge has been published or announced, so the 2017/2018 publications remain current; the approach is stable rather than under revision. The certification scheme is active: EXIN offers VeriSM Foundation (its current preparation guide is edition 202503) and VeriSM Professional. The official VeriSM site still names IFDC as owner of the content and scheme, while EXIN's 2025 exam documents describe VeriSM as an EXIN trademark, so check exin.com for current scheme details. VeriSM is a body of knowledge, not an ISO or national standard, and there is no certification of organisations against it. Verified 2026-10-29.

Who it is for: service managers and service owners, IT operations and support staff, product and delivery managers, people in HR, finance, marketing or customer service who contribute to services, and leaders who are accountable for how well the organisation serves its consumers. No previous service management certificate is needed.

Prerequisites: none. Some exposure to working life in an organisation that delivers services (internal or external) will make the examples easier to relate to.

How to use this tutorial: read the seven lessons in order (about 45 minutes), study the four diagrams, then spend the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why VeriSM was created, what problem it solves and what it deliberately does not try to be.
You will be able to define the core vocabulary: consumer, outcome, capability, governance, service management principles, Management Mesh and operating model.
You will be able to describe each element of the VeriSM model and the activities inside the four stages Define, Produce, Provide and Respond.
You will be able to assemble a Management Mesh for a specific product or service from resources, environment, management practices and emerging technologies.
You will be able to outline how an organisation adopts VeriSM step by step and how individuals gain VeriSM certification.
You will be able to compare VeriSM with ITIL, ISO/IEC 20000-1, COBIT, SIAM and DevOps and choose how to use them together.

Lesson 1 – Origins, purpose and scope

Why a new service management approach?

For about thirty years, "service management" mostly meant IT service management. Frameworks such as ITIL and the international standard ISO/IEC 20000 helped IT departments organise incident handling, change control, service levels and many other processes. That work was valuable, but it rested on an assumption that is no longer true for most organisations: that technology is something a separate IT department provides to "the business".

Digital transformation broke that assumption. A bank's mobile app, an insurer's online claims form or a city council's parking permit portal is not an "IT system" sitting behind the real service. It is the service, and it only works when product designers, marketing, legal, finance, contact-centre staff, suppliers and engineers cooperate. At the same time a wave of newer ways of working appeared: Agile, DevOps, Lean, Site Reliability Engineering, Service Integration and Management (SIAM), customer experience design, continuous delivery. Many organisations found themselves asking which framework to adopt, running several in parallel with little coordination, or fighting internal "framework wars".

VeriSM was designed as a response to both problems. Its creators argued that no single framework fits every product, team or situation, and that the real skill is to combine practices sensibly, guided by what the organisation is trying to achieve. VeriSM therefore works at the level of the whole organisation and offers a model for selecting and integrating practices rather than another list of processes.

How it was created

IFDC was established in 2017 to unite exam institutes, a publisher and community bodies behind one shared approach. A team led by Chief Architect Claire Agutter, with lead authors Suzanne D. Van Hove, Randy Steinberg and Rob England and more than 70 co-authors, contributors and reviewers, wrote the first book, published in December 2017. The Foundation exam became available on 1 January 2018 and the Professional exam on 24 October 2018, alongside the second volume. In 2020 IFDC and its partners released a free "10 steps" toolkit (an infographic, a canvas and a workbook) to help organisations start applying the approach.

The central ideas

Three ideas run through the whole approach:

Everyone is a service provider. Even retailers and manufacturers sell services around their products (delivery, returns, support), and public bodies serve citizens. Service management is therefore an organisational capability, not the job of one department, and VeriSM does not call for a separate "VeriSM team" to own it.
Technology-enabled services, not IT projects. Almost every business change now involves technology, so thinking of it as an "IT project" handed to a separate group leads to delays and misunderstandings.
Fit the practices to the situation. A safety-critical payment platform and an experimental marketing app should not be managed in the same way. VeriSM lets each product or service draw on a different combination of practices, within shared organisational guardrails.

Scope: what VeriSM is and is not

VeriSM is an approach and a body of knowledge. It describes concepts, a model, people and culture topics, progressive practices and the impact of new technology. It is not a process library: it does not tell you how to run incident management step by step, because frameworks such as ITIL already do that. It does not replace ITIL, COBIT, ISO/IEC 20000 or DevOps; it gives you a way to decide where each of them is useful. And it is not a standard with mandatory requirements, so there is nothing to "comply with" in a legal or audit sense. Think of it as the glue and the decision logic that sits above the individual practices.

Lesson 2 – Key concepts and vocabulary

VeriSM uses ordinary business words, but it gives several of them a precise meaning. Learn these terms before moving on to the model itself.

Consumer – anyone who receives products and services. VeriSM uses this one umbrella word instead of choosing between "customer" (who pays and sets requirements), "user" (who uses the service day to day) and "client".
Service provider – the organisation that offers products and services to consumers. In VeriSM the whole organisation is the provider; departments are capabilities inside it.
Product and service – a product is something consumers obtain and use; a service is the means of delivering value by enabling outcomes the consumer wants. VeriSM treats products and services together because consumers experience them together.
Value – the benefit both sides gain from the exchange. The consumer wants needs met and a return on what they invest; the provider wants ongoing demand that justifies its investment.
Outcome versus output – an output is a deliverable (a parcel delivered on time); an outcome is the end result of the consumer's interaction (a birthday present arrives and the recipient is delighted). VeriSM puts outcomes first.
Capability – the people, knowledge, processes and tools that let an organisation do something. Human resources, sales, finance and IT are all capability areas.
Organisational governance – the system by which an organisation is directed and controlled. VeriSM uses the three governance activities of evaluate (assess the situation and options), direct (set strategy and policy) and monitor (check performance and conformance).
Service management principles – a small set of organisation-wide guardrails, derived from governance, that apply to every product and service, for example on quality, security, risk and cost.
Management Mesh – the flexible combination of resources, environment, management practices and emerging technologies chosen to create and support a particular product or service.
Operating model – how the organisation actually works to deliver value: structures, practices, roles and tools in use. A target operating model is the desired future version.
Service culture – shared values and behaviours that put the consumer's experience at the centre, visible in what people do and say rather than in posters.
Progressive practices – newer management practices that VeriSM discusses in depth: Agile, DevOps, SIAM, Lean, Shift Left, customer and user experience (CX/UX) and continuous delivery.
Service blueprint – the detailed specification produced at the end of the Define stage, which guides the people who build and launch the solution.
Digital transformation – the change in how an organisation creates value when technology becomes part of every product, process and interaction.
Shadow IT – technology acquired or built by business teams without the knowledge of the people responsible for governing it; usually a symptom that official routes are too slow.
Silo – a team or department that works in isolation and optimises for itself; tribalism is the related behaviour of loyalty to one group at the expense of the whole.

The VeriSM materials also describe the shapes of professional skill. An I-shaped professional has deep knowledge in one area only. A T-shaped professional combines that depth with broad knowledge of neighbouring areas and the ability to collaborate across them, which is what integrated service delivery needs.

Figure 1 – The VeriSM model: governance and principles set stable guardrails, the Management Mesh adapts, and four stages turn a consumer need into an outcome.

Lesson 3 – Structure of the VeriSM model

The VeriSM model is the heart of the approach. Read it from the outside in, as Figure 1 shows. The consumer appears at both ends: their needs and requirements start the work, and the outcomes they experience (and the feedback they give) close the loop. Between those points sit the elements the organisation controls.

Governance

Every organisation is governed, whether formally by a board or informally by its owners. Governance sets the mission, the strategy, the appetite for risk and the policies that everyone must follow. VeriSM places governance on top of everything else because no product or service should be designed in a way that contradicts it. Governance flows down through the organisation: the governing body evaluates the situation, directs management through strategy and policy, and monitors what happens. Management then plans and runs the work, and operations deliver it. Information flows back up so that governors can monitor results.

Governance changes only occasionally, for example after a merger, a new regulation or a change of strategy. In VeriSM it is therefore a relatively stable element.

Service management principles

Governance is usually expressed at a high level ("we will protect customer data", "we aim to be the most trusted provider in our market"). The service management principles translate that into guardrails that apply to every product and service the organisation offers. Typical areas are quality, security, risk, cost, compliance, accessibility and sustainability. A principle might say that every service must have a named accountable owner, or that personal data must not leave the country, or that every new service must be usable by people with a visual impairment.

Two things matter about principles. First, they are defined once for the organisation and then inherited, so individual teams do not need to renegotiate basic rules for each new product. Second, they leave room for freedom: within the guardrails, each team can choose the practices and tools that suit its product. Like governance, principles are relatively stable and change only when the organisation's needs change.

The Management Mesh

The Management Mesh is VeriSM's most distinctive idea. Instead of one fixed operating model for everything, the organisation weaves together four elements in a way that suits each product or service:

Resources – what the organisation can use: people and their skills, money, time, knowledge, facilities and other assets.
Environment – the context it works in: organisational culture, market position and competitors, regulation and legislation, and the expectations of consumers.
Management practices – the frameworks, methods and standards available: ITIL, COBIT, ISO/IEC 20000, SIAM, DevOps, Agile approaches, Lean, project management methods and so on.
Emerging technologies – technology developments that change what is possible or how work is done: cloud services, automation, containers, artificial intelligence, the Internet of Things.

The word "mesh" is chosen deliberately. Like threads in a fabric, the elements are interlinked: a strict regulatory environment may push you towards more formal change practices; a team with strong automation skills (a resource) may make continuous delivery realistic; a new technology may require new skills. The mesh is also flexible. It can be stretched or reshaped for a new product without redesigning the whole organisation.

The mesh is not designed in a vacuum. The governing body and management first set strategy within the guardrails of governance and principles; the strategic plan identifies which consumer needs to address. The mesh is then built to support that strategy, and tactical and operational plans follow from the elements chosen. This order matters: if you choose practices before you understand strategy and principles, you are back to adopting frameworks because they are fashionable.

Figure 2 – The four elements of the Management Mesh are combined, within strategy and principles, into the operating model for a specific product or service.

The four stages

Below the mesh sit four stages that describe the life of a product or service from the consumer's need to their ongoing experience. They are not strictly sequential phases with formal gates; several products can be in different stages at the same time, and agile teams cycle through them quickly. Each stage works inside the guardrails of the principles and uses the elements selected in the mesh.

Define covers the activities related to designing a product or service and the outcomes it should support. It starts from the consumer need, which is often captured in a business case. Requirements are then gathered, both functional (what the service must do) and non-functional (how well it must do it: availability, capacity, performance, continuity, security, usability). The requirements describe what "good" will look like and therefore drive how the service will be measured and reported. A solution is designed, including how performance will be assured, and the stage ends with a service blueprint: a detailed specification that includes service level requirements, the support model and the agreed measurements.

Produce takes the service blueprint and turns it into a working solution. The work is to build, test and implement the product or service under change control. Testing has a specific purpose in VeriSM: to confirm that what was built meets the requirements set in Define, not only technically (functionality, compatibility, usability) but also in terms of the business outcomes it should enable. Produce is where practices such as Agile development, DevOps and continuous delivery usually play a large role.

Provide makes the new or changed solution available for consumption and keeps it fit for purpose. Typical activities include protecting the service (security, continuity), measuring and maintaining its performance against what was agreed, and improving it over time. Improvement here is continuous: data from operation should flow back into future Define and Produce work.

Respond is the support consumers receive when they have a performance issue, a question or another request. VeriSM describes two activities: record, which captures information about the contact or event, and manage, which deals with it until the consumer has an outcome, for example by resolving an issue, fulfilling a request or answering a question, and by tracing the issue to its source event. Respond also feeds insight back into the organisation, because patterns in consumer contacts often reveal design flaws.

Figure 3 – Typical activities inside the four VeriSM stages, from the consumer's need to support during live use.

How the body of knowledge is organised

The core book has 26 chapters, and EXIN's Foundation preparation guide maps its exam topics onto them in this order. The first six chapters cover the service organisation: organisational context and governance, digital transformation, service culture, people and teams, and common service management challenges. Chapters 7 to 15 cover the VeriSM model (governance, principles, the mesh and the four stages) and how to adapt it. Chapters 16 to 24 cover progressive management practices (Agile, DevOps, SIAM, Lean, Shift Left, CX/UX, continuous delivery and others), chapter 25 the impact of emerging technologies, and the final chapter how to get started. The second volume adds detailed guidance on applying the model in practice, including case studies.

Lesson 4 – How VeriSM works in practice

Adapting the model to your organisation

VeriSM describes adapting its model in three high-level steps. First, establish the principles: confirm governance requirements and agree the service management principles that every product and service must respect. Second, select a set of practices: review the management practices already in use, identify gaps and choose which practices (and which emerging technologies) to bring into the mesh. Third, create a responsive operating model: arrange people, practices and tools so that they deliver the required outcomes and can change as needs change.

Selecting practices is a judgement, not a scoring exercise. Useful questions include: What does the consumer value most for this product? How much regulation applies? How much change is expected? What skills do we have, and which are we willing to develop? Which practices already work well here, and which cause friction? The answers will differ between a regulated payment service and an internal collaboration tool, and that difference is exactly what VeriSM wants you to embrace.

Successful operating models share some characteristics: they are built around consumer outcomes rather than internal departments; they have clear accountability; they integrate capabilities across the organisation (not only IT); they are measured; and they are able to evolve. VeriSM's name itself, value-driven, evolving, responsive and integrated, is a reminder of these qualities.

Progressive practices

Part of VeriSM's purpose is to help service managers understand newer practices well enough to choose among them. In brief:

Agile – iterative, incremental work in short cycles with frequent feedback; suits products with uncertain or changing requirements.
DevOps – a culture and set of practices that bring development and operations together, supported by automation, to deliver changes rapidly and reliably.
SIAM (Service Integration and Management) – an approach to managing multiple service providers so that consumers experience one coherent service; useful when many suppliers contribute.
Lean – a focus on value from the consumer's viewpoint and on removing waste from the flow of work.
Shift Left – moving work, knowledge and quality checks earlier in the lifecycle or closer to the consumer, for example letting first-line staff or self-service resolve more requests, or testing earlier.
Customer and user experience (CX/UX) – designing every interaction with the consumer in mind, using techniques such as journey mapping and usability testing.
Continuous delivery – keeping software in a releasable state at all times through automated build, test and deployment pipelines.

Success factors for adopting any of them are similar: a clear reason linked to outcomes, leadership support, training and coaching, attention to culture and willingness to adapt the practice to the context rather than copying another organisation's version.

Emerging technologies

The mesh includes technology because new technology changes how services are built and supported. Cloud services, virtualisation and automation reduce the time and cost of providing infrastructure. Big data, the Internet of Things and mobile computing create new sources of demand and new data to manage, while "bring your own device" policies increase the variety of equipment that support teams must handle. Serverless computing, containerisation, artificial intelligence, machine learning and robotic process automation (RPA) change both the products themselves and the way service management tasks are done. For example, RPA can take over repetitive process steps so that people can concentrate on more complex work; it does not automatically mean fewer staff.

People, culture and change

Much of the VeriSM body of knowledge is about people. It distinguishes leaders, who set direction and inspire people to follow it, from managers, who plan, organise and control the work; organisations need both. It describes the competences of service management professionals, the elements of well-functioning teams (shared goals, trust, clear roles, good communication) and ways to overcome common team problems such as silos and the difficulties of virtual teams. It also discusses the challenges of managing consumer expectations and the importance of clear, two-way communication.

A service culture is the foundation for all of this. It means that people throughout the organisation understand who the consumers are, what outcomes they need, and how their own work contributes. A no-blame culture supports this: when something goes wrong despite people acting sensibly, the focus is on finding the cause and preventing a repeat, not on punishment. Culture change is usually more successful as a series of small, evolutionary changes than as one big revolution, and established organisational change models, such as Kotter's eight-stage model, can help plan it.

Roles

VeriSM does not prescribe a fixed set of roles or create a new department. Existing roles carry the work: the governing body owns governance; senior leaders own strategy and principles; service or product owners are accountable for individual products and their meshes; practitioners in every capability area (IT, HR, finance, marketing, customer service, suppliers) contribute to the four stages. What changes is the expectation that these people work together on outcomes rather than handing work over walls.

Getting started and moving from reactive to proactive

Many organisations that look at VeriSM are stuck in "firefighting" mode: they spend most of their effort reacting to incidents and complaints. VeriSM's advice is counter-intuitive at first. Instead of putting all energy into the Provide and Respond stages, where the fires are visible, invest in Define and Produce so that new and changed services are designed and built well from the start. Fixing errors after the fact keeps you reactive; preventing them makes you proactive.

Figure 4 – A practical adoption path: set the guardrails, select practices, pilot on one service, then measure and extend.

A sensible first programme often looks like Figure 4. Start by confirming governance and strategy and agreeing a short list of principles. Map the practices that already exist, including informal ones, and identify what works. Choose one important product or service as a pilot, build its mesh and operating model, and walk it through the four stages. Measure the outcomes consumers experience, not only internal outputs, and learn before extending the approach to other services. The free 10-steps toolkit from IFDC offers a canvas and workbook for structuring these conversations.

Lesson 5 – Assessment, certification and compliance

No organisational certification

VeriSM has no conformity requirements, no audit criteria and no certification scheme for organisations. An organisation cannot be "VeriSM certified", and any claim of that kind should be treated with caution. If an organisation needs independent certification of its service management, the relevant standard is ISO/IEC 20000-1, which specifies requirements for a service management system and is audited by accredited certification bodies. VeriSM can happily coexist with such a certification: the standard says what a management system must achieve, and VeriSM helps decide how practices are combined to achieve it.

Individual certifications

VeriSM certifications are for people. EXIN currently offers two levels:

VeriSM Foundation – confirms understanding of the basic concepts and how to apply a range of management practices flexibly. According to the EXIN preparation guide (edition 202503) the exam has 40 multiple-choice questions in 60 minutes, a pass mark of 65 % (26 of 40), closed book, and tests the first two levels of Bloom's revised taxonomy (remembering and understanding). The guide recommends 14 contact hours of training and estimates 56 hours of total study effort. The largest exam topics are the VeriSM model (32.5 %), people and organisational structure (20 %) and progressive practices (20 %); the remainder covers the service organisation, service culture, innovative technologies and getting started.
VeriSM Professional (preparation guide edition 202510) – tests the ability to apply VeriSM, for example creating or adapting a Management Mesh from an organisation's portfolio, principles and governance needs. The exam has 30 multiple-choice questions in 90 minutes with a 65 % pass mark and is open book. Candidates must first complete practical assignments, through accredited training or self-study. The required literature is part A of VeriSM: Unwrapped and Applied, which EXIN makes available as a free download.

In the early years the Foundation content was also offered in two halves: VeriSM Essentials (service culture, people and the model, aimed at newcomers and non-IT staff) and VeriSM Plus (progressive practices and technologies, aimed at people already holding an IT service management certificate). Neither appears in EXIN's current VeriSM catalogue. A "VeriSM Leader" level was announced as expected in 2020, but it does not appear in EXIN's current catalogue. Training is delivered by Accredited Training Organisations, and exams can be taken through them or booked directly with the exam institute. Always check the current exam rules, languages and fees on the exam institute's website rather than relying on older course brochures.

Assessing your own adoption

Because there is no formal assessment, organisations judge their VeriSM adoption by its effects. Useful evidence includes:

Documented governance requirements and service management principles that teams actually know and apply.
For each important product or service, an explicit mesh: which practices, resources, technologies and environmental constraints shape it, and why.
Service blueprints that state outcome-based measures and are used during Produce and Provide.
A balance of leading indicators (signals that predict future performance, such as the share of changes tested automatically) and lagging indicators (results after the fact, such as consumer satisfaction or the number of major incidents).
Evidence of cross-capability working: HR, finance, marketing and suppliers taking part in Define and Respond, not only IT.
A shift in effort from reactive firefighting towards proactive design and improvement over time.

Some organisations use maturity or capability models from other frameworks to structure such self-assessments. That is legitimate, but remember that VeriSM itself does not define maturity levels.

Lesson 6 – Worked example: a digital claims service at a regional insurer

Harbourline Mutual (a fictional company) is a regional insurer with 1,200 employees. Claims for storm and water damage are handled by phone and paper forms; settlement takes on average three weeks and complaints are rising. Two app-based competitors settle simple claims in days. The board decides to launch a digital claims service within twelve months. The IT department already uses ITIL-based incident and change management, a small development team is experimenting with Scrum, and the claims department has run Lean workshops. Different parts of the company each believe their own approach should be used for the whole project. The service director proposes using VeriSM to bring them together.

Step 1 – Governance

The board's strategy is to remain the most trusted insurer in its region while cutting the cost of handling claims. Its risk appetite is low for data protection and regulatory breaches and moderate for product experiments. The insurance regulator requires fair treatment of customers and timely complaint handling. These points are recorded as governance inputs; nobody on the project may trade them away.

Step 2 – Service management principles

The leadership team agrees five principles that will apply to every Harbourline service, not only the claims app: every service has a named accountable owner; customer personal data is stored only in approved data centres within the country; every customer-facing service meets an agreed accessibility standard; every service has outcome measures reviewed monthly by its owner; and any change to a live customer-facing service passes a risk-based change approval that matches its impact. The last principle leaves room for automated approval of low-risk changes.

Step 3 – Building the Management Mesh

The service owner (the head of claims) runs a workshop with IT, the contact centre, legal, finance and two suppliers, and records the mesh for the new service:

Resources: the claims handlers, a development team of eight, contact-centre staff, a budget for twelve months, existing policy data, and a loss-assessment supplier.
Environment: a cautious organisational culture, strict regulation, strong competitors with digital-first offers, and customers who are often stressed when they make a claim.
Management practices: Scrum for the app development; DevOps practices and a continuous delivery pipeline for releases; the existing ITIL-based incident, change and problem practices for live operation; Lean for redesigning the claims workflow; elements of SIAM to coordinate the loss-assessment supplier and the cloud provider; and journey mapping from customer experience design.
Emerging technologies: a public cloud region in the country (to satisfy the data principle), image recognition to help triage photos of damage, and robotic process automation to move data between the new app and the old policy system.

The mesh makes several tensions visible early. The cautious culture and strict regulation conflict with fast releases, so the team agrees that low-risk changes (text, layout) will flow automatically through the pipeline after automated tests, while changes to payment logic need a short risk review. That decision honours the change principle without creating a bottleneck.

Step 4 – Define

The consumer need comes from the business case: customers want a quick, fair and low-effort way to claim after damage to their home. Requirements are gathered with real customers and claims handlers. Functional requirements include uploading photos, tracking claim status and receiving payment directly. Non-functional requirements include availability during storms (when demand spikes), capacity for ten times normal volume, protection of personal data, accessibility and a target of settling simple claims within five working days. The solution design covers the app, the triage service, the integration with the policy system and the support model. The resulting service blueprint states the service levels, the measures (claim cycle time, customer effort score, complaint rate), the support arrangements and who owns what.

Step 5 – Produce

The development team builds the app in two-week sprints. Testing goes beyond functional checks: usability tests with customers, load tests simulating a storm, security testing, and a check that a handler can actually settle a simple claim end to end within the target time. A small pilot region goes live first under the agreed change approach, and the team confirms that the pilot meets the requirements in the blueprint before wider release.

Step 6 – Provide

Once live, the service is protected by security monitoring and a continuity plan for the cloud region. Its performance is measured against the blueprint every week and reviewed monthly by the service owner, as the principles require. Measurements show that photo triage works well for roof damage but poorly for water damage, so an improvement item is created and prioritised alongside new features.

Step 7 – Respond

Customers contact Harbourline through in-app chat, phone and email. All contacts are recorded in one place, whatever the channel, so that patterns are visible. Contacts are then managed to an outcome: questions answered, issues resolved, requests (for example to change bank details) fulfilled. Analysis of recorded contacts shows many customers asking whether their claim was received after uploading photos. That insight goes back to Define, and the next release adds an immediate confirmation message, which reduces such contacts sharply. This is the loop shown in Figure 1 in action.

What the example shows

Harbourline did not choose between ITIL, Scrum, Lean and DevOps; it used each where it fitted, inside guardrails everyone had agreed. Departments outside IT (claims, contact centre, legal, finance) took part from the start because the service, not the technology, was the unit of work. The principles saved time later, because the next service the company launched (online policy renewals) inherited them without debate and only needed its own mesh.

Lesson 7 – Relationship to other standards and frameworks

VeriSM is designed to sit above and around other bodies of knowledge, so understanding its neighbours is essential. The table summarises the most important relationships.

Framework or standard	What it is	Focus	How it relates to VeriSM
ITIL (PeopleCert)	A widely used best-practice framework for IT and digital service management	Detailed guidance on service management practices such as incident, change and service level management	A common source of management practices in the mesh; VeriSM decides where and how much of it to use
ISO/IEC 20000-1	International standard specifying requirements for a service management system	What a certifiable management system must achieve; third-party audit	Provides certifiable requirements that VeriSM lacks; an organisation can use VeriSM to choose practices that meet them
COBIT (ISACA)	Framework for governance and management of enterprise information and technology	Governance objectives, management objectives, design factors	Supports the governance element and can sit in the mesh as a practice; both stress tailoring to context
ISO/IEC 38500	International standard on the governance of IT	Principles for governing bodies; the evaluate, direct, monitor model	Uses the same evaluate, direct, monitor activities that VeriSM applies to governance at the top of its model
SIAM body of knowledge	Approach for managing multiple service providers as one integrated service	Multi-supplier integration, roles and structures	One of VeriSM's progressive practices; used in the mesh when many suppliers contribute
DevOps, Agile, Lean	Ways of working and cultural movements rather than single standards	Flow, fast feedback, collaboration, waste reduction, automation	Progressive practices covered in depth; VeriSM helps decide where each adds value

Three relationships deserve a closer look.

VeriSM and ITIL. People often ask whether VeriSM is a competitor to ITIL. The intent is the opposite: VeriSM does not replace ITIL, and organisations still need detailed practice guidance of the kind ITIL provides. The difference is one of altitude and breadth. ITIL describes service management practices in depth and has broadened over time beyond pure IT, while VeriSM takes the whole organisation as the service provider and focuses on how to combine many practices, ITIL among them. A VeriSM organisation may well use ITIL extensively for live operations and lighter, agile practices for product development.

VeriSM and ISO/IEC 20000-1. The standard says what a service management system must contain and allows organisations to prove it through certification. VeriSM does not offer that kind of assurance. They complement each other: the standard defines the destination for a management system, and VeriSM's principles and mesh are one way of deciding how to get there without forcing every product into the same mould.

VeriSM and enterprise service management. The idea of applying service management to HR, facilities, finance and other departments is often called enterprise service management. VeriSM goes a step further: rather than having each department run its own service desk, it treats all departments as capabilities of one service provider that serve the consumer together.

Common pitfalls and best practices

Pitfalls to avoid:

Treating VeriSM as a new framework to install. Organisations sometimes create a "VeriSM project team" and a new process library. VeriSM is an approach for integrating what you have; there is no VeriSM department.
Skipping governance and principles. Jumping straight to choosing practices produces a mesh with no guardrails, and teams end up arguing about basics for every product.
Keeping it inside IT. If HR, finance, marketing, customer service and suppliers are not involved, the result is just IT service management with a new name.
One mesh for everything. Copying the same combination of practices to every product defeats the purpose of a flexible mesh.
Measuring outputs only. Counting tickets closed or releases shipped without measuring consumer outcomes hides whether value is delivered.
Staying in firefighting mode. Pouring all effort into Respond and Provide while neglecting Define and Produce keeps the organisation reactive.
Believing an organisation can be "VeriSM certified". Certification is for individuals; organisational assurance needs a standard such as ISO/IEC 20000-1.

Best practices:

Write a short list of principles derived from governance, publish them widely and make them the default for every new product or service.
Make the mesh explicit for each important service, including the reasons for each choice, and revisit it when the environment or technology changes.
Start with a pilot on one valuable product or service, learn, and then extend, rather than attempting an organisation-wide rollout at once.
Invest in Define and Produce to prevent problems, and use insight from Respond to improve future designs.
Build T-shaped skills and cross-functional teams so that people can collaborate across capability areas.
Use evolutionary culture change: small, visible improvements and a no-blame approach to failures.
Combine VeriSM with detailed practice guidance (ITIL, DevOps, Lean, SIAM) and, where assurance is needed, with ISO/IEC 20000-1.

Summary and key takeaways

VeriSM (Value-driven, Evolving, Responsive, Integrated Service Management) is an organisation-wide service management approach created by IFDC in 2017; its two-volume body of knowledge dates from 2017 and 2018 and remains current.
It treats the whole organisation as the service provider and every department as a capability; service management is part of everyone's role.
The model has relatively stable elements (governance and service management principles) and a flexible element (the Management Mesh).
The mesh combines resources, environment, management practices and emerging technologies differently for each product or service.
Four stages describe a product's life: Define (needs, requirements, design, blueprint), Produce (build, test, implement), Provide (protect, measure, maintain, improve) and Respond (record and manage consumer contacts).
VeriSM complements rather than replaces ITIL, COBIT, ISO/IEC 20000-1, SIAM, Agile, DevOps and Lean.
There is no organisational certification; EXIN offers individual Foundation and Professional certifications.
To escape firefighting, focus first on getting Define and Produce right, and feed consumer insight back into design.

Reflection questions

Think of a service your organisation offers. Which departments contribute to the outcome the consumer experiences, and which of them currently see themselves as part of service management?
Draft three service management principles for your organisation. Which governance requirement does each one come from, and what freedom does each leave to individual teams?
Build a Management Mesh for one product or service you know well. Which element (resources, environment, practices or technologies) constrains your choices most, and why?
Where does your organisation spend most of its effort today: Define, Produce, Provide or Respond? What would change if you moved some of that effort earlier in the lifecycle?
Your organisation already holds ISO/IEC 20000-1 certification and uses ITIL. Explain to a sceptical manager what VeriSM would add, and what it would not.