TenantAtlas/specs/409-evaluation-procurement-rollout/spec.md

Feature Specification: Evaluation, Procurement & Rollout Readiness Website Surface

Feature Branch: 409-evaluation-procurement-rollout
Created: 2026-05-30
Status: Draft
Input: User description: "Create a public website page that explains how MSPs and Enterprise IT can evaluate, procure, and roll out Tenantial through a structured demo, pilot, security review, and rollout-readiness path without any apps/platform runtime changes."

Spec Candidate Check (mandatory - SPEC-GATE-001)

• Problem: Public buyers still lack one concrete public page that explains how Tenantial is evaluated, reviewed internally, piloted, and prepared for controlled rollout.
• Today's failure: After the homepage, trust, provider taxonomy, use-case pages, and review/evidence story, prospects still need to ask the same manual questions about demos, pilot scope, Microsoft 365 access, security/privacy review, and procurement readiness.
• User-visible improvement: A first-time MSP, IT lead, security reviewer, Datenschutz contact, or procurement stakeholder can understand in one visit how to start, what to prepare, which questions matter, and what Tenantial does not promise.
• Smallest enterprise-capable version: One dedicated public website page, lightweight discoverability from existing IA, page-specific metadata, real CTA routing only, and explicit claim boundaries around demo, pilot, trust, security review, and rollout readiness.
• Explicit non-goals: No apps/platform changes, no onboarding runtime, no CRM, no billing, no trial provisioning, no Microsoft consent runtime, no Graph permission logic, no legal document generation, no fake AVV/TOM downloads, no fake security-pack downloads, no fake calendar booking, no fake customer logos, and no placeholder routes or links.
• Permanent complexity imported: One bounded public page, optional lightweight homepage/platform/trust/use-case/review discovery, public metadata updates, CTA/link guardrails, and copy-review obligations. No models, persistence, runtime abstractions, or product-state machinery are introduced.
• Why now: Specs 404 through 408 established public positioning, trust, provider scope, audience-specific use cases, and the review/evidence story. The remaining commercial friction is the practical evaluation, procurement, and rollout-readiness path.
• Why not local: Small copy additions on existing pages would keep the buyer journey fragmented across trust, use-case, and review surfaces and would not answer evaluation-readiness questions in one coherent destination.
• Approval class: Core Enterprise.
• Red flags triggered: Public overclaim risk, legal/security/procurement promise boundary, IA touch across multiple public entry points, and Microsoft 365 access wording that could drift into unverified permission claims.
• Score: Nutzen: 2 | Dringlichkeit: 2 | Scope: 2 | Komplexitaet: 1 | Produktnaehe: 2 | Wiederverwendung: 2 | Gesamt: 11/12
• Decision: approve.

Red Flag Defense

This spec is intentionally limited to a buyer-readiness page on the public website. It improves sales and evaluation clarity without pretending that trial provisioning, procurement automation, legal downloads, or security workflows already exist as self-service product truth. The scope stays inside one bounded page plus existing public discovery surfaces.

Scope

This spec defines one dedicated public website page that explains how MSPs and Enterprise IT teams can evaluate Tenantial through a controlled demo, pilot, security/privacy review, and rollout-readiness path.

• Relevant application for later implementation: public website only
• Depends on: Spec 404 - Public Website Sales Copy & Positioning Rewrite; Spec 405 - DACH Trust, Datenschutz & Security Website Surface; Spec 406 - Provider & Policy Domain Public Taxonomy; Spec 407 - MSP & Mittelstand Use-Case Pages; Spec 408 - Customer-safe Review, Evidence & Decision Story
• Must not depend on: apps/platform runtime changes
• Primary audience: MSP owners, MSP operators, IT leaders, Microsoft 365 admins, security reviewers, Datenschutz / DPO stakeholders, procurement / vendor-management stakeholders, DACH Mittelstand evaluators, and enterprise IT buyers
• Public message: Tenantial can be evaluated in a structured way through focused demos, clear pilot scope, transparent provider-permission discussions, trust-oriented security/privacy review, and realistic rollout expectations for Microsoft 365 governance
• Out of scope: self-service onboarding, CRM workflows, billing, subscriptions, trial provisioning, Graph consent runtime, legal-document generation, fake procurement portals, fake downloadable documents, fake calendar widgets, fake security or compliance artifacts, root workspace contract changes, and non-website implementation work

