Repo path
website/05-site-message-architecture.md
Explains the sequencing of message, proof, and capability detail so the public story stays strategically sharp.
Repo path
website/05-site-message-architecture.md
Notes
No additional notes recorded.
Mapped workstreams
Mapped appendices
Raw source preview
Raw, unprocessed file text shown below.
--- title: GTM Website - Site Message Architecture status: active created: 2026-04-13 purpose: Canonical messaging spine for the live marketing site. --- # <un>peel Site Message Architecture ## Recommended message architecture ### Core promise Help enterprise insight teams answer faster, defend the work, and validate the answer against connected evidence. ### Primary pain The insight team loses relevance when the business wants answers faster and has more shortcuts than ever. The risk is not just poor methodology. It is that the team starts to look slow, difficult, or optional while everyone else finds a faster-looking route. ### Support points - Speed without cutting corners - Visible rigor that makes work easier to stand behind - Connected evidence that helps teams validate answers and stand behind them - AI that supports the researcher rather than replacing them ### Proof hierarchy Equal in architecture, staged in experience: 1. `Before` and `during` proof earns trust first - Research Guard - Trust Centre 2. After the study, connected evidence helps teams validate the answer - Insight Navigator - Cross-study support, retrieval, and connected project record ### Secondary framework `Confidence before / during / after` remains a useful public sub-frame, but it is not the top-level proposition. It explains how the platform works. It does not replace the business outcome. ### Anti-message rules - Do not lead with `Research OS` - Do not overclaim certainty - Do not imply AI replaces the researcher - Do not open with broad suite language before trust is earned - Do not make the site sound like a generic AI platform with research attached ## Page role matrix ### Homepage Top-funnel strategic page. - Lead with team relevance earned through trust - Name the business-speed problem clearly - Earn credibility through early proof - Show enough breadth to feel real without sounding like a feature sprawl ### Pricing page Commercial expression of the same promise. - Show that pricing scales with workflow scope, trust infrastructure, and organizational reach - Keep the commercial model tied to the proposition - Avoid a detached pricing-table feel ### Product pages Mid-funnel evaluator pages. - Answer: what does this product do, when should a team use it, and how does it help the team stay trusted and useful? - Stay product-led - Connect each product to the wider proposition without repeating the homepage word-for-word ### Capability pages Mid-funnel proof pages. - Answer: why should a buyer trust this approach? - Stay evidence-led and specific - Deepen belief in the homepage promise instead of creating a new story ### Company and legal pages Credibility scaffolding. - Provide basic vendor context during the pilot phase - Reduce trust friction without pretending unfinished material is complete - Stay factual and lightweight until fuller company details are ready ## Open decisions See `06-decision-register.md` for messaging questions that are intentionally still open. See `09-pre-launch-checklist.md` for operational items that are intentionally deferred until later. ## Backup proposition routes These are viable alternatives, but not the recommended lead. ### Route 1 - Fast without compromise Emphasize moving at business speed without letting the work get sloppy. ### Route 2 - Proof over shortcuts Emphasize making the difference between real research and faster-looking shortcuts visible. ### Route 3 - Team relevance first Emphasize the insight team's position in the organization, with trust as the mechanism. ## Rewrite blueprint ### Keep - Researcher-in-control AI framing - Specific proof over vague quality claims - Design / Protect / Validate as the lower-page operating frame - The distinction between product pages and capability pages ### Change - Replace `indispensable`-style abstraction with a clearer business outcome - Move away from suite-first language on the homepage - Tighten proof around the strongest present-day capabilities - Make pricing feel like part of the same argument as the rest of the site ### Cut or reduce - Anything that implies breadth before proof - Claims that depend too heavily on future-state capability - Detached audience-page positioning - Child-page copy that sounds like it came from a different company than the homepage