Embedding Service Design in Organizations: Maturity Model, Team Structure & ROI

Most organizations treat service design as a project: a team runs through a Double Diamond, delivers a result, and then the organization returns to business as usual. The result may be good — but the capability that produced it vanishes when the project ends.

The numbers show why this is costly. McKinsey studied 300 publicly listed companies over five years and developed the McKinsey Design Index (MDI): companies in the top quartile achieved 32 percentage points more revenue growth and 56 percentage points higher shareholder returns than the industry average [1]. But — and this is the critical point — these companies had not treated design as a project but embedded it as an organizational capability. They had top-level design metrics, cross-functional teams, and continuous user research.

The Service Design Network (SDN) arrives at the same conclusion from the other direction: in their research on organizational challenges in service design, practitioners report that 70% of problems in SD projects are organizational in nature — not customer-related [2]. What is missing is not methods or insights, but mandate, budget, access to stakeholders, and integration into decision-making processes. One practitioner reports spending 80% of her working time on internal stakeholder management rather than actual design work [2].

The question, then, is not whether service design works. The question is: how do you embed it in your organization so that it has impact beyond individual projects? This article provides a complete framework: a 5-stage maturity model, three team structures compared, an ROI framework that scales with maturity, and the six most common mistakes organizations make when embedding service design.

The Service Design Maturity Model

Maturity models for service design are well established in English-language literature but virtually absent from German-language sources. The following model is based on the work of the SDN and Koos Service Design Agency [3], extended with the five dimensions from the InVision Design Maturity Report [5] and the practical experience documented in Stickdorn et al. (2018) [4].

Each stage describes how deeply service design has permeated the organization — not how many projects have been completed. A company at Stage 3 with ten projects is further along than one at Stage 1 with thirty.

Stage 1: Explore

Service design exists as an isolated initiative. A team or individual has discovered the topic, run initial workshops, or engaged an external service provider. There is no dedicated budget, no formal process, and no metrics. The outcome depends on the energy of individual people.

Typical picture: A product manager at an insurer heard about customer journey mapping at a conference and tries it in her own project. The results are good, but no one outside her team knows about it. There is no documentation, no knowledge transfer, and no budget for a second project.

Self-assessment: If the person driving SD leaves the company — does service design disappear with them?

Stage 2: Prove

Initial pilot projects deliver measurable results. Management takes notice. There are 1-3 internal champions actively advocating for service design. First budgets are approved — but project-bound, not permanent. The evidence comes from individual successes: “We reduced onboarding time by 40% using journey mapping.”

Typical picture: The board of an automotive supplier approves a second SD project after a successful pilot in the after-sales division — this time for dealer onboarding. But each project still requires individual approval.

Self-assessment: Do you have measurable results from at least one SD project that you can show to management?

Stage 3: Scale

Service design is applied across multiple projects and business units. There is a dedicated budget (no longer project-bound), formal processes, and initial standards. A team or role is explicitly responsible for SD. The organization begins investing in SD training.

Typical picture: A bank establishes a three-person service design team that supports internal projects. There are templates for journey maps and service blueprints, a standardized workshop format, and a catalog of completed projects with documented outcomes.

Self-assessment: Is there a formal process through which business units can request service design support?

Stage 4: Integrate

Service design is embedded in business processes: new services go through an SD process as standard (not as an exception). Cross-functional teams work with SD methods. Decisions are made based on user research, not just business cases. Metrics exist at portfolio level, not just project level.

Typical picture: A telecommunications company has integrated service design as a permanent part of product development. Every new tariff structure goes through a journey mapping phase, every customer channel has an up-to-date service blueprint. The Chief Customer Officer reports quarterly on SD-driven metrics.

Self-assessment: Would a new service without an SD process be considered an exception — or the norm?

Stage 5: Thrive

Service design is no longer a department but organizational culture. Birgit Mager, the world’s first professor of service design, describes this target state as the moment when SD ceases to be a separate activity and becomes second nature [6]. The company’s language is customer-centric. Pieter Zwart, CEO of Coolblue, put it this way: “We are a customer journey agency that happens to sell electronics” [3]. At this stage, a separate SD team is no longer necessary because the mindset is embedded in every function.

