Document the technical evaluation process

fern/products/docs/docs.yml

@@ -10,6 +10,9 @@ navigation:
       - page: Self-service setup
         path: ./pages/getting-started/self-service-setup.mdx
         hidden: true
+      - page: Technical evaluation
+        path: ./pages/getting-started/technical-evaluation.mdx
+        hidden: true
       - page: Project structure
         path: ./pages/getting-started/project-structure.mdx
       - link: Customer showcase

fern/products/docs/pages/getting-started/technical-evaluation.mdx

@@ -0,0 +1,63 @@
+---
+title: Technical evaluation
+description: How a technical evaluation with the Fern team works, from the demo site through requirements review and approvals.
+---
+
+<Markdown src="/snippets/enterprise-plan.mdx"/>
+
+A technical evaluation is a guided trial of [Fern](/learn/docs/getting-started/capabilities) using your own content. It takes one to three weeks, giving your team time to publish real changes and see what Fern's outputs look and feel like before you commit.
+
+Your Fern account team runs the evaluation with you. Contact them with questions at any point during the process.
+
+## Evaluation stages
+
+| Stage | Outcome |
+| --- | --- |
+| 1. [Demo site](#demo-site) | Fern stands up a site with representative content, specs, and configuration. |
+| 2. [Hands-on access](#hands-on-access) | Your whole team can edit and publish docs directly. |
+| 3. [Requirements sheet](#requirements-sheet) | A shared, prioritized list of what your docs need. |
+| 4. [Requirements review](#requirements-sheet) | Fern matches the demo to the sheet and walks through it on a call. |
+| 5. [Stakeholder sessions](#stakeholder-sessions) | Each team sees how Fern fits their workflow. |
+| 6. [Approvals](#approvals) | Legal, security, and procurement reviews. |
+
+## Demo site
+
+Fern builds the demo site before the evaluation starts, using representative content from your existing docs, your API specs, and configuration close to what you would ship.
+
+To get the demo as close to your real site as possible, send your account team:
+
+- A content export from your existing docs
+- Your API specs
+- Brand assets like your logo, favicon, colors, and fonts
+
+Send further configuration requests as they come up: versions, products, additional branding, authentication, or anything else the demo needs to represent your real site.
+
+## Hands-on access
+
+Fern gives every participant access to the demo site so your team can go through the publishing flow rather than watch it. Both authoring paths are available:
+
+- Writers who don't use Git can edit and publish in [Fern Editor](/learn/docs/writing-content/fern-editor).
+- Engineers and writers who prefer Git can clone the repository and work locally against Fern's [project structure](/learn/docs/getting-started/project-structure). The [Docs quickstart](/learn/docs/getting-started/quickstart) covers the CLI, local previews, and publishing.
+
+## Requirements sheet
+
+Fern and your team build a shared requirements document, with each requirement prioritized as a must-have, should-have, or could-have.
+
+Alongside the requirements, agree on two or three success criteria tied to an outcome you care about, like reader activation, support ticket deflection, or engineering time saved on docs maintenance. That gives the evaluation a clear bar to clear rather than just a feature list.
+
+Fern then configures the demo site to match the sheet and presents it on a call, going through the requirements one by one so each is either checked off or has a clear path forward.
+
+## Stakeholder sessions
+
+Fern meets with the teams that touch your docs to discuss how Fern fits their existing flows and the outcomes they care about. Which teams join and what each session covers depends on what matters to you. The table below shows common examples:
+
+| Example team | Example topics |
+| --- | --- |
+| Engineering | [Spec syncing](/learn/api-definitions/openapi/sync-your-open-api-specification), [API Explorer](/learn/docs/api-references/api-explorer) configuration with [SDK snippets](/learn/docs/api-references/sdk-snippets) and [API key injection](/learn/docs/authentication/features/api-key-injection), and how Fern [reduces time to first API call](https://buildwithfern.com/customers/frame). |
+| Marketing | The [SEO, GEO](/learn/docs/seo/overview), and [agentic optimizations](/learn/docs/ai-features/overview) Fern provides to improve discoverability by both agents and humans. |
+| Support | Configuring [Ask Fern](/learn/docs/ai-features/ask-fern/overview) as the first line of support for your users. |
+| Technical writing | Automating docs maintenance with the [Fern Agent](/learn/docs/ai-features/fern-agent), driven by code changes, [user feedback](/learn/docs/customization/user-feedback), support tickets, and [analytics](/learn/docs/integrations/overview). |
+
+## Approvals
+
+Once the requirements are settled, Fern works with your legal, security, and procurement teams through their review processes. The [security overview](/learn/docs/security/overview) covers Fern's architecture, authentication model, and self-hosted options, which are the most common questions in a security review.