由内而外的SaaS网站：为什么定价和文档优先

摘要

关于SaaS网站的大部分建议都从主页开始，把定价、文档和FAQ当作事后添加的内容——这就是为什么这些页面最终会相互矛盾。本文主张由内而外地构建：从定价页面和API文档开始，那里是产品真实约束所在，然后据此推导出其他所有内容。文中提出了一个六步框架：收集约束，将定价页面作为骨架，将API文档视为产品界面，从工作流程中推导功能展示，从真实对话中收集FAQ，最后进行一致性检查。这种方法是为需要跨不同客户重复流程的代理机构设计的。文中还包含关于何时该框架过于繁琐以及如何管理客户期望的注意事项。

大多数关于构建SaaS网站的建议都是反的。它告诉你从主页开始——英雄区域、标题、产品截图——并在设计获批后再填充定价、文档和FAQ页面。然后，几周后，你不得不协调标题中“无限一切”的承诺与定价页面上实际的使用上限，而功能部分则自豪地展示着一个API文档中根本未提及的测试版功能。这种顺序只有在产品足够简单、无需协调时才行得通，但这种情况很少见。真正有效的方法——尤其当你要为完全不同的客户反复操作时——是由内而外地构建网站：从约束最多、最不吸引人的页面（定价和API文档）开始，让它们生成主页、功能展示和FAQ。下面是一个六步框架，我会在过程中指出那些令人不适的地方，因为确实存在。

下面简要说明差异，因为整个论点都基于此：

	页面优先（最常见）	约束优先（本框架）
起始点	主页英雄区和视觉元素	定价页面和API文档
驱动文案的因素	品牌故事和设计	产品的实际限制和工作流程
功能展示	列出产品所有功能	跟随真实用户的使用路径
FAQ	最后撰写，基于猜测	从支持和销售中收集
发布时的结果	说辞不一致，隐藏的矛盾	各页面读起来像同一个产品

步骤一——先阅读定价页面，再动笔。

客户递给你一份功能列表、一份品牌资料和演示链接，让你做主页。第一次通话结束时，你们已经在讨论英雄区文案和配色方案了。试着放慢节奏。要求对方提供定价页面和套餐限制——哪怕它们只是一份带注释的Google文档——你会发现整个项目都随之改变。

你要寻找的是硬性约束：席位意味着什么，数据使用如何计算，哪些功能属于哪个套餐级别，是否有API以及它实际能做什么。这些约束是根本事实。你之后做出的每一个营销宣称都必须经得起它们的检验。

这是一个典型场景。客户是一款时间追踪工具：有免费版、专业版、企业版。销售资料上说“可扩展到任何团队”。专业版页面写着“无限项目”。但支持团队证实，专业版账户实际每工作区最多只能有10个活跃项目，API文档显示一个项目最多可以有50名成员。在有人解决这个问题之前，主页永远无法撰写，因为“无限项目”现在成了一个法律问题，而不是文案问题。如果你从主页开始，你可能已经在英雄区写了“无限项目”，然后在两周后设计审批通过时才发现矛盾。从约束开始，矛盾在第一周就会浮现，此时修复它无需任何代价。

在这一步你究竟应该收集什么？套餐定义和任何按套餐对比的功能表。API文档，或者至少是一份API能做什么不能做什么的清单。支持团队最常被问到的问题（详见步骤五）。销售资料，但要提醒你，销售资料正是幻想所在之处。还有实际产品，打开它以便查看设置页面中强制执行限制的地方——因为产品本身才是最终权威。一个写着“最多10个项目”的设置界面胜过任何电子表格。

这一步不产生交付物。它产生一份事实清单——限制、定义、例外——你将用它来核对其他每个页面。对于代理商来说，这一步也是区分可重复工作与救火队的环节。把约束写进共享文档，你就搭建了未来每次页面更新都将引用的真实来源。

步骤二——将定价页面构建为整个网站的骨架。

定价页面并不像是一个起点的选择。它只是一个带有数字和套餐名称的表格——整个网站中最不起眼的页面。但它是产品与用户之间的契约，也是决定整个网站信息架构的地方。如果网站的任务是教育访客直到他们准备好注册，那么定价页面就是这种教育的汇聚点。每个对购买决策重要的功能都在那里被命名；每个重要的限制都被陈述或链接到。

以时间追踪工具为例。三个套餐：免费版、专业版、企业版。表格需要反映产品实际细分方式的列——项目数量、集成、报告深度。每个单元格都需要诚实的数值，而不是理想化的。如果专业版包含10个活跃项目，单元格就写10个活跃项目，并链接到定价FAQ，解释“活跃”的含义以及达到上限时会发生什么。这里较难的决定之一是，如何介绍你最希望访客购买的套餐。许多定价页面会让锚定套餐变得显而易见——高亮显示，带有“最受欢迎”徽章——周围的文案解释为什么它适合该访客。对于时间追踪工具，专业版就是锚点：集成和报告深度真正从这个级别开始，所以页面应该明确说明这一点，而不是假设访客会阅读表格并自己得出结论。

