Headless CMS
a centralized enterprise platform

Headless CMS
a centralized enterprise platform

Transforming fragmented digital experiences into one scalable platform with global governance and controlled local customization.

Project Overview

Europ Assistance managed dozens of independently maintained B2B and B2C digital products across 37 markets, creating inconsistent experiences, duplicated effort, and slow delivery.

My Role

Collaboration

Product DiscoveryStakeholder InterviewsWorkflow MappingInformation ArchitectureModular Page TemplatesCMS GovernanceUX DesignBacklog PrioritizationDomain Strategy
I led product discovery and experience design for a global Headless CMS transformation, aligning business, engineering, and local markets to build a centralized, scalable enterprise platform.
Product ManagerEngineeringQA
CybersecurityITCommunications
CCOMarketing teamLocal Markets

Enterprise transformation

  • Company: Europ Assistance
  • Duration: 7 months
  • Scope: 37 markets

Maryna Lievshyna

  • Growth Product Designer
  • Discovery → Delivery
  • Product · UX · Strategy

Workflow

  1. Shared Content & Templates
  2. Centralized Enterprise Platform
  3. Local Market Adaptation
  4. B2B / B2C Experiences
  5. Ongoing Governance & Updates

The Problem

Across 37 markets, digital maturity, technical capabilities, local regulations, and ways of working varied dramatically, making global consistency and future rebranding difficult to scale.

Uneven digital maturity

Some markets had strong digital products; others had outdated or no platforms.

High operating costs

Standalone websites, CMS licenses, agencies, and technical support increased costs across markets.

Fragmented experiences

UX, UI, content, CMS, publishing, SEO, and domains were managed separately and inconsistently across markets.

Rebrand at scale

37 markets needed to adopt one global brand while keeping local flexibility.

Customer Discovery

I investigated how markets managed their websites and content, mapping workflows, technical capabilities, dependencies, and governance to understand what each market could realistically operate and maintain.

Capability?

Editors

Technical capability varied dramatically between markets, with some teams unable to maintain a standalone CMS without external support.

Maturity?

Local Markets

Digital maturity ranged from advanced local websites with dedicated technical support to markets with outdated or no digital platforms at all.

Scale?

Business

Markets wanted consistent corporate and B2B experiences, while the upcoming rebrand created a need to coordinate change across 37 countries.

Compatibility?

Platform

Different CMSs, information architectures, SEO capabilities, security requirements, and support models made a one-size-fits-all migration unrealistic.

Discovery Process

  1. Stakeholder Interviews
  2. Workflow Mapping
  3. CMS Audit
  4. Requirements Mapping
  5. Cross-Market Comparison
  6. Governance Review

Solution

A centralized Headless CMS created one scalable foundation for 37 markets, while allowing local teams to manage content and adapt experiences to their needs.

Centralized Headless CMS

  • Shared platform on Strapi + Azure
  • Modular content architecture
  • Reusable page templates
  • Domain governance
  • Phased market rollout + onboarding

One

PLATFORM

for global governance and local adaptability

Design Principles

To support markets with very different needs and capabilities, I defined five principles to guide platform, content, and governance decisions.

Global governance

One source of truth across all markets.

Local flexibility

Markets adapt content without breaking consistency.

Reusable by design

Components work across products and markets.

Editor-first experience

Non-technical teams can manage content independently.

Future-ready platform

Built for integrations, automation, and future expansion.

Implementation Phases

These principles translated into the platform’s architecture, content model, and governance, creating a system that could scale globally while remaining simple for local teams to use.

Strategic Product Decisions

Key product decisions balanced local market needs, platform scalability, and long-term governance across 37 markets.

Trade-off
Global governance ↔ Local flexibility
Fast delivery ↔ Long-term scalability
Flexible editing ↔ Structured content
Immediate needs ↔ Future expansion
Decision
Controlled customization
Consistency without removing local autonomy
Reusable architecture
Reduce repeated market-specific work
Standardized content models
Keep content reusable and governable
Design for scale
Support new markets and integrations

One shared backend, flexible multiple market experiences.

  • Centralized managed through one shared backend
  • API-driven delivery separated content from presentation
  • Flexible frontends allowed markets and products to adapt the experience

Deep Dive

From a single domain request to a global strategy

A routine request to acquire one country domain exposed a much larger risk around rebranding, expansion, cybersecurity, and future operating costs.

The trigger

Can we buy europassistance.nl domain?

The domain was already owned by a third party.

The answer:

No, the domain isn’t available.

The question I asked instead:

What happens when the entire company rebrands?

Discovering the hidden risk

1 unavailable domain
Company name change
37 markets
× country domains
× brand variations
× B2B / B2C needs
× future expansion
× cybersecurity exposure
Potential six-figure risk

Investigation

Agency research

Understand domain registration, recovery, and pricing

Country managers

Validate SEO and local-market implications

Cybersecurity

Validate ownership, phishing and brand risks

Communications

Connect the issue to rebranding and expansion

The strategic decision

Buy early. Govern centrally. Design for expansion.

Instead of recovering domains after the rebrand, I proposed securing likely domain combinations in advance and defining a scalable governance model for future markets and digital products.

Protect

Secure critical names and variations early

Separated B2B

Separated B2B domain structure

From B2C subdirectory structure

B2C subdirectory structure

Structure

Define naming across countries, products and use cases

Centralized naming structure

Scale

Account for future markets and expansion from the start

Future market expansion structure

~€10/year
proactive registration
vs
up to €10K/case
domain recovery

From initiative to approval

I initiated the investigation, developed the strategy, gathered cross-functional evidence, and brought the proposal through stakeholder alignment to board approval.

Risk identified
Evidence gathered
Strategy developed
Stakeholders aligned
Board approved

One unavailable domain exposed a much bigger risk. I recognized it early enough to address the problem before it became far more expensive with the global rebrand.

Cross-functional Leadership

Aligning product, technical, governance, and market teams around one scalable platform required continuous coordination from definition through rollout.

Product direction
Requirements, priorities, backlog
Engineering + QA
Feasibility, implementation, testing
IT + Cybersecurity
Architecture, security, approvals
Communications + CCO
Brand requirements, global alignment
Local markets
Local needs, onboarding, rollout

Leadership takeaway

Connected business and technical needs
Turned fragmented requirements into product direction
Built alignment across global and local teams
Supported decisions from discovery through rollout

Outcomes

The platform created measurable business value while establishing a shared foundation for faster, more consistent content operations across markets.

80%
lower rebranding costs
60%
lower operational effort
70%
faster content updates
250%
projected ROI

Faster publishing

Less dependency on technical teams

Shared governance

More consistent experiences across markets

Scalable foundation

Reusable across products and future markets

Reflection

Working across 37 markets reinforced the importance of looking beyond what is immediately visible. Different levels of digital maturity, fragmented ownership, and small operational frictions often pointed to larger structural problems.

Look beyond a simple request

A small issue can be a symptom of a much larger product, operational, or business risk.

Investigate before solving

Understanding why friction exists can reveal opportunities that would be missed by simply fixing the immediate problem.

Design for what happens next

Decisions made for today should account for how the system will behave as markets, teams, and requirements evolve.

Interested in Product Design for Complex Systems, Enterprise Platforms, or Global Transformation?