Goals

• G1: Explain a concrete evaluation path from first walkthrough to pilot and next-step decision.
• G2: Make pilot requirements and preparation work visible before a prospect asks for a manual explanation.
• G3: Prepare procurement, security, and Datenschutz review through clear, bounded public guidance.
• G4: Show which internal and external stakeholders should be involved in the evaluation.
• G5: Prevent fake self-service, legal, provider, security, or automation claims.
• G6: Improve conversion quality through real CTAs that match actual routes, forms, or contact methods.

Non-goals

• No apps/platform runtime work.
• No onboarding backend, tenant connection wizard, or consent flow.
• No CRM or lead-routing backend.
• No billing, subscriptions, or trial provisioning.
• No Microsoft Graph permission logic or exact permission matrix.
• No legal-document generation or fake AVV/TOM downloads.
• No fake calendar scheduling widget.
• No fake procurement portal.
• No fake downloadable security pack, legal pack, or procurement checklist.
• No fake logos, case studies, certifications, or compliance claims.
• No placeholder links, placeholder buttons, or href="#".

Spec Scope Fields (mandatory)

• Scope: N/A - public website surface outside authenticated workspace, tenant, or canonical product flows
• Primary Routes: preferred public route family /evaluierung for German-first IA or /evaluation for English-first IA; real fallback route families such as /demo-pilot, /procurement, or /start only when current IA requires them
• Data Ownership: no workspace-owned, tenant-owned, provider-owned, procurement, trust, legal, customer, or runtime product data is created, changed, or persisted by this feature
• RBAC: public read-only content only; no membership, role, capability, authorization, or authenticated product behavior changes

For canonical-view specs, the spec MUST define:

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

Cross-Cutting / Shared Pattern Reuse (mandatory when the feature touches notifications, status messaging, action links, header actions, dashboard signals/cards, alerts, navigation entry points, evidence/report viewers, or any other existing shared operator interaction family; otherwise write N/A - no shared interaction family touched)

• Cross-cutting feature?: yes
• Interaction class(es): public navigation, footer links, homepage teaser, platform-page teaser, trust/use-case/review crosslinks, CTA links, and metadata
• Systems touched: current public website shell, page-layout conventions, homepage, platform page, trust page, use-case pages, review/evidence page, navigation, footer, and page metadata
• Existing pattern(s) to extend: existing public website layout, section, card/grid, CTA, teaser, and metadata conventions
• Shared contract / presenter / builder / renderer to reuse: current website content structures and reusable presentation components
• Why the existing shared path is sufficient or insufficient: the public site already has the shell and adjacent buyer-story surfaces; this feature needs one focused evaluation-readiness destination inside that shell rather than a second microsite or a new design system
• Allowed deviation and why: a dedicated evaluation route is allowed when the current IA supports it because demo, pilot, security review, and rollout-readiness questions need one coherent destination
• Consistency impact: Microsoft 365-first wording, provider-permission transparency, trust-language boundaries, no-instant-trial posture, and real-CTA behavior must stay aligned across the new page and any discovery surfaces
• Review focus: verify that the evaluation path is understandable, the stakeholder and preparation sections are practical, all CTAs are real, and copy does not drift into unsupported legal, provider, automation, or self-service claims

OperationRun UX Impact (mandatory when the feature creates, queues, deduplicates, resumes, blocks, completes, or deep-links to an OperationRun; otherwise write N/A - no OperationRun start or link semantics touched)

• Touches OperationRun start/completion/link UX?: no
• Shared OperationRun UX contract/layer reused: N/A
• Delegated start/completion UX behaviors: N/A
• Local surface-owned behavior that remains: none
• Queued DB-notification policy: N/A
• Terminal notification path: N/A
• Exception required?: none