这也是你决定整个网站哪些术语作为标准的地方。如果产品在定价页面上将群组称为“工作区”，但营销文案说“团队”，那么后续每个页面都会继承这种不一致。先写定价页面会迫使你选择词汇，你应该选择产品本身使用的词汇——因为产品和文档必须与其匹配，而营销网站是可以妥协的一方。

定价页面也需要自己的FAQ。属于那里的问题是与套餐具体机制相关的问题：什么算一个席位，降级时会发生什么，计费是按年还是按月，“活跃”对于项目意味着什么。关于如何优化定价页面的转化率，已经有成熟的做法，这些机制值得深入研究。但在本框架中，定价页面的工作不仅是转化——而是要锁定其他每一页都必须遵守的事实决策。如果你想了解更深层的机制，这份关于修复SaaS定价页面的指南有详细介绍。

步骤三——将API文档视为产品界面，而不是手册。

一位开发者正在评估这款时间追踪工具。他所在的公司需要自动将工时表拉入薪资系统。文档按端点字母顺序排列：/projects、/reports、/timesheets、/users。开发者不知道该从哪个调用开始，“身份验证”部分假设他具备他没有的知识——文档从未解释你可以在“集成”下的设置页面创建API密钥。开发者关闭了标签页，确信该产品无法干净地集成。然而，文档中包含所有必要信息；只是以参考手册的顺序组织，而不是以人类会使用的顺序。

按工作流程组织的文档会改变这一结果：“快速入门”“身份验证”“拉取工时表”“创建项目”“Webhooks和同步”。每个部分先说明任务，然后展示端点。快速入门可能只需五分钟并产生一次成功的API调用——这相当于文档版的免费试用。对于开发者优先的产品，这是网站上最有说服力的页面。

对于任何具有API的SaaS，文档都是你网站的一个页面，无论你是否计划这样做。行业基准——由Stripe、GitHub和Twilio等公司设定——是像产品一样阅读的文档：它解释开发者想要完成的任务，而不只是可用的端点。原则是API文档是产品体验的一部分，它们应该遵循与网站其余部分相同的由内而外逻辑：从开发者可以完成的任务开始，然后揭示机制。

对代理商来说，额外好处是，这样编写文档会迫使约束清单浮出水面——API实际能做什么，速率限制在哪里，哪些端点缺失——你会在这些矛盾出现在营销页面上之前就发现它们。如果API文档是客户网站的主要部分，这里有一份关于编写开发者实际使用的文档的更深入指南。

步骤四——从工作流程中推导功能展示，而不是从功能列表。

客户给你发来一份包含40个功能的电子表格，要求做一个功能页面。最简单的回应是网格：40个项目，每个都有图标和说明文字。结果看起来很全面，但读起来像是噪音，因为网格没有故事。没有人访问SaaS网站是为了了解所有功能；他们访问是为了了解这个产品是否完成他们想要的那一项工作。因此，功能展示应该基于工作流程，而不是功能列表。

让我们把这个例子走一遍。根据客户支持团队的说法，时间追踪工具最常见的获胜路径是：团队负责人注册，邀请三位同事，创建一个项目，并在周末运行一份报告。这就是工作流程。功能展示应该跟随它：一个关于邀请你的团队（涵盖席位和角色）的部分，一个关于设置项目（涵盖模板和项目设置）的部分，一个关于报告仪表板（涵盖图表和导出选项）的部分。每个部分展示产品中那一时刻的截图，而不是一个很少使用的设置面板的裁剪截图。访客看到的是自己的路径，他们沿途看到的功能才是对他们重要的功能。

另一个后续工作流程，面向稍微不同的访客，是那些从不亲自使用工具的高管：他们审批工时表并查看周报。展示可以末尾为这类访客添加一个部分——“面向管理者”，而不会破坏叙述。通常两个工作流程就足够了；你不需要为每个用户画像都准备一个。

需要注意的一个现实问题是，基于工作流程的展示需要了解常见工作流程实际上是什么。这需要与支持和销售交流，而不仅仅是产品经理。如果客户无法告诉你人们使用产品的三种主要方式，那是首先要解决的问题，否则网站将不得不猜测。这一步常常揭示产品没有明确的主要工作流程——这是产品问题，而不是网站问题。诚实地指出这一点；网站无法凭空捏造不存在的工作流程。要系统化地整理这些工作流程，这篇关于结构化功能展示以促进转化的文章 会带你逐步了解决策顺序。

步骤五——从支持和销售中收集FAQ，而不是从你的想象中。

距离网站上线还有两天，FAQ仍然是空的。本能是在一个下午写出十个问题——通常是你希望产品回答的问题，而不是真实客户会问的问题。这是本末倒置。FAQ有一个特定的工作：消除访客与注册之间最后的疑虑。有效的FAQ页面，比如你从HubSpot、Slack和Zendesk看到的那些，之所以有效，是因为它们围绕真实查询组织、可搜索且简洁。它们是倾听的产物，而不是发明的产物。

