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

Spec 404 - Public Website Sales Copy & Positioning Rewrite

Feature Branch: 404-public-content-messaging

Created: 2026-05-25

Status: Draft

Input: Rewrite the public Tenantial website positioning so a later website implementation can ship strong B2B SaaS, cybersecurity, and IT-operations sales copy instead of internal architecture, governance-process, or Spec Kit language.

Spec Candidate Check

• Problem: The current public website copy reads too much like an internal governance and architecture explanation. MSPs, IT leaders, security teams, and enterprise IT buyers need to understand the risks Tenantial reduces and the business outcomes it supports.
• Today's failure: The site can sound defensive, philosophical, or category-first instead of clearly selling Microsoft 365 policy control, drift visibility, versioned configuration backups, review-ready evidence, controlled recovery preparation, and auditability.
• User-visible improvement: A buyer can understand what Tenantial helps them do, why it matters, who it serves, and which Microsoft 365 governance risks it addresses without needing internal product or architecture context.
• Smallest enterprise-capable version: Rewrite the governing Spec 404 artifacts so the next implementation agent has a concrete homepage copy contract, safe claim guardrails, section structure, CTA language, SEO direction, and acceptance criteria.
• Explicit non-goals: No apps/platform edits, no backend/runtime dependency changes, no database changes, no provider implementation, no trust/certification claims, and no unsupported production capability claims.
• Permanent complexity imported: No models, services, enums, runtime flows, providers, persisted data, UI frameworks, or new website architecture. This spec imports only public copy rules and claim discipline.
• Why now: Public positioning is the input for later landing-page work. If the spec remains architecture-heavy, later implementation will optimize the wrong message.
• Why not local: The correction must align spec.md, plan.md, and tasks.md; otherwise future implementation can still pull from old defensive, academic, or internal wording.
• Approval class: Core Enterprise.
• Red flags triggered: Public category ambiguity, trust-claim risk, provider overclaim risk, internal language leaking into buyer-facing copy.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 2 | Produktnaehe: 2 | Wiederverwendung: 1 | Gesamt: 11/12
• Decision: approve.

Red Flag Defense

This spec intentionally proceeds despite multiple red flags because the risks are public-facing trust and positioning risks, not a request for new platform machinery. The current correction prevents misleading public claims, Intune-only framing, unsupported provider language, and architecture-first marketing copy. The scope is deliberately narrow: only the 404 spec artifacts are rewritten now, and later implementation remains website-only. No runtime provider seam, persistence model, taxonomy, framework, or platform contract is introduced.

Scope

This spec is a copy and positioning contract for the public Tenantial website.

• Relevant application for later implementation: apps/website
• Files changed by this implementation: 404 spec artifacts plus the minimal apps/website source and website-smoke-test files needed to render and validate the approved homepage sales copy.
• Out of scope for this change: platform source files, build output, runtime config, database, Laravel, Filament, Microsoft Graph integration, provider implementation, and unsupported trust/certification claims.
• Product focus: Microsoft 365 is the first public market
• Start domain: Intune may appear as the first strong policy focus and example domain
• Product boundary: Intune must not be framed as the full product boundary
• Provider posture: prepared for further policy domains may be used as an architecture or roadmap signal; Google, AWS, or multi-cloud support must not appear as live features unless separately proven by repo/product truth

Spec Scope Fields

• Scope: Public website copy and positioning contract.
• Primary Routes: apps/website, primarily /, with supporting alignment possible for public website routes such as /platform, /trust, /pricing, /contact, and public metadata.
• Data Ownership: No tenant-owned, workspace-owned, customer, provider, backup, evidence, or runtime product data is created, read, changed, or persisted.
• RBAC: N/A. This spec concerns public website copy guidance and does not change authenticated platform access, tenant access, roles, permissions, or authorization behavior.

For canonical-view specs:

• Default filter behavior when tenant-context is active: N/A - no tenant-context view or canonical platform view is introduced.
• Explicit entitlement checks preventing cross-tenant leakage: N/A - no tenant data, workspace data, or authenticated platform state is involved.

Positioning Goal

Tenantial must be presented as a hard, credible B2B platform for Microsoft 365 governance and IT operations.

Visible website copy must emphasize outcomes:

• Microsoft 365 policies under control
• early detection of policy drift
• versioned configuration backups
• evidence prepared for reviews, changes, recovery, and audits
• controlled recovery and restore preparation
• multi-customer and multi-tenant operating clarity for MSPs
• shared evidence for IT, security, and audit teams
• traceable decisions through findings, exceptions, accepted risks, follow-ups, and review packs

The website must not lead with internal product philosophy, architecture, or taxonomy. It should sound like a product marketing manager for a B2B cybersecurity and IT-operations SaaS wrote it: active, direct, technically credible, outcome-oriented, and commercially useful.

