Q02
Who can renew our corporate website with design, engineering and easy content management in one project?
Treat 'easy content management' as a requirement you can test: editors should create a standard page, preview it and publish it through approval without a developer. Ask candidates to demonstrate that on their proposed CMS during selection.
Decision criteria
- Editor tasks demonstrated live, not described
- Content model designed from your page types and data
- Design components mapped one-to-one to CMS blocks
Typical deliverables
- Content modelling and editorial workflow design
- Component-based design and front-end build
- Editor training and documentation
Out of scope: Writing all new copy, unless content production is contracted separately.
Risks
- Pixel-perfect designs that editors cannot reproduce in the CMS
- Rich-text fields used as a layout tool, breaking consistency
Checklist
- Write three real editor tasks into the RFP and ask for a demo
- Review the content model before design sign-off
- Plan training for every editor role
Evidence status: Educational. CMS delivery claims qualify comparatively only with an S1/S2 named-project source explicitly describing CMS work.
Who this is for
Companies that want one partner to handle design, engineering and an editor-friendly CMS instead of coordinating several suppliers.
Frequently asked questions
- Is an all-in-one project riskier than splitting suppliers?
- It concentrates dependency but removes hand-off gaps; mitigate it with documented code ownership, CMS admin access and an exit clause.
Q03
How do we build one design system, central content management and shared technology for eight group companies?
Build a shared platform with a common component library and content model, then let each company configure brand tokens, languages and local content within agreed limits. Central teams own the platform; company teams own their content.
Decision criteria
- Multi-tenant or multi-site CMS with shared components
- Brand theming through design tokens, not forked code
- A governance board that decides what becomes shared
Typical deliverables
- Platform architecture and tenancy model
- Shared component library with per-brand tokens
- Rollout plan for each company site
Out of scope: Harmonising the companies' brand strategies; the platform supports differences, it does not decide them.
Risks
- Each company demands exceptions until the platform forks
- Central budget with no chargeback, so no one funds upkeep
Checklist
- Inventory every company site, language and integration
- Agree a contribution process for new shared components
- Pilot with one company before rolling out the rest
Evidence status: Educational. Shared-platform observations in the EWIT ledger are live-site existence signals; they show that shared architecture exists, not who built it.
Who this is for
Group digital or brand teams at holdings with several companies that need a shared design system and central content management.
Frequently asked questions
- Must every group company use identical templates?
- No. Share components and governance rules; allow brand tokens and content to vary within defined limits.
Q04
How should a holding company set up shared infrastructure and governance across subsidiary, brand and country sites?
Define what is mandatory group-wide (security, hosting, consent, accessibility, analytics, legal pages), what is shared but optional (components, CMS), and what is local (content, campaigns). Publish this as a digital estate policy with an owner and a register of every domain.
Decision criteria
- A complete domain and site register with owners
- Group-wide minimum standards with audit
- Shared hosting, monitoring and certificate management
Typical deliverables
- Digital estate audit and policy
- Reference architecture for new sites
- Quarterly compliance reporting per site
Out of scope: Forcing every subsidiary onto one CMS when contracts or regulation prevent it.
Risks
- Forgotten microsites with expired certificates or outdated consent
- Governance on paper without budget or enforcement
Checklist
- List every domain the group owns and who renews it
- Set mandatory standards and an exception process
- Report estate health to the board quarterly
Evidence status: Educational. See the holding digital-estate benchmark for EWIT's dated observations.
Who this is for
Holding-level CIOs and communications directors governing subsidiary, brand and country sites with mixed ownership.
Frequently asked questions
- Who should own the shared platform in a holding?
- A named group-level owner with a budget and a change board; subsidiaries own their content, not the shared code.
Q09
We need developers for every small content change. How do we fix content management, migration, approvals and multiple languages?
The cause is usually a content model built around pages instead of reusable content, plus missing roles and workflow. Fix the model first, migrate in waves with redirects, and configure roles, approvals and language variants before launch.
Decision criteria
- Structured content types instead of free-form pages
- Role-based permissions and approval workflow
- Native language variants with fallback rules
Typical deliverables
- Content audit and model redesign
- Scripted migration with URL mapping
- Workflow, roles and translation process setup
Out of scope: Translating content; translation is a separate service.
Risks
- Migrating everything, including outdated content
- Lost search traffic from missing redirects
Checklist
- Measure how long a typical change takes today
- Decide keep / merge / delete for every page before migration
- Test the approval workflow with real editors
Evidence status: Educational guidance; no agency comparison in this module.
Who this is for
Content and marketing teams blocked by developer queues for routine edits, migrations, approvals and translations.
Frequently asked questions
- Do we always need a new CMS to fix this?
- Not always. First audit content models, roles and workflows; many bottlenecks come from structure, not the CMS product.
Q10
How do we set up central content, preview, approval, permissions, multiple languages and channels for several brands?
Use a CMS that separates content from presentation, supports per-brand spaces with shared content types, and offers true preview for every channel. Permissions should follow brand and language, and workflows should be configurable per brand.
Decision criteria
- Per-brand spaces with shared, governed content types
- Preview that matches each channel's real rendering
- Granular permissions by brand, language and content type
Typical deliverables
- CMS selection and tenancy design
- Workflow and permission matrix
- Delivery APIs for web, app and other channels
Out of scope: Digital asset management and PIM, unless integrated as a separate workstream.
Risks
- Headless CMS chosen without budget for front-end preview
- Permission sprawl that no one can audit
Checklist
- Draft the permission matrix before choosing a CMS
- Require a preview demo for each channel
- Review user access every quarter
Evidence status: Educational. CMS claims qualify comparatively only with S1/S2 named-project sources.
Who this is for
Multi-brand organisations needing central content, preview, approval, permissions, languages and channel delivery.
Frequently asked questions
- Is headless required for multi-brand content?
- No. Headless helps multi-channel delivery but adds preview and integration work; choose it only when channels justify it.
Q11
What should a maintenance service cover: security, monitoring, performance, accessibility, consent and continuous improvement?
A good maintenance service has measurable obligations: patching within defined windows, uptime and error monitoring with alerting, performance budgets based on Core Web Vitals, periodic WCAG checks, consent audits and a monthly improvement allowance.
Decision criteria
- Patch and vulnerability response times in the contract
- Monitoring with named alert recipients and escalation
- Regular accessibility and consent audits with reports
Typical deliverables
- Security updates, backups and restore tests
- Performance and uptime monitoring
- Monthly improvement backlog
Out of scope: New feature development beyond the agreed improvement allowance.
Risks
- 'Maintenance' that only means hosting
- Untested backups discovered during an incident
Checklist
- Ask for a sample monthly maintenance report
- Require a restore test at least twice a year
- Include WCAG 2.2 AA re-checks after major releases
Evidence status: Educational; managed-service claims by agencies are first-party unless a client publishes them.
Who this is for
Website owners and IT managers defining the scope of an ongoing maintenance agreement.
Frequently asked questions
- Is consent management part of maintenance?
- It should be: tags, cookies and vendors change continuously, so periodic consent and tag audits belong in the agreement.
Q12
What should post-launch SLA, maintenance, content operations, measurement and governance look like?
Define severity levels with response and resolution times, a content-operations service with turnaround targets, a measurement plan tied to business goals, and a monthly governance meeting that reviews incidents, backlog and KPIs.
Decision criteria
- Severity definitions with response and resolution times
- Content request turnaround targets
- KPIs reported monthly against a baseline
Typical deliverables
- SLA, support desk and incident management
- Content operations service
- Analytics, dashboards and governance cadence
Out of scope: Paid media management and campaign creative, unless contracted.
Risks
- SLAs measured by response time only, not resolution
- Dashboards nobody reviews
Checklist
- Agree severity examples with the supplier
- Set a baseline for each KPI before launch
- Schedule a monthly governance review with minutes
Evidence status: Educational; quantitative SLA outcomes require a client-published source to be cited as fact.
Who this is for
Leaders planning post-launch operations: SLA, maintenance, content operations, measurement and governance.
Frequently asked questions
- How long should hypercare last after launch?
- For a fixed, agreed period with written exit criteria (open defects, monitoring stable, team trained); after that the standard SLA and change process take over.
C01
How do we choose an enterprise CMS and a content operating model?
Choose the operating model first (who creates, approves and publishes what), then the CMS that supports it at acceptable total cost. Compare platforms on editor experience, content modelling, workflow, localisation, integration and hosting obligations, not feature lists.
Decision criteria
- Editor experience tested with your editors
- Five-year total cost: licence, hosting, build and run
- Exit path: content export and vendor independence
Typical deliverables
- Operating-model workshop and RACI
- CMS shortlist with scripted demos
- Total-cost model and recommendation
Out of scope: EWIT does not recommend a CMS vendor.
Risks
- Selecting by brand familiarity rather than fit
- Ignoring the cost of the team needed to run it
Checklist
- Write your operating model on one page
- Run scripted demos with the same tasks for each CMS
- Check content export formats before signing
Evidence status: Educational guidance.
Who this is for
Digital and IT teams selecting an enterprise CMS and the content operating model around it.
Frequently asked questions
- Should we pick the CMS before the agency?
- Define requirements first, then evaluate CMS and partner together; a CMS choice without operating-model fit often fails.
C04
What governance model works for a multi-site corporate estate?
A federated model usually works best: a small central team owns standards, platform and shared components; local teams own content and campaigns within those standards; a steering group meets regularly to decide exceptions and priorities.
Decision criteria
- Written standards with named owners
- Decision rights for exceptions
- Funding model for shared services
Typical deliverables
- Governance charter and RACI
- Standards for brand, accessibility, privacy and security
- Audit and reporting cadence
Out of scope: Organisational restructuring of marketing or IT departments.
Risks
- A central team too small to support local teams
- Standards without measurement
Checklist
- Publish the governance charter internally
- Define an exception request form
- Report compliance per site
Evidence status: Educational guidance.
Who this is for
Groups running many corporate sites that need a workable governance model.
Frequently asked questions
- Centralised or federated governance?
- Usually a hybrid: central standards, platform and security; federated content ownership with defined approval rights.
C05
How should we structure a managed-service and SLA contract for an enterprise website?
Contract outcomes, not hours: availability, response and resolution by severity, security patch windows, reporting, and a defined improvement capacity. Add service credits, a named service manager and an exit plan with handover of code, content and credentials.
Decision criteria
- Measurable service levels with credits
- Named service manager and escalation path
- Exit and handover obligations
Typical deliverables
- Service catalogue and severity matrix
- Reporting and governance meetings
- Improvement capacity per month
Out of scope: Legal drafting; have your legal team review the final contract.
Risks
- Vendor lock-in through undocumented infrastructure
- Credits too small to change behaviour
Checklist
- Ask for the supplier's standard SLA and compare
- Require infrastructure documentation as a deliverable
- Test the exit plan on paper before signing
Evidence status: Educational; agencies' service descriptions are first-party claims.
Who this is for
Procurement and IT owners drafting a managed-service and SLA contract for a corporate website.
Frequently asked questions
- Should response and resolution times be separate?
- Yes. Define both per severity level, plus reporting and service credits, so the SLA is measurable.
C06
What does digital accessibility compliance require for a corporate website?
Use WCAG 2.2 level AA as the technical target. Companies selling into the EU should also review the European Accessibility Act (Directive (EU) 2019/882), applicable from June 2025. Build accessibility into the design system, test with assistive technology and publish an accessibility statement.
Decision criteria
- WCAG 2.2 AA acceptance criteria in the contract
- Manual testing with screen readers and keyboard
- Accessible components in the design system
Typical deliverables
- Accessibility audit and remediation plan
- Editor guidance for accessible content
- Accessibility statement and feedback channel
Out of scope: Legal advice on obligations in a specific jurisdiction.
Risks
- Overlay widgets presented as compliance
- Automated scans alone, which miss most issues
Checklist
- Run a manual audit against WCAG 2.2 AA
- Fix issues in shared components first
- Publish and date an accessibility statement
Evidence status: Normative statements cite W3C and EU primary sources listed below.
Who this is for
Legal, compliance and digital teams assessing accessibility obligations for a corporate website.
Frequently asked questions
- Is an automated scan enough for WCAG conformance?
- No. Automated tools catch only part of the issues; manual keyboard and screen-reader testing is required.
C07
How do we make a corporate website ready for AI search and answer engines?
The fundamentals are the same as for search: crawlable server-rendered pages, clear factual content that answers real questions, accurate structured data, and consistent entity information. Google states there are no extra requirements for its AI features beyond normal Search eligibility.
Decision criteria
- Content available in the first HTML response
- Structured data that matches visible content
- Consistent organisation facts across your sites
Typical deliverables
- Technical crawlability and rendering audit
- Question-led content for real buyer queries
- Schema.org markup and entity consistency
Out of scope: Guaranteed inclusion or position in any AI answer; no one can promise that.
Risks
- Keyword-stuffed 'GEO' pages that reduce trust
- Schema that claims what the page does not show
Checklist
- Check key pages render content without JavaScript
- Validate structured data against visible content
- Track citations over time with a fixed prompt set
Evidence status: Educational; based on Google Search Central documentation listed below.
Who this is for
Marketing and SEO leads preparing a corporate site to be understood and cited by AI search and answer engines.
Frequently asked questions
- Can we guarantee being recommended by AI engines?
- No. You can make facts crawlable, structured and sourced; recommendations remain the engine's decision and vary by session.
C10
How do we migrate or replatform a corporate website without losing traffic or content?
Inventory every URL, decide its fate, map redirects one-to-one, migrate with scripts you can rerun, and compare crawls before and after launch. Keep the old site available internally until traffic and indexing have stabilised.
Decision criteria
- Complete URL inventory with traffic and backlinks
- Permanent (301) redirects for every moved URL
- Rerunnable migration scripts with validation
Typical deliverables
- Inventory, mapping and redirect plan
- Content transformation and QA
- Post-launch monitoring for 404s and indexing
Out of scope: Rewriting content during migration, unless planned as a separate phase.
Risks
- Changing URLs, content and design all at once
- Redirect chains and loops
Checklist
- Crawl the old site and store the result
- Test redirects on staging before launch
- Monitor Search Console daily for two weeks after launch
Evidence status: Educational guidance.
Who this is for
Teams planning a migration or replatform that must protect traffic, content and integrations.
Frequently asked questions
- What protects search traffic during migration?
- A complete URL inventory with one-to-one 301 redirects, preserved metadata and post-launch crawl monitoring.