SaaS常见问题页面是机构忽视的转化主力

摘要

大多数SaaS常见问题页面都是基于支持工单构建的，这意味着它们回答的是已经购买用户的问题，而忽略了阻止潜在客户购买的异议。本文将常见问题从发布后的附注转变为销售资产。本文面向为多个客户构建网站的机构，涵盖了一个可重复的流程：收集销售团队的异议，按购买阶段分组问题，写出足够完整以结束搜索的答案，将每个异议与特定的社会证明配对，并按季度节奏维护页面。神话与现实的对比格式展示了什么真正有效，每个部分都有实际示例。结果是，常见问题页面既能减少支持负担，又能提高潜在客户注册的可能性。

关于SaaS常见问题页面的大多数建议都从错误的地方开始。它们被视为发布后的清理工作——一个存放支持工单答案的地方，以便支持团队不再重复。正是这种定位导致您客户的常见问题页面几乎对企业毫无作用。真正有效的方式是：常见问题页面是潜在客户在已经决定可能购买后访问的少数几个页面之一。它是一个决策阶段的页面，而不是文档页面。它应该旨在消除访客与注册之间的异议，并应获得与定价页面相同的战略关注。

如果您在机构工作，问题更为尖锐。每个客户都不同：不同的产品、不同的买家、不同的支持历史。然而，您必须在每次都不从零开始的情况下产出有效的内容。诱惑是复制您上次构建的常见问题的结构。这在有效之后可能会失效，因为对金融科技客户重要的异议与团队协作客户不同。框架必须相同；内容必须不同。下面对神话的破除就是该框架。下面的模式很简单：期望常见问题能够销售，而不仅仅是告知。这改变了您收集问题、分组、回答长度以及在其旁边放置内容的方式。

从销售开始，而不是支持工单

首先，向您客户的销售团队询问最近五个停滞的交易。停滞这些交易的问题就是您常见问题页面应回答的前十个问题。大多数常见问题页面是由支持工单构建的——来自已购买用户的问题。真正阻碍销售的问题来自尚未购买的用户，它们往往涉及迁移、安全、定价以及试用结束后会发生什么。

实践中的情况如下。一个工作流自动化客户带着一个充满诸如“如何重置密码？”和“支持哪些浏览器？”等问题的常见问题来找我们。该页面在技术上是有用的，但在商业上是惰性的。于是我们询问销售团队在失败的交易中听到了什么。结果发现，潜在客户在询问该工具是否能取代他们当前的电子表格、迁移是否需要IT部门，以及销售人员的价格表是否与实际计费费用一致。我们围绕这三个异议重建了常见问题，每个都有简短答案和指向相关页面的链接。密码重置问题移到了支持中心。该页面变成了一个成交工具，而不是帮助台。

当您进行这种访谈时，不要满足于“他们询问定价”。要求确切的措辞。“定价是按用户还是按工作区？”是可行的问题。“他们询问定价”则不是。还要询问竞争对手做了什么客户难以匹敌的事情——这通常会浮出销售团队听腻了的异议。将这些放在页面最顶部。

这是从内到外构建SaaS网站获益的地方：您从真实买家提出的问题开始，然后围绕这些问题构建网站。需要注意的是，您不能完全跳过支持问题。有些访客是现有客户。但页面的黄金位置应给予购买前出现的问题，而不是购买后的。如果您需要在页面上保留一些支持问题，请将它们移到最底部，并加上明确标注的“现有客户”标题。这样，您就可以在不让支持问题主导的情况下服务两个受众。运行访谈的一个有用方法是向销售团队发送一个简单提示：列出上个月潜在客户提出的每个问题，而这些问题您必须手动回答。您将得到两个列表。需要判断的问题属于常见问题素材；可以用链接回答的问题属于文档。

长度并不等于详尽

值得坚持的原则是位置相关性。试用三分钟的访客与评估工具采购官员的问题不同。如果常见问题是一个字母排序的列表，采购官员必须从“如何更改我的头像？”中筛选出“你们如何处理数据驻留？”大多数访客不会这样做。他们会离开。

一个项目管理SaaS客户有一个按字母排序、长达数页的常见问题。我们将其重新分为四个类别：“开始之前”（它是什么、如何比较）、“试用期间”（设置、限制）、“购买”（定价、发票、安全审查）和“购买后”（账单变更、支持）。购买类别放在第一位，因为这是资金流失的地方。字数没有太大变化，但页面从列表变成了引导路径。

在每个类别中，使用两种排序规则之一。如果产品有清晰的购买方式，则按严重性排序：直接阻止交易的问题放在首位。如果产品没有明显的顺序，则按频率排序——但仅限于类别内部，而不是整个页面。重要的是，访客无需阅读所有内容就能找到他们关心的问题。在页面顶部使用锚点链接，以便采购官员可以直接跳转到“购买”，试用用户跳转到“试用期间”。在典型的SaaS网站上，这两个群体产生的注册和流失交易最多，因此他们在页面顶部。

对于定价问题，您会应用于为转化而构建的定价页面的相同逻辑也适用于常见问题内部：先放与决策相关的细节，然后是理由，然后是链接。不要让访客寻找他们想要计划的价格。在购买类别中，再考虑顺序。将安全性和合规性放在支付方式之前，因为安全审查通常是阻止评估的守门人，在支付问题出现之前。