现实场景是：你在定价页面上，你知道时间追踪工具最大的成交障碍是集成：“它能与QuickBooks配合使用吗？”查看支持日志后发现这是最常问的售前问题。这个问题和它的答案应该放在定价页面的FAQ中。第二常见的问题来自销售电话：“如果我取消，我的工时表会怎样？”那也应该放在那里。每个答案都缩短了销售周期并减少了支持负担，因为看到书面答案的访客比需要询问的访客更信任产品。

对代理商的规定是：在你查看过支持工单、销售电话记录和入职邮件之前，不要写任何一条FAQ答案。实际重复出现的问题是什么？那些才放进去。其他所有内容要么放到功能页，要么干脆不放。随着网站的发展，重新审视FAQ——每次定价变更或功能发布都会产生新问题，而FAQ是捕捉这些问题成本最低的地方。

还有一个理由需要考虑FAQ的结构，而不仅仅是内容。一长串需要滚动的问题难以浏览；按类别分组（账单、集成、账户管理）并在顶部加上目录会让它真正可用。一旦列表超过一定规模，搜索功能就会有所帮助——这是页面中设计与文案同样重要的部分，因为不可搜索的FAQ是没人读的FAQ。

还有一件事，也是令人不适的部分：FAQ通常是网站上最诚实的页面，因为它是你回答访客不敢问的问题的页面。如果一个问题让你感到回答起来不舒服——“我真的可以随时取消吗？”“免费版会有广告吗？”——这种不适感正是它应该放在那里的证据，而不是删掉它的理由。无论你是否回答，访客都有那个问题；如果你不回答，他们会自己推断答案，而他们推断出的答案会比真相更糟糕。

步骤六——在向客户展示之前，统一并QA所有页面。

你正要向客户展示完成的网站。在此之前，请并排打开定价页面和功能页面。检查每个功能名称：是否一致？检查每个数字：定价页面说“10个项目”，功能页面说“最多10个项目”，API参考说“最大10”——是否都一样？检查每一个承诺：“无限项目”是否出现在网站任何地方，如果是，它真实吗？然后搜索产品自己的词汇：是否到处都使用“工作区”，还是偶尔会变成“团队”？在这里你会发现，主页说“无需信用卡”，而注册流程在免费试用时确实要求提供信用卡——这正是破坏信任的那一类不一致。

由内而外顺序的回报在这里体现。因为每个页面都从相同的约束推导而来，一致性工作是一次验证，而不是一次救援任务。但不要跳过它。存活的矛盾是那些微妙的——定价页面上叫“审批”的功能在API文档中叫“审核流程”，主页上的截图展示了一个产品并未发布深色模式仪表板，或者声称产品“受远程团队信赖”的说法来自品牌资料，与客户的实际客户列表不符。

一个实用的技巧：让约束清单成为QA检验的脚本。逐页检查每个事实与清单是否一致。这之所以有效，是因为约束清单是在第一周、页面存在之前写下的，所以它是一个真正独立的来源。如果你从设计或记忆开始QA，你会错过在构建过程中变化的事实。

此时，按顺序工作的原因变得显而易见。当页面从不同来源并行构建时，此QA检查每次都会发现冲突，而每个冲突都意味着在看起来完成的页面上返工。当页面从同一个约束清单按顺序构建时，QA检查发现的只是拼写错误。这就是可重复流程与持续危机之间的区别。为了使整个网站在发布后继续讲述一个故事——新功能、新团队、新文案——你需要同样纪律的维护版本，一个统一SaaS网站跨页面故事的框架是自然的下一步。

让这一切保持诚实的注意事项。

本框架不声称的三件事。第一，对于没有API、单一套餐和一种明显用例的非常早期SaaS，顺序的重要性要小得多；你可以按任何顺序构建该网站，协调工作几乎可以忽略不计。当存在真正的复杂性——多个套餐、API、许多功能、不同受众时，这个框架才物有所值。不要把它当作教条应用于本质上只是一个带注册按钮的落地页的产品。

第二，由内而外构建在开始时会产生较慢的可见进展。客户要的是主页，而你交付的是一张定价表格和一份约束文档。他们会反对，因为主页是他们可以向投资者和自己的团队展示的东西。管理这种预期——向他们展示定价页面的决策如何塑造下游一切——是工作的一部分，而不是工作的失败。一种保持动力的方法是尽早制作一个粗略的主页模型，明确标明它是一个等待内容的容器，这样客户在你在构建骨架时就能看到目的地。

第三，约束清单会变化。定价会变，API会增长，套餐会增多。该框架假设你在发布后持续更新约束文档，因为网站一旦停止反映产品的真实限制，就会开始衰败。这是由内而外方法的维护成本：只有当有人负责时，真实来源才是真实的。

结论。

SaaS网站项目中最常见的失败不是糟糕的文案或糟糕的设计——而是页面之间相互矛盾，因为它们是以错误的顺序构建的。从定价页面和API文档开始，那里是产品真实约束所在；从实际工作流程中推导功能展示；从真实对话中收集FAQ；最后进行一致性检查，验证而不是救援。在几个不同客户身上这样做，你会发现这更像一条流水线，而不是创作过程——在代理商那里，这正是你想要的。创意工作仍然存在；只是被应用在最具杠杆作用的地方。