CX Blueprint — Foleon / AEM Content Process
Designing a 10-phase service blueprint that standardizes how Marsh delivers digital content across three technical scenarios — standalone Foleon, AEM-integrated, and AEM-embedded. Co-designed with Claude as AI collaborator to structure governance, QA protocols, and cross-team workflows.
Context & Challenge
No Shared Process for Enterprise Content Delivery
Marsh's digital content team used Foleon and AEM to produce and publish content — but depending on the project, the technical architecture was completely different. Standalone Foleon assets, Foleon pages linked within AEM journeys, and Foleon content embedded as iframes in AEM all required different setups, different QA, different SEO approaches, and different rollback plans. Without a shared process, every project started from scratch.
Teams operated in silos. CX, SEO, Analytics, Platform, and QA each had their own timelines with no formal handoff points. Late stakeholder feedback regularly derailed launches. There was no severity classification for QA findings — a typo and a broken embed were treated the same way.
Standalone Foleon, AEM-linked, and AEM-embedded content required entirely different technical setups — but were treated as the same type of project.
Stakeholders could request structural changes mid-production. Without formal approval checkpoints, late feedback continuously derailed timelines and forced costly rework.
CX, SEO, Analytics, Platform, and QA each worked sequentially rather than in parallel. No shared language, no unified timeline, no handoff standards.
Without a severity model, every QA finding was treated as a blocker. This created ambiguity about what could delay a launch and what could be addressed post-live.
adjustMy Brief
Design a service blueprint that governs all three content delivery scenarios — creating a shared process language between CX, SEO, Analytics, Platform, QA, Designer, and stakeholders. The blueprint needed to define ownership, parallel workstreams, governance gates, and escalation paths from scenario selection through post-launch retrospective.
Key Decisions
Strategic Choices That Shaped the Blueprint
| Decision | What I Chose | Why | Tradeoff |
|---|---|---|---|
| Blueprint format | NN/g service blueprint (phases × layers) | Different roles see the same process from their own layer — CX sees the journey, platform sees the tech, QA sees their stage. One document, multiple audiences. | More complex to author, but far more durable than a simple checklist |
| Scenario architecture | 3 distinct scenarios (A, B, C) with shared core phases | A single "content delivery process" doesn't exist — the technical reality differs too much. Naming scenarios creates shared vocabulary without over-engineering. | More documentation per scenario, but eliminates ambiguity on every project |
| Team workstreams | Parallel tracks in Phase 3 (SEO + Analytics + Platform) | Sequential handoffs added 1–2 weeks to every project. Running SEO, Analytics, and Platform planning simultaneously cuts calendar time without cutting depth. | Requires stronger coordination, but CX brief in Phase 2 serves as the synchronization point |
| Governance model | 3 formal gates: Gate 1, Gate 2, Go/No-Go | Gates create shared commitment moments. Once a stakeholder approves Gate 1, structural changes require a formal change request — protecting the team from scope creep. | Stakeholders must engage earlier, but late-stage surprises drop dramatically |
| QA severity model | P1 Blocker / P2 Must Fix / P3 Improvement | Without severity classification, any finding could theoretically block a launch. The model gives QA a shared language with IT/PM and stakeholders about what actually gates publication. | Requires upfront alignment on definitions, but removes ambiguity in every QA conversation |
| AI collaboration | Claude as co-designer for blueprint structuring | Designing a process this complex involves generating, iterating, and reorganizing large amounts of structured content. Claude served as a thinking partner — drafting layer content, stress-testing scenarios, and formatting documentation. | AI drafts need human review for accuracy, but the collaboration compressed weeks of process writing into days |
The Blueprint
10 Phases × 6 Service Layers
The blueprint uses the NN/g service blueprint model: read each column as a phase in the timeline, read each row as a layer of the service. Every cell is owned by a specific team and produces a specific deliverable or action.
Read each column as a phase · Read each row as a service layer · Gates mark formal approval moments
Service Layers
folder_open Evidence / Deliverables
What gets produced at each phase
From scenario decision doc and Wrike project brief through QA report, SEO validation, consolidated feedback, published URL, and final version log.
person Stakeholder Journey
What stakeholders experience
Scoping call → request submission → Gate 1 approval → progress updates → preview review → Gate 2 sign-off → 48hr final review window → written Wrike approval → performance report + retrospective.
support_agent Frontstage (Employee Actions)
What the team does that stakeholders see
IT/PM facilitates scoping; CX presents recommendations; Designer shares preview; QA communicates findings; SEO/Analytics report validation results; IT/PM confirms go-live; Analytics shares performance dashboard.
computer Technology Stack
Tools per phase
Wrike (project mgmt + automation) · Figma (journey mapping, A11y scanning) · Foleon (builder, publishing, SEO) · Adobe Analytics + Looker · AEM (scenarios B & C) · BrowserStack (device testing) · Claude (AI assist) · Osano (cookie consent) · info.marsh.com (publishing).
settings Backstage (Internal Actions)
What happens behind the scenes
Scenario evaluation → Wrike project setup → CX brief distribution → parallel SEO/Analytics/Platform planning → WCAG AA design + Osano/LCPA config → P1/P2/P3 QA → metadata validation → feedback implementation → pre-publication checklist → 72-hour monitoring.
library_books Support Processes
Standards that enable consistency
Scenario decision framework · Wrike automation templates · Design system + WCAG reference · SEO guidelines + analytics playbook · Foleon templates + naming conventions · QA checklist + device matrix · Feedback protocol + change request form · Retrospective template + version log.
Phase Timeline
Scenario Determination
IT/PM + CX evaluate the request using the decision framework. 30-min scoping call if unclear. Output: Scenario A, B, or C confirmed.
1 day
Intake & Project Setup
IT/PM creates Wrike project with 10 core tickets + scenario-specific additions. Brief submitted with objectives, audience, source materials, launch date, and distribution strategy.
1–2 days
CX Strategy Review
CX evaluates IA, content hierarchy, user journey, and mobile-first approach. CX brief distributed to SEO, Analytics, and Designer. → Gate 1
2–3 days
Parallel Planning
Three tracks run simultaneously: SEO (titles, metadata, canonical strategy) · Analytics (event tracking, dashboard setup) · Platform (hosting, AEM config, CSP/security).
2–3 days (parallel)
Design, Preview & Full Build
Designer creates WCAG AA-compliant Foleon asset, Osano/LCPA config, naming conventions. Preview review. → Gate 2. Full build incorporating SEO tags, analytics, and all metadata.
5–10 days
QA — Internal Review
Full checklist: accessibility, branding, device matrix (1920/1440/768/375px), content accuracy, links, performance. P1 blockers loop back to designer. Parallel: SEO + Analytics validation.
2–4 days
SEO & Analytics Validation
Parallel validation of metadata, alt text, indexing settings (SEO) and event triggers, scroll tracking, data flow (Analytics). Scenario C embed tracking is a critical test point.
1–2 days (parallel)
Stakeholder Review
48-hr review window. One designated feedback contact. Max 2 rounds. Feedback categorized as content correction, design adjustment, or new requirement (triggers change request).
2–5 days
Approval & Go-Live
Final QA confirms no P1 items. Written Wrike approval captured. Pre-publication checklist completed per scenario. → Go/No-Go. Publication with scenario-specific rollback plan on standby.
1–2 days
Monitoring & Retrospective
72-hour monitoring of traffic, events, performance, SEO indexing, and embed stability (Scenario C). 30-min retrospective within one week. Version log maintained for recurring assets.
72hrs + retro
The 3 Scenarios
One Blueprint, Three Delivery Architectures
The core 10-phase process applies to all projects. Scenarios define which technical path each project follows — determining hosting, SEO ownership, embed strategy, AEM involvement, and rollback complexity.
Foleon asset published directly on info.marsh.com. Full creative control. URL-based SEO owned entirely by Foleon.
- Hosting: info.marsh.com
- SEO: Foleon URL owns all signals
- Rollback: Unpublish immediately (simple)
- Osano + LCPA: Required on Foleon side
Complexity: Low
Foleon content linked from AEM pages — both platforms form a connected user journey. Each platform owns its SEO. Design continuity across both is critical.
- Journey: AEM → Foleon → AEM flow
- SEO: Both URLs validated; canonical defined
- Rollback: Take down both (sequence defined)
- QA: Cross-platform re-test if either changes
Complexity: Medium
Foleon content embedded as an iframe within AEM pages. Most technically complex — CSP headers, cookie consent, embed scroll behavior, and analytics firing all require specific validation.
- SEO: AEM page only (iframe not indexed)
- Critical test: Embed tracking in AEM staging
- Rollback: Replace embed with static placeholder
- No scroll-within-scroll designs allowed
Complexity: High
Governance Gates
lockThree Approval Moments That Protect the Team
⛔ Gate 1 — After Phase 2
Content Structure & Journey Approval
Stakeholder confirms: content structure, user journey direction, scenario approach. No design work begins without this approval. Post-gate changes require a formal change request.
⛔ Gate 2 — After Phase 4 Preview
Content Substance Approval
Stakeholder confirms: content completeness and accuracy, structure correctness, navigation functionality, visual direction. Post-gate changes require change request with timeline impact assessment.
⛔ Go/No-Go — After Phase 8
Pre-Publication Checklist Complete
All scenarios: Wrike closed, metadata verified, analytics live. Scenario-specific: hosting confirmed (A), both platforms ready (B), AEM staging validated + CSP confirmed (C).
Blueprint Documents
Results & Impact
From Ad-hoc to Governed Delivery
Delivery Process
Structured
end-to-end blueprint
Scenarios
Classified
A · B · C with own protocols
QA Severity
Model
shared severity language
Approval Gates
Governed
G1 · G2 · Go/No-Go
Key Deliverables
Reflections