神话	现实
常见问题是用来回答问题的	常见问题是用来消除购买异议的
更长的常见问题意味着更详尽	可扫描、分组的常见问题优于长列表
答案应该简短	答案应该足够完整以结束搜索
社会证明只属于首页	放在异议旁边的证明转化效果更好
常见问题是发布交付物	常见问题是带审查节奏的活文档

过短答案的代价

这是当客户对“长”答案提出异议时我们使用的前后对比。

之前：“你们支持SSO吗？我们是支持的。”

之后：“SSO在Pro及以上计划中可用。一旦您是工作区所有者，就可以从设置 > 安全中启用。这里有一个分步指南。如果您的团队使用Okta或Azure AD，两者都受支持。”

第二个答案更长，但它也是最终的。访客停止搜索是因为答案预见了后续问题。这样写作看起来简单，但需要知道后续问题到底是什么。最简单的找到它们的方法是查看每个功能区域的顶级支持工单，并将答案合并到常见问题中。

要使用的结构是：直接回答，一句背景，然后一个链接。将直接回答加粗，以便快速浏览者立即看到。如果有截图，请将其放在背景之后，而不是之前。不要将答案埋在描述功能的段落中。这也是使Stripe和Twilio等公司的API文档脱颖而出的原则：您可以到达、获得答案、然后离开。我们在编写开发人员实际使用的SaaS API文档指南中更深入地探讨了这一标准。需要注意的是，“完整”并不意味着“为长而长”。文字墙仍然是一堵文字墙。

还有一个语气问题。过短的答案往往听起来简短甚至粗鲁；过长的答案听起来防守。最佳点是一个称职的支持人员会在电子邮件中给出的答案：直接回应、简短解释和下一步。如果您客户的支持团队写有用的电子邮件，请索要几封并将其用作模型。如果没有，您可以自己写模型，让支持团队纠正。这也是获得支持团队支持的好方法，因为常见问题开始看起来像他们最好的电子邮件，而不是公司文件。

将异议与证明配对

对您客户常见问题上的每一个异议，问一个问题：哪一条社会证明可以化解这一点？一个电子签名客户在首页上有一个强有力的推荐部分。但当我们查看常见问题中的安全问题——“你们如何保护我的文档安全？”——答案却是枯燥的合规语言。来自法律团队的首页推荐语“我们的合规团队在一天内批准了他们”正是该答案所需的保证。

我们开始将每个异议与一条证明配对：安全问题得到了合规推荐，定价问题得到了来自从竞争对手转换的客户的引言，迁移问题得到了一行关于一位客户在不停机的情况下转移了整个公司的文字。常见问题不再是一个单独的页面，而是成为推销的一部分。

这里的注意事项是相关性。靠近常见问题的标志墙几乎没有什么作用；直接针对异议的推荐才具有分量，尤其是在说明给予推荐的人的角色时。如果您客户还没有这种证明，开始从产生异议的同一销售电话中收集。这两种资产来自同一来源。当您获得推荐时，提取一个与常见问题问题匹配的子句。您不需要完整的引言；一个具体的句子就足够了。请销售团队在交易结束时注意客户是否提了特定顾虑。该顾虑是未来的常见问题问题，客户自己的话是其最佳答案。

还有第二种不太明显的证明形式：产品证据。如果潜在客户询问“我能导出数据吗？”最有力的答案包括导出屏幕的截图，而不仅仅是一句“可以”。如果他们询问“试用期有多长？”最有力的答案包括关于试用期结束时会发生什么的说明。截图和短视频在这里有效，因为它们展示而非声称。这也是常见问题与功能展示连接的地方：像“这与电子表格有什么不同？”这样的问题应该链接到展示差异的网站部分，而不是一堵比较文字墙。

常见问题是一个流程，而不是发布交付物

对机构而言，持久的原则是常见问题页面是一个流程，而不是一个页面。客户的产品每月都在变化；每次定价变化、每个新竞争对手、每个季度都会出现新的异议。您在1月推出的页面到3月就成了猜测。使这项工作可重复的机构会在参与过程中建立轻量级的维护节奏。

发布后，设置季度审查，查看三个输入：新的支持工单、销售电话中的问题和产品变更。将审查分为两步。首先，删除不再重要的问题。其次，添加过去90天内出现的问题。您不需要内容策略师。您需要一个习惯。

我们通过对一个客户实施这一点，让支持负责人标记任何网站本可以回答的工单。几个季度后，支持负责人在我们询问之前开始向我们发送重复问题的列表。常见问题成为一个共享项目，这是它保持相关性的唯一方式。对于在多个项目中开展此类工作的任何机构，将常见问题视为可重复的SaaS网站系统的一部分，是保持质量一致而不每次重新发明过程的方式。

审查不需要超过一小时。支持工单十五分钟，销售问题十五分钟，产品变更十五分钟，更新页面十五分钟。如果您为内容维护计费，它就成为经常性收入来源。如果不计费，它能使页面不会老化。有一个值得关注的指标，即使您无法设置硬性数字：支持团队是否报告更少的相同问题。当支持团队停止回答现在已在常见问题上的问题时，这是一个胜利，并且通常在仪表板显示之前就能从团队的语气中看到。当支持团队开始建议新的常见问题条目时，您就知道维护过程已经扎根。

这些都不需要重新设计或新工具。它需要的是您与客户谈论常见问题方式的转变。在项目计划中停止称其为“常见问题”，开始称其为“异议页面”。这一改变将重塑后续的每一个决策，从您收集的问题到您写的答案。它还将更轻松地说明维护页面的理由，因为没有客户会否认需要不断消除异议。