Provider Boundary / Platform Core Check (mandatory when the feature changes shared provider/platform seams, identity scope, governed-subject taxonomy, compare strategy selection, provider connection descriptors, or operator vocabulary that may leak provider-specific semantics into platform-core truth; otherwise write N/A - no shared provider/platform boundary touched)

• Shared provider/platform boundary touched?: yes
• Boundary classification: mixed public vocabulary only
• Seams affected: Microsoft 365 access-readiness wording, provider-permission transparency, consent/admin-role language, trust-language handoff, and controlled-rollout versus blind-automation positioning
• Neutral platform terms preserved or introduced: evaluation, pilot scope, security review, trust documents, provider permissions, stakeholder readiness, review objective, success criteria, and controlled rollout
• Provider-specific semantics retained and why: Microsoft 365, consent, and admin-role language remain explicit because the public buying context is still Microsoft 365 governance and the evaluation path must feel concrete
• Why this does not deepen provider coupling accidentally: the feature explains evaluation boundaries and buyer preparation only; it does not introduce a runtime permission matrix, provider capability registry, or provider-owned product contract
• Follow-up path: none in this feature; later provider-expansion or permission-detail work belongs in follow-up website or platform specs only if product truth changes

UI / Surface Guardrail Impact (mandatory when operator-facing surfaces are changed; otherwise write N/A)

N/A - public website buyer-readiness surface only; no authenticated operator-facing product surface is changed.