Typical picture: When an executive asks in a board meeting, “What does the journey map say about this?” — and it is a normal question, not an exotic interjection.

Self-assessment: Is “How does the customer experience this?” asked as naturally in decision-making meetings as “What does this cost?”

Capital One under Jamin Hegeman is one of the best-documented examples of Stage 5: over nine years, more than 1,000 employees were trained in SD methods, journey maps became the shared language across all functions, and the company transformed entire business units with an SD mindset [7].

Important: These stages are not linear. Individual business units can be at different stages. And regression happens — for example, when an executive sponsor changes roles and the topic loses its backing.

3 Team Models Compared

Once service design grows beyond individual projects (from Stage 2-3 onward), the structural question arises: where does the SD team sit in the organization? Stickdorn et al. (2018) dedicate an entire chapter to this topic and identify three fundamental models [4].

Central Team (Center of Excellence)

A dedicated service design team that bundles all SD activities. Business units “book” the team for projects.

Dimension	Assessment
Advantages	Consistent methods and standards; knowledge transfer between projects; critical mass of expertise
Disadvantages	Becomes a bottleneck under high demand; distance from business units; can be perceived as an “ivory tower”
Best for	Stage 2-3; organizations that are just building SD capability and need consistency

Embedded Designers (Federated)

SD practitioners sit directly in product or business unit teams. There is no central SD team.

Dimension	Assessment
Advantages	Maximum business proximity; fast iteration; deep domain knowledge
Disadvantages	Inconsistent practices; designer isolation; no systematic knowledge exchange
Best for	Stage 3-4; organizations with strong business units and high autonomy

Hybrid Model

A central CoE sets standards, evolves methods, and provides training. Simultaneously, embedded designers in business units handle day-to-day work.

Dimension	Assessment
Advantages	Consistency AND business proximity; knowledge exchange via community of practice; scalability
Disadvantages	Matrix complexity; dual reporting lines; requires mature governance
Best for	Stage 4-5; large organizations with multiple business units

Practical example: Imagine an insurer with 12 business units (health, life, property, auto, etc.). A central CoE of 4 people develops the SD toolkit, trains new colleagues, and maintains the cross-cutting journey map library. In 6 of the 12 business units, an embedded service designer supports projects on the ground. The embedded designers meet monthly in a community of practice moderated by the CoE. This creates consistency without centralization — and business proximity without isolation.

The InVision Design Maturity Report confirms this pattern: organizations with the highest design maturity predominantly use hybrid models, while beginners start with central teams [5].

Selling Service Design Internally

The SDN research paints a sobering picture: service designers report spending three times more time on stakeholder engagement than planned [2]. Internal selling is not a side concern — it is half the job. Five strategies that have proven effective in practice:

1. Start with Quick Wins

Find a specific problem that is visible, manageable, and solvable in 4-6 weeks. An onboarding process that loses customers. An internal form that everyone hates. A channel transition where information gets lost. Solve it with SD methods, measure the result, communicate it broadly. The first proof matters more than any strategy presentation.

2. Speak Management’s Language

“Empathy,” “user-centricity,” and “co-creation” are SD jargon that does not resonate in the boardroom. Translate: “We can reduce onboarding time by 40%” (measurable), “We reduce support tickets by a third” (cost-effective), “Our churn rate drops from 18% to 12%” (revenue-relevant). McKinsey found that companies with top-level design metrics — meaning design KPIs discussed in the boardroom — achieve significantly better financial results [1].

3. Use Journey Mapping as a Trojan Horse

A customer journey map is the most accessible SD tool: visual, immediately understandable, and it makes silos visible without naming them. Invite stakeholders to contribute their perspective on the journey. Once someone has seen how their department looks from the customer’s perspective, they ask for more on their own.

4. Build Internal Champions

A single SD evangelist is not enough. You need allies in every business unit — people who understand SD not as a method but as a mindset and advocate for it in their area. Identify colleagues who already think in customer-centric terms and give them tools and success stories.

5. Combine Top-Down and Bottom-Up

