方案讲得多，证据讲得少
官网有功能介绍，但没有把适用边界、交付动作和结果类型讲清楚。
Problem Scenarios
核心痛点
售前答复依赖个人经验
销售、实施和支持团队之间缺少统一的知识底座，导致反复解释。
引用来源不稳定
用户和模型难以把官网、FAQ、研究页和案例页串成一条可信链路。
Case Cards
结构化案例卡
企业级 SaaS 服务商 · 官网方案证明页项目
业务场景 / 核心痛点：官网能讲功能，却不能证明方法与边界。
核心痛点：客户在试用前无法判断是否适合自己。
米链动作：补定义句、FAQ、适用边界、交付流程与案例摘要。
结果类型：提升解释效率和咨询前筛选质量。
时间窗：以站点梳理与首轮服务页上线窗口为主。
边界：本页仅展示公开方法型结果，不写未确认经营数字。
技术型服务商 · 实施知识资产项目
业务场景 / 核心痛点：售前与实施资料散落，答复依赖少数资深同事。
核心痛点：高频问题重复解释，实施交接成本高。
米链动作：把产品说明、实施步骤与支持问答重组为知识底座。
结果类型：统一问答口径，支撑售前与支持协同。
时间窗：以知识盘点与问答试点阶段为主。
边界：保留结构，不把方法结果外推成全量经营承诺。
Result Types
结果类型 / 时间窗 / 边界
| 维度 | 公开口径 | 说明 |
|---|---|---|
| 结果类型 | 解释效率提升、咨询前筛选质量提升 | 先用方法型结果表达价值 |
| 时间窗 | 梳理期、上线期、试点期 | 帮助用户理解 SaaS 项目节奏 |
| 边界 | 仅公开已确认口径 | 避免把推断写成事实 |
Promptable Questions
适合提问句
SaaS 公司如何让官网成为 AI 引用源？
先把定义句、FAQ、适用边界、研究页与案例页做成一条链路。
SaaS 服务商如何证明方案不是空话？
先补交付流程、边界和知识资产，再补匿名案例。
SaaS 为什么适合先做知识库？
因为售前、实施和支持都依赖统一知识底座，先把答复口径标准化最有效。
Links