Decision-First Surface Role (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Audience-Aware Disclosure (mandatory when operator-facing surfaces are changed)

N/A - public buyer-facing copy only; no operator diagnostics, support mode, or raw evidence surface is added here.

UI/UX Surface Classification (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Operator Surface Contract (mandatory when operator-facing surfaces are changed)

N/A - no operator-facing product surface change.

Proportionality Review (mandatory when structural complexity is introduced)

• New source of truth?: no
• New persisted entity/table/artifact?: no
• New abstraction?: no
• New enum/state/reason family?: no
• New cross-domain UI framework/taxonomy?: no - the feature reuses the current public website shell and existing page patterns
• Current operator problem: buyers and internal reviewers cannot yet plan a Tenantial evaluation without manually reconstructing the path across multiple public pages and conversations
• Existing structure is insufficient because: homepage, trust, use-case, and review/evidence surfaces answer adjacent questions, but they do not present one coherent evaluation and rollout-readiness journey
• Narrowest correct implementation: one dedicated public page plus lightweight discoverability from current IA
• Ownership cost: public copy, metadata, and CTA targets must stay aligned with actual trust, contact, and product truth as the commercial process evolves
• Alternative intentionally rejected: spreading the story across homepage, trust, and platform blurbs only, because that would keep evaluation readiness fragmented and harder to verify
• Release truth: current public website truth only; no runtime product promise or future abstraction is introduced

Compatibility posture

This feature assumes a pre-production environment.

Backward compatibility, legacy aliases, migration shims, historical fixtures, and compatibility-specific tests are out of scope unless explicitly required by this spec.

Canonical replacement is preferred over preservation.

Testing / Lane / Runtime Impact (mandatory for runtime behavior changes)

• Test purpose / classification: Browser
• Validation lane(s): browser, confidence
• Why this classification and these lanes are sufficient: public website quality is proven by reachable routes, readable desktop/mobile layouts, real CTA targets, static claim scans, and any existing website build/check/test commands that validate the public site
• New or expanded test families: none beyond website-only static checks and any existing public-site smoke coverage
• Fixture / helper cost impact: none
• Heavy-family visibility / justification: none
• Special surface test profile: N/A - public website surface
• Standard-native relief or required special coverage: ordinary public-site coverage only; verify route reachability, readable layout, real CTA links, crosslink integrity, and claim-boundary compliance
• Reviewer handoff: confirm only website-facing files change, no apps/platform files change, the chosen route follows current IA, CTA targets are real, and copy stays bounded around security, privacy, procurement, and pilot readiness
• Budget / baseline / trend impact: none expected
• Escalation needed: follow-up-spec only if later work introduces a real procurement workflow, trial automation, or legal/security document delivery surface
• Active feature PR close-out entry: Smoke Coverage
• Planned validation commands:
  • inspect root and website package manifests before running scripts
  • run only existing website check, build, or test commands if present
  • run static scans for placeholder links, banned internal phrases, and unsupported claims in website source and committed public assets
  • run desktop and mobile browser smoke for the evaluation page and any homepage/platform/trust/use-case/review discovery links if local preview is available

User Scenarios & Testing (mandatory)

User Story 1 - Buyers Understand The Evaluation Path (Priority: P1)

An MSP owner or internal IT evaluator opens the page and quickly understands how Tenantial is evaluated from first walkthrough through pilot and next-step decision.

Why this priority: The page exists primarily to remove the practical evaluation ambiguity that remains after the earlier public-site specs.

Independent Test: Can be fully tested by opening the page and confirming that the hero, evaluation-path section, timeline, and CTA language clearly explain how to start without implying instant self-service onboarding.

Acceptance Scenarios:

1. Given a first-time public buyer lands on the page, When they read the hero and evaluation-path section, Then they understand that Tenantial is evaluated through a structured sequence of demo, scope clarification, review, pilot, and next-step decision.
2. Given a visitor comparing products quickly, When they scan the page sections, Then they do not interpret Tenantial as an instant-trial product, blind automation tool, or generic procurement portal.
3. Given a visitor reaches the final CTA, When they review the call to action, Then they see a bounded next step such as demo, pilot request, trust review, or platform view through a real destination.

---

User Story 2 - Security And Procurement Stakeholders Know What To Prepare (Priority: P1)

A security reviewer, Datenschutz contact, or procurement stakeholder can identify which internal roles, trust questions, and document-status checks belong in the evaluation.

Why this priority: Enterprise and MSP buying friction usually appears in security, privacy, and procurement conversations rather than in product positioning alone.

Independent Test: Can be fully tested by reviewing the preparation, stakeholder, security/procurement, and FAQ sections to confirm that the page names the relevant contacts, questions, and review boundaries in buyer-facing language.

Acceptance Scenarios:

1. Given a security or Datenschutz stakeholder opens the page, When they review the security/procurement section, Then they can identify trust, AVV/DPA/TOM status, provider-permission, hosting/subprocessor, and retention-related review topics.
2. Given a procurement or vendor-management stakeholder reads the page, When they review the stakeholder and preparation sections, Then they can see which internal owners should be involved before a pilot or rollout decision.
3. Given a reviewer looks for legal or compliance promises, When they scan the page, Then they do not see fake downloads, fake approvals, or unverifiable compliance/certification claims.

---

User Story 3 - Technical Owners Understand Pilot Scope And Access Boundaries (Priority: P2)

A Microsoft 365 admin or technical owner can understand what a realistic pilot needs, what sort of access may be discussed, and what is explicitly not required for a first evaluation.

Why this priority: The page must answer technical-readiness questions without drifting into an unverified permissions matrix or overpromising write/remediation behavior.

Independent Test: Can be fully tested by reviewing the pilot-scenario, Microsoft 365 access, and "what is not required" sections to confirm that they explain scope-dependent access and controlled rollout language.

Acceptance Scenarios:

1. Given a technical owner reads the Microsoft 365 access section, When they review read-oriented access, recovery-adjacent access, and consent/admin-role wording, Then they understand that access requirements depend on pilot scope and are not blind defaults.
2. Given a visitor fears a forced big-bang rollout, When they read the "what Tenantial does not require" section, Then they understand that a limited-scope evaluation or pilot is possible.
3. Given a visitor asks whether a productive tenant is always required, When they review the FAQ, Then they see a careful answer that allows bounded starting scope without promising unrealistic outcomes from a zero-context setup.

---

User Story 4 - Visitors Discover The Page Through Real IA Entry Points (Priority: P2)

A public visitor should be able to find the evaluation page through the existing website information architecture without broken links, placeholders, or fake CTA targets.

Why this priority: The page only reduces friction if it is reachable from the places where buyers first decide whether to ask for a demo or pilot.

Independent Test: Can be fully tested by following homepage, platform, trust, use-case, review/evidence, navigation, or footer links to the page on desktop and mobile.

Acceptance Scenarios:

1. Given a visitor uses any homepage, platform, trust, use-case, review/evidence, navigation, or footer teaser added by this feature, When they follow the CTA, Then they reach the evaluation page through a real route.
2. Given a visitor uses any in-page CTA added by this feature, When they open the target, Then the destination resolves as a real route, form, or mailto target without placeholder behavior.
3. Given a mobile visitor opens the new page, When they scan the hero, core sections, FAQ, and CTA, Then the page remains readable and actionable.

Edge Cases

• What happens when the current website IA does not support /evaluierung or /evaluation cleanly? The implementation must choose a real route family that matches current conventions and document the decision.
• What happens when a suggested CTA target such as trust, demo, pilot request, platform view, or security-contact route does not exist as a real destination? The CTA must be omitted or mapped to an existing real destination.
• What happens when exact Microsoft 365 permissions are not verified in public source truth? The page must keep the access section at the level of scope-dependent readiness and must not publish an exact permission matrix.
• What happens when a buyer wants to know whether a productive tenant is required immediately? The page must answer cautiously and allow a bounded starting scope without implying that every meaningful evaluation can run with no real context.
• What happens when the active site language is German-first, English-first, or mixed? The implementation must follow current site conventions instead of introducing a new localization foundation.

Assumptions

• The current public website can support one real evaluation-readiness destination without changing root workspace contracts.
• At least one real destination exists for primary CTA flows such as demo/contact, trust, platform, or mailto contact; unavailable CTA variants may be omitted.
• AVV/DPA/TOM and security-document readiness can be described as status, discussion, or request-based handoff without claiming downloadable self-service artifacts.
• Microsoft 365 access requirements remain purpose- and pilot-scope-dependent and should not be marketed as a fixed universal permission set.
• The current site language strategy may be German-first or mixed; implementation should follow that convention instead of normalizing the whole site.

Requirements (mandatory)

This feature introduces no Microsoft Graph calls, no write/change product behavior, no persistence, no OperationRun flow, no RBAC mutation, and no provider runtime capability. Its only additions are bounded public website copy, route exposure, discoverability links, and metadata that translate existing product truth into an evaluation, procurement, and rollout-readiness story.

Functional Requirements

Scope And Route

• FR-001: The implementation MUST remain public-website-only and MUST NOT require apps/platform runtime changes.
• FR-002: The public website MUST provide one dedicated page for evaluation, procurement, and rollout readiness.
• FR-003: The implementation MUST follow the current website route family; the preferred destination is /evaluierung for German-first IA or /evaluation for English-first IA, with real fallback route families only when current IA requires them.
• FR-004: The chosen route and IA decision MUST be documented during implementation.
• FR-005: The new page MUST be reachable from at least one existing public-site entry point such as the homepage, platform page, trust page, use-case pages, review/evidence page, navigation, or footer.
• FR-006: Every CTA, teaser, nav link, footer link, and in-page link added by this feature MUST resolve to a real destination; placeholder links and href="#" are forbidden.

Core Story And Page Structure

• FR-007: The page MUST position Tenantial as a structured and controlled evaluation path for Microsoft 365 governance rather than as instant self-service software.
• FR-008: The page MUST explain a buyer journey from initial walkthrough or demo through scope clarification, security and Datenschutz review, technical readiness check, focused pilot, and review or commercial next-step decision.
• FR-009: The page MUST include a hero section, evaluation-path section, preparation section, pilot-scenario section, stakeholder section, security/procurement section, Microsoft 365 access section, "what Tenantial does not require" section, example timeline, buyer FAQ, and final CTA.
• FR-010: The hero and supporting copy MUST make safe evaluation and controlled pilot positioning clear without implying instant signup, automatic provisioning, or blind rollout.
• FR-011: The evaluation-path section MUST explain that Tenantial should be evaluated through clear scope, controlled review, and explicit next-step decisions rather than blind production introduction.
• FR-012: The page MUST make clear that Tenantial is not positioned as a helpdesk, admin-center replacement, PSA platform, or blind automation/remediation engine.

Preparation, Pilot Scope, Stakeholders, And Timeline

• FR-013: The preparation section MUST include use case, Microsoft 365 scope, technical owner, security/privacy contact, review objective, and success criteria.
• FR-014: The preparation copy MUST explain that evaluation does not require months of preparation but benefits from clear ownership, scope, and expected outcomes.
• FR-015: The pilot-scenario section MUST include MSP customer review, internal IT governance, policy backup/versioning, evidence/audit preparation, and provider-permission readiness examples.
• FR-016: Pilot-scenario copy MUST describe these as typical examples and MUST NOT imply that every scenario is fully automated or self-service today.
• FR-017: The stakeholder section MUST include MSP service owner, MSP operator or cloud engineer, IT leadership, Microsoft 365 admin, security, Datenschutz / DPO, and procurement or vendor management, with optional auditor or compliance involvement when relevant.
• FR-018: Stakeholder copy MUST explain what each role evaluates in buyer-facing language.
• FR-019: The timeline section MUST be framed as a cautious example and MUST NOT guarantee delivery or rollout duration.

Security, Procurement, And Microsoft 365 Access

• FR-020: The security/procurement section MUST cover trust/privacy posture, AVV/DPA/TOM status, provider permissions, hosting and subprocessors, audit/retention/export/delete posture where available, and commercial fit.
• FR-021: Trust, security, or procurement CTAs MAY link only to existing trust routes, contact routes, forms, or mailto destinations.
• FR-022: The Microsoft 365 access section MUST explain read-oriented access, write- or recovery-adjacent access, consent/admin-role readiness, and no-blind-execution positioning.
• FR-023: Access wording MUST explain that relevant permissions depend on pilot scope and MUST NOT list exact Microsoft Graph permissions unless separately verified as public source truth.
• FR-024: The page MUST explain that a productive tenant is not always required for a first conversation, but meaningful evaluation outcomes may still require a realistic Microsoft 365 context.
• FR-025: The page MUST explain that security, privacy, and procurement review happen through transparent discussion and status clarification rather than fake downloads, fake approvals, or fake self-service portals.

Boundaries And Buyer FAQ

• FR-026: The "what Tenantial does not require" section MUST include no big-bang rollout, no admin-center replacement, no helpdesk switch, no automatic remediation, and no fake compliance positioning.
• FR-027: The buyer FAQ MUST address productive-tenant expectations, scope-dependent permissions, AVV/DPA/TOM status, admin-center replacement, helpdesk or PSA status, automatic changes, provider scope, and compliance boundaries in direct buyer-friendly language.
• FR-028: FAQ and page copy MUST avoid legal, provider, security, or automation overclaim and MUST keep answers at the level of verified product truth.

Discovery, CTA, Metadata, And Claim Guardrails

• FR-029: Primary CTAs MAY include Demo buchen, Pilot anfragen, Security-Unterlagen anfragen, Trust & Datenschutz ansehen, and Plattform ansehen, but only when each target is a real destination.
• FR-030: Any unavailable CTA MUST be omitted or mapped to an existing real destination rather than faked.
• FR-031: The homepage MAY expose a compact evaluation teaser when the current homepage structure supports it without a heavy IA rewrite.
• FR-032: The platform page MAY expose a compact demo and pilot teaser when current structure supports it.
• FR-033: Trust, use-case, and review/evidence pages MAY crosslink to the evaluation page only when those routes exist as real destinations.
• FR-034: Navigation or footer MAY expose the page only where current IA supports it; the feature MUST NOT introduce placeholder dropdowns or a heavy navigation refactor solely for this page.
• FR-035: Page metadata MUST describe demo, pilot, security review, privacy questions, provider permissions, and rollout readiness in Microsoft 365 governance language for MSPs and enterprise IT buyers.
• FR-036: Visible copy and metadata MUST use strong but safe terms such as Tenantial evaluieren, Demo buchen, Pilot anfragen, Security Review, Datenschutzfragen, Provider-Berechtigungen, Technical Readiness Check, Pilot-Scope, Erfolgskriterien, Trust-Unterlagen, AVV/DPA/TOM-Status, and kontrollierter Rollout.
• FR-037: Visible copy and metadata MUST NOT use internal phrases such as procurement readiness website surface, productization gap, repo-real foundation, workspace-first route context, capability registry, provider-neutral artifact taxonomy, cutover guardrails, or implementation truth.
• FR-038: Visible copy and metadata MUST NOT claim instant trial, self-service onboarding availability, automated provisioning, DSGVO-konform, ISO-zertifiziert, NIS2-konform, in Deutschland gehostet, no customer data stored, Google/AWS support, automatic remediation, automatic restore, or one-click restore unless separately verified as current product truth.
• FR-039: The feature MUST NOT introduce fake downloadable documents, fake AVV/TOM files, fake security-pack downloads, fake calendar widgets, fake customer logos, fake case studies, or fake certifications.

Scope Safety

• FR-040: The implementation MUST preserve root workspace contracts, including existing root script names, the website package name, the WEBSITE_PORT convention, and the apps/* workspace convention.
• FR-041: The implementation MUST follow the current site language strategy and MUST NOT introduce a new localization foundation.
• FR-042: The implementation MUST NOT add onboarding runtime, CRM behavior, billing or trial provisioning, Microsoft consent runtime, Graph permission logic, or legal-document generation.
• FR-043: The implementation MUST record the exact validation commands and results used to verify the public website change.
• FR-044: The implementation close-out MUST explicitly confirm that changed application files are limited to apps/website/**.

UI Action Matrix (mandatory when Filament is changed)

N/A - no Filament Resource, RelationManager, or Page is changed by this feature.

Key Entities (include if feature involves data)

• Evaluation Readiness Page: A public buyer-facing page that explains how Tenantial is evaluated, reviewed internally, piloted, and prepared for controlled rollout.
• Evaluation Path: The buyer-facing sequence from first walkthrough or demo through scope clarification, security/privacy review, technical readiness, pilot, and next-step decision.
• Pilot Scope: The bounded combination of use case, Microsoft 365 context, stakeholder ownership, access readiness, and success criteria used to evaluate Tenantial safely.
• Trust Handoff: The buyer-facing explanation of which trust, privacy, AVV/DPA/TOM, hosting, and security questions are reviewed during evaluation.
• Stakeholder Set: The collection of commercial, technical, security, privacy, and procurement contacts that should participate in a meaningful evaluation.

Success Criteria (mandatory)

Measurable Outcomes

• SC-001: Structured internal copy-review notes record that a first-time MSP or enterprise IT evaluator can identify within 60 seconds how Tenantial moves from first demo to focused pilot and next-step decision.
• SC-002: Structured internal copy-review notes record that a security, Datenschutz, or procurement reviewer can identify within 90 seconds which questions, contacts, and trust topics belong in the evaluation.
• SC-003: Structured internal copy-review notes record that a technical owner can identify within 60 seconds that Microsoft 365 access depends on pilot scope and that blind automation or forced big-bang rollout is not being promised.
• SC-004: QA finds zero placeholder links or broken exposed routes across the new page and any homepage, platform, trust, use-case, review/evidence, navigation, or footer discovery points changed by this feature.
• SC-005: Static copy review finds zero occurrences of banned internal phrases, fake self-service or download claims, and unverified legal, provider, or automation claims on new or updated public surfaces created by this feature.
• SC-006: Desktop and mobile smoke review confirms that the page remains readable, keeps its primary CTA visible, explains the evaluation path and FAQ clearly, and shows no fake widgets or document-download affordances.