Bottom-up alone generates grassroots enthusiasm but no resources. Top-down alone generates a mandate that nobody lives. You need both: an executive sponsor who provides budget, access, and visibility — and a network of practitioners who change daily work. Stickdorn et al. (2018) emphasize: “Service Design needs organizational backing that goes beyond a single project” [4].

Measuring ROI: What at Which Stage?

One of the most common mistakes when embedding SD: trying to calculate the “ROI of service design” too early. At Stage 1 there is no baseline, at Stage 2 the sample sizes are too small. ROI measurement must grow with maturity.

Stage 1-2: Project Level

In the early stages, track what is directly measurable:

• Customer satisfaction before/after (NPS, CSAT for the specific service)
• Process efficiency (processing time, number of handoffs, error rate)
• Time-to-market (duration from idea to live service)
• Support tickets (reduction after service redesign)

Do not try to calculate a financial ROI — you have neither the baseline nor the attribution. Instead, document before-and-after comparisons per project. An example: an insurance company measures that average claims processing time is 14 days and the NPS for the claims process is -5 before the SD pilot. After redesigning the process with service blueprint and journey mapping, processing time drops to 8 days and NPS rises to +22. That is not ROI — but it is evidence that funds the next project.

Stage 3: Portfolio Level

From Stage 3, you have enough data points to aggregate beyond individual projects:

• Percentage of services that went through an SD process (adoption rate)
• Aggregated NPS increase across all SD projects
• Cost avoidance through early error detection (problems discovered during prototyping rather than after launch)
• Employee satisfaction in SD-supported teams vs. comparison group

This is where the RODI approach (Return on Design Investment) first becomes applicable: (Benefit - Cost) / Cost. Benefits include both direct savings (process reduction, error reduction) and opportunity gains (faster time-to-market, higher customer retention).

Stage 4-5: Business Level

At mature stages, SD impact becomes visible at the business level:

• Revenue growth from SD-designed services (attribution via A/B tests or cohort comparison)
• Customer lifetime value (CLV change in SD-treated segments)
• Employee experience (turnover in SD-embedded teams vs. comparison group)
• Innovation velocity (time-to-market as an organizational metric, not a project metric)

McKinsey’s MDI methodology shows: at this stage, design maturity correlates with financial results at the company level — no longer at the project level [1]. The InVision report confirms: organizations at the highest design maturity stage achieve measurably higher revenue growth rates than their competitors [5].

Practical tip: Build the measurement system before you need it. If you are not collecting baseline data at Stage 2, you will have nothing to compare against at Stage 3. Every SD project should document at least one before-measurement.

6 Common Embedding Mistakes

1. The Department Trap

Service design becomes its own department with its own P&L — and thus becomes a silo. The irony: SD is supposed to break down silos but becomes one itself. The consequence: business units delegate “the customer thing” to the SD department instead of internalizing it themselves. Countermeasure: Position SD as a cross-cutting capability, not an organizational unit. The CoE supports; it does not replace.

2. Measuring Adoption Instead of Impact

“14 teams did journey mapping this year” sounds like progress — but says nothing about impact. If all teams use the method but not a single service has measurably improved, adoption without impact has occurred. Countermeasure: Always track outcome metrics alongside adoption metrics. Not “How many teams use SD?” but “What has SD achieved?“

3. Starting Without Executive Sponsorship

Grassroots enthusiasm is important but insufficient on its own. Without a sponsor at C-level or divisional leadership, there is no budget, no access to strategic projects, and no legitimacy to cross departmental boundaries. The SDN research confirms: organizational barriers — lack of resources, lack of decision-making authority — are the most common reasons why SD initiatives stagnate [2]. Countermeasure: Secure an executive sponsor before you scale. At Stage 1-2, a department head suffices; from Stage 3, you need C-level backing.

4. Copying Instead of Adapting

Transferring the SD model of a tech corporation one-to-one to a mid-sized manufacturer does not work. The organizational culture, decision-making paths, and available resources are fundamentally different. An insurer with 5,000 employees and regulatory requirements needs a different embedding model than a 200-person SaaS company. Countermeasure: Adopt the principles, adapt the structure. Proceed stage by stage, do not implement everything at once.

5. Methods Training Without Project Attachment

