In Article 1 of the "Raiders of the lost service" series, we looked at why missing service definitions are no longer a harmless gap. They quietly undermine value reporting, risk assessment, cost transparency, and regulatory work. In Article 2, we clarified what a service actually is a supported facility for a specific customer group, and why teams, applications, and contracts are unreliable substitutes.
This third article is about getting from theory to movement. Once you accept that your current "service model" is mostly shadows, how do you start fixing it without launching another huge programme that collapses under its own ambition?
When organisations notice that their service picture is fuzzy, the typical response is scale: a service catalogue project, a CSDM (Common Service Data Model - ServiceNow) rollout, a CMDB initiative, or a "Epic service portfolio transformation". It feels serious. There is a charter, a steering group, a tool roadmap, maybe even some glossy diagrams from a vendor.
You probably know how the story goes from there:
A small group spends months wordsmithing service names and negotiating categories.
Every stakeholder insists their "area" deserves to be its own service.
A long tail of half-documented entries appears: some are systems, some are teams, some are processes, some are wishes.
After the initial push, nobody has time to maintain the catalogue, and nobody quite trusts it either.
The result is an object that looks authoritative, but cannot be used for real decisions. It is too messy for risk and continuity work, too abstract for business stakeholders, and too detached from actual support structures to help operations.
A more effective approach is to accept that you will not fix everything at once, and design your starting point accordingly.
To get started in the right direction when defining and developing services, it is valuable to define guiding principles for how these services are defined, collected, documented, and maintained. This approach ensures consistency and quality, helping stakeholders understand the relevance and scope of the process.
Instead of trying to document "all services", treat service definition as a sequence of waves that focus on where clarity will deliver the most value fastest.
- Highly visible to the business or citizens
- High risk or high regulatory exposure (e.g. NIS2, ISO 27001 Annex A 5.30 on continuity)
- Regular sources of pain and firefighting
- Significant cost items with unclear value story
- Constant sources of confusion about scope or ownership
- "Digital Workplace for Office Staff"
- "Secure Remote Access for Field Workers"
- "Citizen Self-Service Portal"
- "Clinical Documentation Access"
— not "Active Directory" or "Network Team".
For each candidate, you should be able to answer, at least roughly:
If you cannot answer those three questions, the service is a prime candidate for rescue.
Starting with a wave does two important things: it forces prioritisation — you cannot pretend everything is equally important — and it creates a manageable experimental space — you can refine your method on a small set before scaling it.
Later waves can add more services, refine earlier ones, or branch into more technical or internal services once the core model is stable.
Once you have your Wave 0 candidates, the next step is not to open the CMDB. It is to get the right people into a room and co-design the service in plain language before you touch any tools.
Here, a combination of the Value Proposition Canvas and the USM Service Model Canvas works very well.
For each service candidate, identify the main customer segment(s) — e.g. "line managers in retail stores", "citizens using self-service", "field technicians" — the jobs they are trying to get done (functional, social, and emotional), the pains that make those jobs hard or risky (delays, rework, compliance anxiety, reputational risk), and the gains they are actually looking for (faster decisions, less effort, fewer errors, feeling in control).
The point is to remind everyone that services exist to relieve pains and create gains for specific jobs — not to showcase technology.
Using what you have just uncovered, work through the seven building blocks: The Service (internal and external name, short description, and version), Parties (who is the customer, who are the users, who is the service manager/provider), Facilities (the goods and actions that make the service possible), Support (how support works — contact routes, opening times, channels, call types, standard requests and incidents), Experience (clarity, predictability, usability, empathy, and confidence expectations), Reporting (what gets reported, how often, to whom, and through which medium), and Meetings (regular governance and operational meetings related to this service).
This is where you connect the outside-in view from the Value Proposition Canvas with the inside-out reality of facilities and support — still at a level business people can follow.
The canvas session is not just a workshop. It is a decision forum: Where does this service start and stop? Which consumers are in scope, and which are out? Which facilities are truly part of this service, and which are separate services or shared capabilities? What do we promise explicitly vs. what is "best effort"?
Ambiguity here will come back to haunt you in risk, continuity, and cost work.
It is worth stressing that the Value Proposition Canvas, developed and popularised by Alexander Osterwalder and colleagues, is not just a nice visual to print on the wall; it is a disciplined way of forcing the service team to talk about customers in a structured, testable way.
- Jobs – what these people are really trying to get done in their work and lives: tasks to complete, problems to solve, needs to satisfy (functional, social, and emotional).
- Pains – what makes those jobs hard, risky, frustrating, or politically sensitive: delays, effort, compliance worries, loss of status, fear of making wrong decisions.
- Gains – the outcomes and benefits they are actually looking for: faster cycle times, fewer errors, cost savings, peace of mind, looking competent in front of others.
- The products and services that constitute the IT service — the tools, platforms, processes, and human touchpoints that together make the service possible (USM: facilities).
- The pain relievers that remove or reduce specific named pains — for example, cutting approval wait times, eliminating rework, easing compliance anxiety, or ensuring requests don't fall through the cracks.
- The gain creators that produce outcomes customers actually want — faster decisions, less cognitive load, better visibility for managers, or field technicians who can resolve issues without escalating.
You get real leverage when you treat those sticky notes as hypotheses instead of facts. The original method is very explicit about this: good teams continuously design, test, and evolve value propositions, using the canvas to make assumptions visible and to record what they have validated with customers in the field. In an IT context that means talking to real consumers and business stakeholders about their jobs, pains, and gains, and then checking whether your proposed services actually relieve those pains and create those gains — not just assuming that "self‑service" or "automation" is always a win.
In practice, I use the Value Proposition Canvas in Wave 0 as a gate before we invest effort in detailed Service Model Canvases, specifications, or agreements. If a candidate service cannot pass a simple test like "we can name the customer jobs, pains, and gains on one page, and our proposed service clearly addresses the top few," it is not ready for more documentation. That discipline keeps the first wave focused on services that have a real customer logic behind them, rather than on internal tidy‑up projects that happen to be fashionable in IT that year.
A common failure mode is to treat service definition as a side project, disconnected from how decisions are made. That guarantees that whatever you produce will be seen as documentation, not as a management tool.
Instead, you want service definition to plug into governance and your Service Management System immediately.
Three artefacts from your material are especially useful here:
Think of this as a portfolio view of all wishes and changes related to services — new services, major changes, retirements, and clean-up or documentation work.
- Every significant service-related idea appears as an initiative on this horizon.
- The horizon is reviewed regularly by a governance board or steering group.
- Prioritisation is based on value, risk, regulatory drivers, and available capacity.
That means service definition work competes transparently with other work, instead of being an invisible "we will do it when we have time" like we see with Problem and Knowledge Management.
Before an item is accepted onto the Service Horizon, require a short initiative value proposition. It should describe:
- The problem or opportunity (linked to jobs, pains, gains).
- The proposed service change (new, changed, retired, or cleaned-up service).
- Expected benefits and strategic alignment.
- Risks of doing nothing.
- Key stakeholders.
This connects the Value Proposition Canvas logic directly into governance: if you cannot explain the job, pain, and gain, the initiative is not ready.
Once you have a shared understanding captured on the canvases and embedded in governance, you still need structured artefacts that can live in tools and be used for audit and automation. The trap here is to over-engineer documentation or to duplicate the same content in multiple places.
From your existing material, three artefacts are worth treating as your minimum viable documentation set:
Your structured, tabular description of the service. It covers:
- Service identification and high-level description.
- Business context (processes supported, customers, stakeholders).
- Service context (SLAs, OLAs, operational windows).
- Vendor and contract context.
- Support context (support groups, escalation paths, maintenance windows).
- IT operations context (monitoring, backup, recovery, capacity, dependencies).
- Criticality and data classification, supporting BIA and NIS2/ISO evidence.
This is what you sync into your CMDB / CSDM structures and service catalogue, rather than populating tools manually from scratch.
Using the USM Service Agreement template, you formalise the relationship between provider and customer. It translates the canvas into alignment of expectation language:
- Parties and scope.
- Facilities, support features, and standard interactions.
- Service levels and prioritisation rules.
- Reporting and meeting cadence.
- Financial arrangements and responsibilities.
For many organisations, this is also where risk and compliance sign-off lives, including reference to NIS2 "essential/important services" where applicable.
Only after you have the above do you update your ITSM tool:
- Business and technical services in the CSDM / CMDB
- Service catalogue entries and request offerings, linked back to the Service Specification.
- Monitoring, incident, change and request categories tagged to the service.
The key discipline is translation, not reinvention: tools reflect the definitions, they do not define them. If you find yourself inventing service names or scopes directly in a tool, that is a red flag.
All of this might sound like a lot, but remember: we are talking about a small number of services in the first wave.
- Select Wave 0 services.
- Run Value Proposition + Service Model Canvas workshops for each.
- Produce draft Service Specifications and Agreements.
- Wire at least one or two services into your tools and governance flows.
- Use those definitions in real decisions.
- A risk or continuity workshop.
- A cost or showback review.
- A governance board session comparing initiatives by service.
- An audit or NIS2/ISO 27001 conversation where you can actually show a coherent chain from service to risk and controls.
- Where did the method work well?
- Where did internal politics or tool constraints get in the way?
- Which parts of the documentation set were genuinely useful, and which were overkill?
- Did the new service definitions change any decisions, or did they just create better diagrams?
Then adjust the method and decide your next move:
Expand to a second wave of services?
Refine Wave 0 only and stabilise?
Pause and focus on embedding the new definitions in risk, continuity, and financial processes?
A service model that is not actively used in risk, continuity, cost, and governance work is not worth maintaining — no matter how beautiful the diagrams or how aligned it is with the latest framework.
It is easy to get better at drawing services. It is much harder to get better at managing them. Your Wave 0 work should be judged primarily on whether it improves decisions, not whether it satisfies a theoretical definition.
In my experience, the organisations that make real progress are the ones that are willing to accept a slightly imperfect but used service model over a theoretically pristine model nobody touches. That is where the "no boiling the ocean" mindset really pays off.
Argued that service suddenly matters because value, risk, cost, and regulatory expectations have caught up with the ambiguity.
Argued that services cannot be defined by org charts and system lists — they must be seen as supported facilities for specific customer jobs.
Has tried to answer the question, "So how do we begin?", with a method that is deliberately small, governed, and connected to real decisions — making use of both Unified Service Management and Alexander Osterwalder's Value Proposition Canvas as practical tools, not theory.
"Where an external advisor can actually help" — when it makes sense to bring in external help for this kind of work, what you should expect them to do, and just as importantly, what you should not outsource if you want your service model to stick.
Because in the end, nobody can own your services for you. But someone can definitely help you find them faster.
This is Article 3 in the "Raiders of the lost service" series by TransparIT. Read Article 1 and Article 2 in the series. Next → Article 4: Where an external advisor can actually help.
How to get started without boiling the ocean