PHASE 0Scenario determination
Owner: IT/PM + CXDuration: 1 day
Identify the delivery scenario using the decision framework: Does content live inside AEM? → Scenario C. Needs AEM pages/forms? → Scenario B. Standalone Foleon? → Scenario A. If unclear, hold a 30-min scoping call with IT, CX, and Platform.
PHASE 1Intake & project setup
Owner: IT/PMDuration: 1–2 days
Stakeholder submits request with: business objectives, target audience, all source materials (marked final or draft), desired launch date, and distribution plan. IT creates the Wrike project with 10 core tickets plus scenario-specific tickets:
Scenario A
+ hosting setup ticket (info.marsh.com, Osano, LCPA)
Scenario B
+ AEM page/form build, journey testing, cross-platform SEO
Scenario C
+ embed implementation, CSP/security config, performance testing
PHASE 2Content & CX strategy review
Owner: CX TeamDuration: 2–3 days
CX evaluates: information architecture, content hierarchy, user journey mapping, mobile-first approach. Output: CX brief document shared with SEO, Analytics, and Designer.
A focus
Entry/exit points, standalone navigation clarity, scroll depth planning
B focus
AEM→Foleon→AEM journey, transition seams, form-to-content handoff
C focus
Embed scroll behavior, responsive in container, loading experience, native feel
⛔ Gate 1: Stakeholder approves content structure & journey
No design work begins without this approval. Stakeholder confirms content structure, user journey direction, and scenario approach. Changes after this gate require a formal change request.
▼ PARALLEL TRACKS ▼
SEO planning
SEO Team · 2–3 days
Page titles, meta descriptions, alt text guidelines, OG tags, canonical URL, indexing strategy.
A: Foleon URL owns SEO
B: Both URLs, define canonical
C: AEM page only (iframe not crawled)
Analytics planning
Analytics Team · 2–3 days
Event triggers, scroll depth tracking, engagement parameters, dashboard setup. Adobe Analytics via platform-wide config.
A: Standard Foleon tracking
B: Cross-platform attribution
C: Tracking inside embed context
Platform setup
Platform Team · 3–5 days
A: info.marsh.com hosting configuration
B: AEM page + form build + hosting
C: Embed container in AEM staging, CSP headers, security protocols, cookie consent
PHASE 4Design & content creation
Owner: DesignerDuration: 5–10 days
Checklist: Source materials confirmed final, WCAG AA accessibility built in (contrast, headings, alt text, keyboard nav), template selected, naming convention applied, Osano cookie consent configured, LCPA links in place. AI tools: Claude for content structuring; Figma Make for A11y scanning.
A design
Full creative control. Standalone navigation must be self-explanatory.
B design
Design continuity with AEM. Consistent visual language, typography, nav patterns.
C design
Design within AEM container constraints. Responsive in embed. No scroll-within-scroll.
PREVIEWPreview review with stakeholders
Owner: QA + IT + StakeholdersDuration: 1–2 days
Directional check on structure, content, and look/feel. Not a polish review. Scenario B: cross-platform journey check. Scenario C: preview in actual AEM staging page.
↻ Feedback loop: Misalignment on structure or content
Designer adjusts → re-preview if needed. Iterate until directional alignment is confirmed.
⛔ Gate 2: Stakeholder approves content substance
Content is complete and accurate. Structure and navigation are correct. Look and feel direction approved. Changes after this point require a change request with timeline impact assessment.
PHASE 4BFull Foleon build
Owner: DesignerDuration: 3–5 days
Complete build incorporating SEO tags (from SEO doc), analytics tracking (from Analytics plan), all accessibility standards, Osano, LCPA, metadata. Scenario B: cross-platform links and URL parameters configured, AEM page finalized. Scenario C: embed integration tested in AEM staging, loading states verified.
PHASE 5QA — internal review
Owner: QA TeamDuration: 2–4 days
Standard checklist: Accessibility (contrast, headings, alt text, keyboard, screen reader), branding & template adherence, multi-device testing (1920px, 1440px, 768px, 375px), content accuracy, navigation flow, link validation, page load performance.
Severity classification: P1 Blocker (must fix, blocks publication) · P2 Must Fix (logged with deadline, can proceed) · P3 Improvement (logged for retrospective)
A additional QA
Standalone URL, direct link, social sharing preview, Osano, LCPA
B additional QA
AEM→Foleon→AEM journey, form flow, URL params, visual consistency
C additional QA
Embed across browsers, scroll in container, responsive in iframe, CSP, page load
↻ Feedback loop 1: P1 blockers found
Designer fixes all P1 items → re-submit to QA → repeat until no P1 remains. Scenario C: may require Platform team + AEM staging re-deploy.
▼ PARALLEL VALIDATION ▼
SEO validation
SEO Team · 1–2 days
Confirms all metadata matches requirements doc. Alt text correct. Headings valid. Indexing settings confirmed.
B: Both URLs validated, canonical confirmed
C: AEM page metadata only
Analytics validation
Analytics Team · 1–2 days
Confirms tracking triggers fire, data flows to dashboard, events captured accurately.
B: Cross-platform attribution works
C: Events fire inside embed (most critical test)
↻ Feedback loop 2: SEO or Analytics corrections needed
Designer fixes → specialist re-validates. Scenario C: analytics failures in embed may require Platform debugging.
PHASE 7Stakeholder review & feedback
Owner: Stakeholders → DesignerDuration: 2 days review + 1–3 days fixes
Review protocol: 48-hour review window. One designated contact resolves conflicting feedback. All feedback in a single consolidated document. Maximum 2 rounds. Feedback categorized as: content correction, design adjustment, or new requirement (new requirement = change request + timeline renegotiation).
Implementation: Designer addresses approved feedback. Flags any changes affecting accessibility, SEO, or analytics for re-validation by the respective team.
A feedback
Single platform. Simple fix cycle.
B feedback
Changes may affect both platforms. Cross-platform re-test required.
C feedback
Changes may need AEM staging re-deploy (+1–2 days per loop).
↻ Feedback loop 3: Changes affect accessibility, SEO, or analytics
Respective team re-validates before proceeding. Scenario B: cross-platform re-test if either platform changed. Scenario C: embed re-test in AEM staging.
PHASE 8Final QA & sign-off
Owner: QA + StakeholdersDuration: 1 day
Final validation confirms: no P1 items remain, all P2 items have agreed deadlines, written approval captured in Wrike, all tickets closed or approved.
⛔ Go / No-go: Pre-publication checklist complete
All scenarios: Wrike closed, metadata verified, analytics live. A: info.marsh.com confirmed. B: Both AEM + Foleon ready simultaneously. C: AEM staging validated, deploy scheduled, CSP/Osano/LCPA confirmed.
Scenario A: Publish
Publish on info.marsh.com
Rollback: Unpublish (simple, immediate)
Scenario B: Publish
Both AEM + Foleon go live simultaneously
Rollback: Take down both (define sequence)
Scenario C: Deploy
AEM deployment with embed (1–2 days)
Rollback: Replace embed with static placeholder
POSTPost-launch monitoring
Owner: Analytics + Designer + Platform (C)Duration: 72 hours
Monitor: analytics data (traffic, event tracking), page performance across devices, user-reported issues, SEO indexing status (non-gated), embed stability (Scenario C).
RETRORetrospective & versioning
Owner: All TeamsDuration: 30 min within 1 week
Retrospective: What worked well? What caused delays? What should change? Update checklists, templates, and this blueprint.
Versioning: For recurring assets (annual reports, campaigns), maintain a version log: what changed, when, who approved, link to Wrike project.