“行业词＋公司名”可以描述业务，却未必能代表客户的实际困惑。客户更可能问：这种方案适不适合我的情况？实施前要准备什么？遇到某种限制怎么办？本文建议先收集这些具体问法，再决定需要补充哪些页面。
从已经发生的沟通中找问题
可以请销售、客服、产品和交付同事分别回忆最近的沟通，提取客户实际使用的句子。尽量保留原意，不急着改成专业术语。涉及客户身份与项目细节时，先去除可识别信息；无法获得使用许可的材料，不进入公开内容。
再查看官网站内搜索、现有文章留言，以及企业已经有权限查看的搜索表现数据。这些来源提供的是不同场景的线索，不能把内部出现次数直接当成整个市场的搜索量。
一张问题卡，至少保留五项信息
- 原始问题：客户具体怎样问，而不是运营人员概括的关键词。
- 使用场景：首次了解、方案比较、实施准备，还是使用中遇到问题。
- 需要完成的判断：读者看完后应能决定什么。
- 现有答案与依据：已有页面、业务资料，以及仍需确认的部分。
- 责任人和状态：由谁补资料、谁审核，当前是待核实还是可写作。
例如“系统能不能接入现有流程”，还需要追问现有流程的边界、数据来源和必要条件。这里是问题拆解示例，不代表任何 YESGEO 客户项目或产品能力。
合并重复问法，但保留不同条件
“怎么开始”和“第一步做什么”可能属于同一问题；“小团队怎么开始”和“多部门企业怎么开始”则可能需要不同回答。合并时要看读者要做的决定是否一致，不能仅靠句子相似度。
本文建议用三个条件安排优先级：业务是否能给出可靠答案、问题是否影响客户决策、当前页面是否存在明显缺口。暂时没有证据的选题先补材料，不为了覆盖词语而匆忙发布。
把问题清单变成内容任务
- 为一个核心问题指定一个主要页面，写明该页需要回答的范围。
- 把有关联的追问放入页面结构，避免拆出许多重复短文。
- 为每个判断准备依据、适用条件和下一步行动说明。
- 请未参与写作的同事阅读，看他能否复述答案并指出仍不清楚的地方。
Google 的内容质量自查强调内容是否帮助既定读者完成目标。官方自查问题可以作为审核参考，但不是题库评分规则。问题清单的价值在于帮助团队持续发现信息缺口，而不是制造一张必须全部发文的关键词表。