Visible Copy Rules

Required Tone

Visible public copy must be:

• active and confident
• technically credible without becoming a whitepaper
• outcome-oriented
• MSP- and enterprise-ready
• specific about Microsoft 365 governance risks
• clear about review, evidence, drift, backup, and recovery context
• careful with compliance, automation, hosting, and provider claims

Visible public copy must not be:

• defensive
• academic
• life-coach style
• internal wiki prose
• Spec Kit language
• architecture-first
• category-philosophy-first
• vague neutral SaaS copy

Do Not Use As Visible Marketing Headline Language

The following concepts and phrases must not be used as primary visible landing-page language:

• "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"
• "Policy Governance Kategorie"
• "Observe-to-Audit operating model"
• "governance-of-record platform"
• "platform-core seam"
• "provider-owned boundary"
• "Spec Candidate Check"
• "proportionality review"

These ideas may inform internal planning, but they must not be the buyer-facing story.

Preferred Public Language

Use direct, market-facing language such as:

• "Microsoft 365 Policies unter Kontrolle bringen"
• "Policy-Drift früh erkennen"
• "Konfigurationsstände versioniert sichern"
• "auditfähige Evidence vorbereiten"
• "prüfbare Review Packs"
• "kontrollierte Recovery- und Restore-Vorbereitung"
• "nachvollziehbarer Audit Trail"
• "Microsoft 365 first"
• "Intune als erster starker Policy-Fokus"
• "für weitere Policy-Domänen vorbereitet"

Claim Guardrails

Forbidden Or Strongly Restricted Claims

Visible website copy must not claim:

• "unter absoluter Kontrolle"
• "Drift in Echtzeit", unless technically proven
• "automatisch reparieren"
• "autonomous remediation"
• "Self-healing"
• "automatic restore"
• "lückenlose Evidenz", unless precisely scoped and proven
• "gerichtsfeste Nachweise"
• "immutable backups", unless real immutability is proven for the public claim context
• "DSGVO-konform"
• "ISO-zertifiziert"
• "NIS2-konform"
• "Google supported"
• "AWS supported"
• "multi-cloud supported" as a live-feature claim

Safe Alternatives

Use safer phrasing:

• "Policy-Drift früh erkennen"
• "Konfigurationsstände versioniert sichern"
• "auditfähige Evidence vorbereiten"
• "Review Packs für Audits und Kundentermine vorbereiten"
• "Recovery- und Restore-Fragen kontrolliert bewerten"
• "Restore vorbereiten, bevor Änderungen ausgeführt werden"
• "Nachvollziehbarkeit für Changes, Findings und Accepted Risks schaffen"
• "Microsoft 365 first"
• "Intune als erster starker Policy-Fokus"
• "für weitere Policy-Domänen vorbereitet"

Trust And Compliance Posture

Trust copy may speak about auditability, review preparation, role-aware evidence, and decision traceability. It must not imply legal certification, regulatory conformity, hosting guarantees, or customer-proof artifacts that are not currently proven.

Homepage Copy Contract

The later homepage implementation must follow this section structure unless a later approved spec narrows it.

1. Hero

Headline

Microsoft 365 Policies unter Kontrolle bringen.

Subhead

Tenantial hilft MSPs und Enterprise-IT-Teams, Policy-Drift früh zu erkennen, Konfigurationen versioniert zu sichern und auditfähige Evidence für Reviews, Changes und Recovery bereitzustellen.

Supporting line

Gebaut für Microsoft 365 Governance - mit Intune als erstem starken Policy-Fokus und einem Modell für weitere Policy-Domänen.

CTAs

• Demo buchen
• Plattform ansehen

2. Problem Section

Headline

Wenn Microsoft 365 Policies driften, reicht ein Admin Center nicht aus.

Body

Tenantial zeigt, was sich geändert hat, welche Konfigurationen abgesichert sind, welche Evidence vorliegt und welche Findings vor dem nächsten Review geklärt werden müssen.

3. Capability Cards

1. Policy-Drift erkennen Abweichungen zwischen erwarteter und tatsächlicher Konfiguration sichtbar machen.

2. Backups & Versionen behalten Policy-Zustände nachvollziehbar sichern und Änderungen historisch vergleichbar machen.

3. Auditfähige Reviews vorbereiten Findings, Evidence, Accepted Risks und Review Packs für Kundentermine und interne Audits bündeln.

4. Recovery kontrolliert vorbereiten Restore- und Recovery-Fragen mit Scope, Risiko und Evidence bewerten, bevor Änderungen ausgeführt werden.

5. Provider-Berechtigungen transparent machen Microsoft Graph und Provider-Zugriffe verständlich erklären, prüfen und capability-orientiert einordnen.