Teams are trained in journey mapping, blueprinting, and prototyping — but there is no concrete project in which to apply what they have learned. After six months, the knowledge has faded. Stickdorn et al. (2018) document this pattern explicitly: methods training without direct application leads to “SD tourism” — teams can talk about methods but cannot work with them [4]. Countermeasure: Link every training to a real project. Participants work on an actual service problem from their business unit during the training.

6. Building External Dependency

External consultants run the SD projects, deliver results, and leave. The company has a result but no capability. The next project is again outsourced. Countermeasure: Use external support for enablement, not replacement. The Integrated Service Development Process (iSEP) follows exactly this approach: external experts accompany the first iterations and simultaneously build internal know-how, so that the organization can increasingly run the process on its own.

Related Concepts

Organizational embedding of service design does not happen in isolation but connects to several core concepts:

• Service Design: The foundational article — definition, process, principles, and the question of when SD makes sense. This article builds on it.
• Service Blueprint: The central tool for backstage analysis. At Stage 3-4 of the maturity model, blueprinting becomes a standard process step.
• Customer Journey Mapping: The most accessible SD tool — and the best “Trojan horse” for internal advocacy (see “Selling SD Internally” section above).

In our Integrated Service Development Process (iSEP), these methods are embedded in a coherent framework that considers organizational embedding from the start: not only the service outcome is designed, but also the path by which the organization builds the capability permanently.

Frequently Asked Questions

Do you need a dedicated service design team?

Not necessarily — but you need clear accountability. At Stage 1-2, engaged individuals who drive SD alongside their primary role are sufficient. From Stage 3 onward, dedicated resources are needed, whether as a central team, an embedded role, or a hybrid. What matters is not the organizational form but that someone is responsible for standards, knowledge transfer, and quality assurance.

How long does it take to embed service design in an organization?

Moving from Stage 1 to Stage 3 typically takes 18-36 months — provided there is management support and real projects. Moving from Stage 3 to Stage 5 can take 3-5 years, because this involves cultural change, not method adoption. Faster is not always better: a company that skips stages has not laid the foundations and will regress.

What does introducing service design cost?

The biggest costs are not external consulting or software but internal working time: interviews, workshops, prototyping, stakeholder alignment. For an initial pilot project (Stage 1-2), plan for 3-5 people over 6-8 weeks at roughly 30-50% capacity. From Stage 3, costs for dedicated roles, training programs, and tools are added. Stickdorn et al. (2018) recommend: “Start with a pilot project, not a company-wide transformation” [4].

Who is responsible for service design?

At Stage 1-2, often an engaged individual in product, innovation, or marketing. From Stage 3, typically a dedicated team or role reporting to a Chief Customer Officer, Chief Experience Officer, or COO. At Stage 5, the question is obsolete — because SD is embedded in every function. The key at every stage: the person responsible needs access to cross-functional projects, not just their own department.

Bibliography

[1] Sheppard, Benedict, Hugo Sarrazin, Garen Kouyoumjian, and Tracy Doshi. “The Business Value of Design.” McKinsey Quarterly, October 2018. URL: https://www.mckinsey.com/business-functions/mckinsey-design/our-insights/the-business-value-of-design

[2] Service Design Network. “Taming Organisational Challenges in Service Design.” SDN Community Knowledge. URL: https://www.service-design-network.org

[3] Koos Service Design. “Service Design Maturity Model: An Introduction.” Koos Blog. URL: https://www.koos.io/service-design-maturity-model

[4] Stickdorn, Marc, Markus Edgar Hormess, Adam Lawrence, and Jakob Schneider. This Is Service Design Doing: Applying Service Design Thinking in the Real World. O’Reilly Media, 2018. ISBN: 9781491927186.

[5] InVision. The New Design Frontier: The widest survey of designers to date. InVision Design Maturity Report, 2019. URL: https://www.invisionapp.com/design-better/design-maturity-model/

[6] Mager, Birgit. The Future of Service Design. TH-Koeln, 2020. ISBN: 978-3-9818990-6-1.

[7] Hegeman, Jamin. “Service Design Leadership at Capital One.” Documented in: SDN Executive Leadership, Carnegie Mellon University, SMU. URL: https://jamin.org/experience/