TenantAtlas/specs/404-public-content-messaging/plan.md

# Implementation Plan: Public Website Sales Copy & Positioning Rewrite

**Branch**: `404-public-content-messaging`
**Date**: 2026-05-25
**Spec**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging/spec.md`

## Summary

This plan turns Spec 404 into a website-copy refactoring plan, not an architecture plan. The goal is to guide a later implementation that rewrites public Tenantial website copy toward B2B SaaS, cybersecurity, and IT-operations outcomes for MSPs, Enterprise IT, Security, and Audit.

This implementation renders the approved homepage sales copy in `apps/website` while keeping platform/backend/runtime scope untouched.

## Scope Decision

- **404 path found**: `/Users/ahmeddarrazi/Documents/projects/wt-website/specs/404-public-content-messaging`
- **Decision**: This is the Public Website Sales Copy & Positioning Spec because the branch, folder name, prior title, and existing content all target public website messaging, homepage hierarchy, provider/trust wording, metadata, and `apps/website`.
- **Spec artifact scope**: `spec.md`, `plan.md`, and `tasks.md`
- **Website implementation scope**: `apps/website` source files and website smoke-test expectations needed for the homepage copy rewrite
- **Explicitly out of scope now**: `apps/platform`, root package/workspace contracts, build output, runtime config, generated assets, dependencies, backend code, provider integrations, and unsupported trust/certification claims

## Repo Verification

Before any later implementation agent edits website source, verify current repo truth instead of relying on this plan as a file-map guarantee:

1. Run `git status --short --branch`.
2. Locate the 404 spec folder with `find specs -maxdepth 2 -iname '*404*' -type d -o -iname '*404*' -type f`.
3. Read `specs/404-public-content-messaging/spec.md`, `plan.md`, and `tasks.md`.
4. Inspect the website structure with `find apps/website -maxdepth 3 -type f | sort | sed -n '1,180p'`.
5. Read `apps/website/package.json` and use only scripts that actually exist.
6. Confirm `apps/platform` remains outside the change.

## Current Copy Inventory

The later implementation must inventory current visible website copy before changing it:

- homepage hero and above-the-fold copy
- homepage section titles and CTA labels
- platform/product page copy
- trust, pricing, contact, and docs entry copy if they repeat the same positioning
- metadata titles and descriptions
- navigation/footer labels only if they repeat stale positioning
- smoke-test forbidden-pattern lists, if they exist

The inventory must identify old internal, defensive, academic, or architecture-heavy wording, including:

- category-first positioning
- "operating model" language as visible marketing copy
- "source of truth" or "provider-extensible" as hero philosophy
- internal governance-process wording
- defensive boundary language that crowds out outcomes
- vague trust language that sounds like certification without proof

## Copy Refactoring Workstreams

### 1. Hero And Above The Fold

Define the homepage first screen around this core message:

- Microsoft 365 Policies unter Kontrolle bringen.
- Policy-Drift früh erkennen.
- Konfigurationen versioniert sichern.
- auditfähige Evidence für Reviews, Changes und Recovery bereitstellen.
- Intune as the first strong policy focus, not the product boundary.

Primary CTA: "Demo buchen"
Secondary CTA: "Plattform ansehen"

### 2. Problem And Pain Section

The first supporting section must make the buyer pain explicit:

- Microsoft 365 policies drift.
- Admin centers show current settings but do not provide enough review context by themselves.
- Operators need to know what changed, what is backed up, which evidence exists, and which findings need action before the next review.

Avoid product-philosophy explanations here.

### 3. Capability Cards

Capability cards must be outcome-led and use the spec copy as the default source:

- Policy-Drift erkennen
- Backups & Versionen behalten
- Auditfähige Reviews vorbereiten
- Recovery kontrolliert vorbereiten
- Provider-Berechtigungen transparent machen
- Entscheidungen nachvollziehbar machen

Each card must describe what the buyer can see, compare, prepare, or document. Do not turn these into internal modules or architecture components.

### 4. Stakeholder And Persona Section

Define a clear stakeholder section for:

- MSP Operatoren
- Enterprise IT
- Security & Audit

The section must show one reliable evidence basis for operators, security owners, and auditors. It should replace screenshot, Excel, and gut-feel decision language with review-ready evidence and traceable findings.

### 5. Differentiation Section

Differentiate Tenantial without attacking Microsoft tools:

- Tenantial does not replace Microsoft Admin Center.
- Tenantial adds versioning, evidence, drift visibility, review context, and auditability.
- Tenantial is built for governance and controlled review, not blind automation.

### 6. Trust Teaser

Keep the trust teaser safe and specific:

- allowed: audit trail, review packs, role-aware evidence, controlled recovery preparation, decision traceability
- forbidden unless proven: DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, complete evidence coverage, no-customer-data claims

Do not make trust the hero story in Spec 404. A separate trust-focused spec can deepen it.

### 7. Bottom CTA

End with an evaluation-oriented CTA:

- Headline: "Bereit, Microsoft 365 Governance messbar zu machen?"
- Body: "Sieh in einer fokussierten Demo, wie Tenantial Policy-Drift, Backups, Evidence und Reviews in einen kontrollierten Governance-Prozess bringt."
- Buttons: "Demo buchen" and "Plattform ansehen"

### 8. SEO And Metadata Direction

SEO metadata must compress the same B2B message:

- Tenantial = Microsoft 365 policy governance
- outcomes = drift detection, versioned backups, evidence, reviews, controlled recovery preparation, auditability
- audiences = MSPs, Enterprise IT, Security, Audit
- first domain = Intune
- future posture = prepared for further policy domains, not live multi-cloud

Do not use Intune-only, backup-only, autonomous remediation, or certification-heavy metadata.

## Claim Guardrails And Static Search Terms

Later implementation must include static scans for stale or unsafe copy. At minimum, scan website source and emitted public output when applicable for:

- `Die richtige Produktkategorie zuerst`
- `Für Teams, die Governance gemeinsam tragen`
- `Klare Grenzen statt überzogener Versprechen`
- `Den nächsten Schritt bewusst wählen`
- `provider-extensible managed environment operating model`
- `source-of-truth first operating model`
- `Observe-to-Audit`
- `governance-of-record`
- `unter absoluter Kontrolle`
- `Drift in Echtzeit`
- `automatisch reparieren`
- `autonomous remediation`
- `Self-healing`
- `automatic restore`
- `lückenlose Evidenz`
- `gerichtsfeste Nachweise`
- `immutable backups`
- `DSGVO-konform`
- `ISO-zertifiziert`
- `NIS2-konform`
- `Google supported`
- `AWS supported`
- `multi-cloud supported`
- `href="#"`
- `lorem ipsum`

Safe copy can still use "Microsoft 365 first", "Intune als erster starker Policy-Fokus", and "für weitere Policy-Domänen vorbereitet" when the surrounding text clearly separates current capability from roadmap or architecture direction.

## Browser Smoke Requirements For Later Implementation

Later implementation must verify:

- desktop and mobile homepage first viewport reads cleanly
- hero headline, subhead, supporting line, and CTAs are visible and not overlapping
- section order matches the spec: hero, problem, capabilities, stakeholders, differentiation, trust teaser, bottom CTA
- CTA targets are real routes or intentional in-page anchors
- no placeholder links remain
- no forbidden claims render in source or public output
- metadata reinforces Microsoft 365 policy governance
- Intune appears only as first domain or example focus
- provider-extensible wording does not imply Google, AWS, or multi-cloud live support
- `apps/platform` remains untouched

Use the existing website scripts from `apps/website/package.json` and root workspace scripts only after verifying they exist.

## Runtime And Scope Boundaries

This plan is intentionally static-website-only for the current task:

- no platform source edits
- no build output edits
- no dependency changes
- no package-script changes
- no backend runtime changes
- no provider implementation changes
- no `apps/platform` changes

## Validation For This Spec Update

For the current website-copy implementation, validation includes:

- `corepack pnpm build:website`
- targeted static claim scan for forbidden public copy in `apps/website/src` and `apps/website/public`
- browser review on `http://127.0.0.1:4321/`
- `git diff --check`
- `git status --short -- apps/website apps/platform`
- `git diff --name-only`

Expected result: only approved 404 spec artifacts plus minimal `apps/website` source and website-smoke-test files are modified, with any pre-existing unrelated untracked files left untouched.

## Follow-Up Specs

- **405 Trust**: proof-backed trust, hosting, privacy, security, compliance, legal, and evidence claims
- **406 Provider Taxonomy**: public current-versus-planned policy-domain and provider vocabulary
- **407 Use Cases**: dedicated MSP, Enterprise IT, Security/Audit, Recovery, and Review landing pages