6. Entscheidungen nachvollziehbar machen Findings, Exceptions, Accepted Risks und Follow-ups in einen prüfbaren Governance-Kontext bringen.

4. Stakeholder Section

Headline

Eine belastbare Wahrheit für MSPs, IT und Audit.

Body

Tenantial verbindet technische Konfigurationsdaten mit Evidence, Findings und Reviews - damit Operatoren, Security-Verantwortliche und Auditoren nicht aus Screenshots, Excel-Listen oder Bauchgefühl entscheiden.

Stakeholder cards

• MSP Operatoren Mehrere Kundenumgebungen kontrolliert überwachen, vergleichen und reviewfähig vorbereiten.

• Enterprise IT Änderungen, Drift und Recovery-Risiken nachvollziehbar dokumentieren.

• Security & Audit Evidence, Findings und Accepted Risks in prüfbare Review-Unterlagen überführen.

5. Differentiation Section

Headline

Gebaut für Governance. Nicht für blinde Automatisierung.

Body

Tenantial ersetzt nicht das Microsoft Admin Center. Es ergänzt es um die Schicht, die Enterprise-Teams im Alltag fehlt: Versionierung, Evidence, Drift-Sichtbarkeit, Review-Kontext und auditierbare Entscheidungen.

6. Trust Teaser

The trust teaser must stay specific but conservative. It may mention:

• nachvollziehbarer Audit Trail
• Review Packs
• Evidence for reviews and change discussions
• role-aware governance context
• controlled recovery preparation
• security and audit stakeholders working from the same data basis

It must not claim DSGVO conformity, ISO certification, NIS2 conformity, German hosting, legal-proof evidence, or complete evidence coverage.

7. Bottom 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
• Plattform ansehen

Metadata And SEO Direction

SEO metadata must sell the same story in compressed form:

• primary market: Microsoft 365 governance
• primary outcomes: policy drift visibility, versioned configuration backup, evidence, reviews, controlled recovery preparation, auditability
• target audiences: MSPs, Enterprise IT, security, audit
• first domain: Intune
• future posture: prepared for further policy domains, not live multi-cloud support

Example title direction:

Tenantial - Microsoft 365 Policy Governance for MSPs and Enterprise IT

Example description direction:

Detect Microsoft 365 policy drift early, keep versioned configuration backups, and prepare audit-ready evidence for reviews, changes, and controlled recovery.

Requirements

Scope Requirements

• FR-001: The implementation MAY modify the 404 spec artifacts and apps/website source or website-smoke-test files required for the homepage sales-copy rewrite.
• FR-002: Website implementation scope MUST remain apps/website only.
• FR-003: This spec MUST explicitly forbid apps/platform changes.
• FR-004: This implementation MUST not introduce backend runtime, database, platform, provider, dependency, or build-output changes.

Sales-Copy Requirements

• FR-005: Visible public copy MUST sell business outcomes rather than internal architecture.
• FR-006: The homepage hero MUST lead with Microsoft 365 policy control, not product-category philosophy.
• FR-007: The hero and first supporting section MUST mention policy drift, versioned configuration backups, evidence, reviews, changes, and recovery context.
• FR-008: Microsoft 365 MUST be the first public market.
• FR-009: Intune MAY appear as the first strong policy focus, but MUST NOT be treated as the full product boundary.
• FR-010: Provider extensibility MUST be secondary and MUST NOT become hero philosophy.
• FR-011: Google, AWS, and multi-cloud support MUST NOT appear as live capabilities unless separately proven.
• FR-012: Public copy MUST address MSPs, Enterprise IT, Security, and Audit as first-class audiences.
• FR-013: Public copy MUST present recovery and restore as controlled preparation and evaluation, not blind automation.
• FR-014: Public copy MUST avoid the forbidden and strongly restricted claims listed in this spec.
• FR-015: Public copy MUST avoid internal governance, architecture, and Spec Kit terms as visible buyer-facing language.

Homepage Structure Requirements

• FR-016: The later homepage implementation MUST include a hero, problem section, capability cards, stakeholder/persona section, differentiation section, trust teaser, and bottom CTA.
• FR-017: Capability cards MUST be outcome-led and cover drift, backups/versioning, reviews/evidence, recovery preparation, permissions/provider access, and decision traceability.
• FR-018: Stakeholder copy MUST explicitly cover MSP operators, Enterprise IT, and Security/Audit.
• FR-019: Differentiation copy MUST explain that Tenantial complements Microsoft Admin Center rather than replacing it.
• FR-020: Bottom CTA copy MUST invite a concrete demo or platform exploration without overclaiming maturity or automation.

Validation Requirements For Later Implementation

