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