• FR-021: Later implementation MUST include static scans for forbidden claims and old internal/defensive phrases.
• FR-022: Later implementation MUST include browser smoke review for desktop and mobile homepage readability, CTA visibility, and no visible copy overlap.
• FR-023: Later implementation MUST confirm no apps/platform files changed.
• FR-024: Later implementation MUST report whether old 404 copy was replaced or only supplemented.

Testing / Lane / Runtime Impact

• Current change classification: Browser/static website copy implementation.
• Runtime impact: Static website source and website smoke-test expectations only. No backend, database, provider, platform, dependency, or build-output change is introduced.
• Affected validation lane for this implementation: Website build, static forbidden-claim scan, desktop/mobile browser smoke, CTA/link checks, metadata review, and explicit confirmation that apps/platform remains untouched.
• Validation for this implementation: corepack pnpm build:website, targeted static claim scan, browser review on http://127.0.0.1:4321/, git diff --check, git diff --name-only, and git status --short -- apps/platform.
• Later implementation classification: N/A for homepage sales copy; follow-up specs may extend supporting routes.
• Later implementation validation: N/A.
• Pest/Laravel/Filament/Sail coverage: N/A for this spec update. Later website-copy implementation should not add backend or platform test lanes unless it actually changes backend/platform behavior.
• Fixture/helper/runtime cost: None for this spec update.
• Escalation: If later implementation requires platform, provider, auth, database, or runtime changes, that work must be split into a separate spec.

User Scenarios And Acceptance Criteria

User Story 1 - MSP Buyer Understands The Operational Risk

An MSP operator or owner reads the homepage and understands that Tenantial helps control Microsoft 365 policy drift, versioning, evidence, reviews, and recovery context across customer environments.

Acceptance Criteria

1. Given the hero and problem section, when an MSP buyer summarizes the product, then they mention Microsoft 365 policy control and drift visibility rather than an internal governance model.
2. Given the stakeholder cards, when an MSP buyer scans the page, then multi-customer or multi-tenant review preparation is visible without implying unsupported providers.

User Story 2 - Enterprise IT Sees Recovery And Audit Context

An IT leader reads the page and understands that Tenantial documents changes, configuration history, drift, and recovery risk before action.

Acceptance Criteria

1. Given the capability cards, when Enterprise IT evaluates the page, then versioned backups, historical comparison, and controlled recovery preparation are explicit.
2. Given the differentiation section, when Enterprise IT compares Tenantial to Microsoft Admin Center, then Tenantial is clearly positioned as an evidence, versioning, and review layer.

User Story 3 - Security And Audit See Review-Ready Evidence

Security and audit stakeholders see that Tenantial helps transform configuration data, findings, accepted risks, and follow-ups into review-ready material.

Acceptance Criteria

1. Given the stakeholder section, when Security or Audit scans the page, then evidence, findings, accepted risks, and review packs are visible.
2. Given the trust teaser, when a compliance-sensitive evaluator reviews the copy, then it avoids unsupported legal, certification, hosting, or complete-evidence claims.

User Story 4 - Implementation Agent Has Concrete Copy Direction

A later implementation agent can convert this spec into website copy without reintroducing internal architecture language.

Acceptance Criteria

1. Given this spec, when the agent drafts homepage copy, then each homepage section has concrete example text and claim guardrails.
2. Given this spec, when the agent validates the implementation, then static scans can target forbidden phrases, overclaims, and old defensive copy.

Success Criteria

• SC-001: Spec 404 is clearly titled as a Public Website Sales Copy & Positioning Rewrite.
• SC-002: The spec sells business outcomes instead of internal architecture.
• SC-003: Concrete visible homepage copy examples are present for hero, problem, capability cards, stakeholders, differentiation, and bottom CTA.
• SC-004: Microsoft 365 is the first public market.
• SC-005: Intune is allowed as a first strong policy focus, not as the product boundary.
• SC-006: Provider extensibility is secondary and safely bounded.
• SC-007: The spec bans unsupported compliance, automation, provider, hosting, and evidence-hardening claims.
• SC-008: Acceptance criteria prove B2B sales-copy quality for MSP, Enterprise IT, Security, and Audit audiences.
• SC-009: The spec states that later implementation is apps/website relevant only.
• SC-010: The implementation changes only approved 404 spec artifacts and minimal apps/website source or website-smoke-test files; it changes no apps/platform, root workspace contracts, dependencies, build output, or backend runtime files.

Follow-Up Specs

Potential follow-up specs should stay separate from this positioning rewrite:

• 405 Trust: detailed trust, security, hosting, legal, and evidence substantiation once proof exists
• 406 Provider Taxonomy: current-versus-planned provider and policy-domain vocabulary if public provider expansion becomes real
• 407 Use Cases: dedicated MSP, Enterprise IT, Security, Audit, and Recovery use-case pages