把一个B2B需求组织成关键词、广告和落地页，核心不是在后台建一个“计划”或“单元”，而是建立一个可以从客户问题追到业务结果的需求单元。这个单元要说明服务谁、解决什么、企业能提供什么，再把搜索表达、账户设置、广告承诺、页面答案、CTA和来源记录连在一起。
赵岩课件提出按推土机、挖掘机等真实业务需求组织推广后台，而不是只按疑问词、肯定词或词长分类。这样做的目的不是规定唯一账户结构，而是让花费、搜索、页面与结果能够分别回到业务，支持开关、预算和优化判断。
先写需求卡，再打开广告后台
需求卡第一行写目标客户与工作场景。例如教学设定：有多个销售团队的企业，希望统一线索跟进记录。第二行写客户要完成的任务：了解需要哪些字段、怎样交接、是否需要系统支持。第三行写企业真实可提供的内容或服务。第四行写本轮不承接的对象和承诺。
再列证据来源：产品资料、官网页面、销售沟通、常见问题和已核验案例。不能确认的功能标记待核实，不让投放人员根据关键词自行发明产品能力。需求卡由业务、内容和销售共同确认，广告账户只是执行载体。
如果一句话无法说明这组需求，说明范围可能太宽。把“企业数字化”缩到“多人线索记录怎样统一”，更容易设计连续内容，也更容易解释测试结果。
收集搜索表达并按任务归类
初始表达可以来自客户原话、销售记录、官网站内搜索、搜索平台查询建议和既有广告搜索词。来源不同，可信程度也不同；所有表达都只是候选，不等于客户量或采购意图。
将表达按任务归类：正在寻找产品类别、解决具体问题、比较供应商、了解实施准备、学习通用方法，以及明显不属于服务范围。分类要保留原句和理由，不能只复制一份行业词库。
同一个词可能处于不同任务中，需结合完整句子。量很少时，不要切得过碎；意图明显不同又需要不同页面和后端标准时，不要为了方便混在一起。
关键词和广告怎样围绕同一承诺
从候选表达中选择本轮能够承接的关键词，并记录匹配范围、对应页面和排除边界。平台功能会变化，具体设置以当前官方说明为准。这里的长期原则是：关键词选择必须有业务理由，上线后必须回看真实搜索词。
广告写成准确预告。标题说明正在回应的问题，说明文字补充对象、内容或过程，避免未经证实的第一、免费、保证和倍数效果。广告不是把所有卖点塞进有限位置，而是帮助不适合的人在点击前退出，也帮助适合的人形成正确预期。
可以准备少量版本验证表达，但每个版本仍要指向同一事实。若一个版本强调方法、另一个承诺产品结果，它们已经是两个假设，不宜混作单纯文案测试。
落地页怎样兑现需求组
页面第一屏回答适合谁、处理什么问题、提供什么；随后解释概念、过程、所需资料、能力与不适合边界，用经过授权的证据或明确标注的教学示例帮助理解。页面最后给与当前阶段相符的下一步。
产品评估页可以连接功能、实施、案例和咨询；方法学习页应先给完整方法，再自然连接产品或服务。用“免费资料”吸引点击却没有对应资源，或用产品词把人带到公司新闻，都会破坏连续性。
页面还需有唯一URL、清晰标题与描述、正确Canonical、移动端可读、加载正常和可用表单。技术规则不会替代内容，但页面打不开会让内容价值归零。
CTA、表单与销售承接怎样进入设计
CTA不是页面装饰。它要告诉客户下一步会发生什么：阅读产品说明、查看适用条件、预约交流或提交具体问题。表单只收本次处理需要的信息，并说明用途；字段越多不一定质量越高，过少也可能让承接人无法判断。
提交后要确认成功、保留来源并通知负责人。CRM至少能看到联系人、企业、客户原话、需求组、关键词或活动标识、落地页、时间和处理状态。自动字段与销售人工判断分开，不能让人工覆盖原始来源。
市场与销售提前约定有效需求、接收时限和退回原因。没有后端反馈，投放只能优化容易提交的人，无法知道哪些搜索真正相关。
怎样用一张表验收需求单元
验收表可以设置六列：客户任务、搜索表达与关键词、广告信息、页面答案、CTA与表单、业务记录。每行用一个具体表达走完整链路。若任何一列只能写“通用公司介绍”或“待上线后再说”，就说明单元尚未准备好。
再做三种测试：相关客户能否看懂并继续；明显不适配的人是否能在广告或页面识别边界；提交后团队能否追到来源并正确处理。测试账户和测试线索单独标记，不污染正式数据。
预算和观察窗口写进同一张表。停止条件可以是大量搜索词明确不相关、页面故障或承接中断；继续条件可以是搜索相关且链路正常，仍需积累样本。不要用一次偶然提交决定永久扩大。
复盘怎样反向改进内容与业务
复盘先看搜索词是否属于需求组，再看广告是否准确、页面是否兑现、表单是否成功、线索是否有效和销售是否处理。每个断点对应不同动作：收紧匹配、排除错误需求、改广告、补页面、修技术、调整表单或完善交接。
客户反复询问页面没有回答的实施问题，可以成为内容更新；某类搜索长期不适配，可能说明业务边界应写得更清楚；有效线索集中在某个具体场景，可以在有足够证据后建立独立单元。投放不只是购买流量，也帮助团队听见客户怎样表达需求。
需求组怎样沉淀成团队资产
每轮结束时，不覆盖旧版本，而是记录新增搜索表达、被证实或否定的假设、页面补充、广告变化、无效原因和成熟中的线索。下一位同事可以知道当初为什么这样设置，不会只根据当前数据重新猜测。
需求组还可以反哺SEO、内容和产品沟通。反复出现的问题适合形成完整知识页，页面中常见误解可以进入FAQ，销售经常补充的解释可以回到服务页。进入公开内容前仍要核验事实和授权，搜索词中的个人或客户信息不能直接公开。
当产品范围或客户对象变化时，用新版本重新确认关键词、广告和页面，不让历史结构自动延续。一个可维护的SEM账户，本质上是业务知识的索引，而不是只属于某位投放人员的操作习惯。
需求单元也需要退出和合并规则。产品停止、页面下线或业务边界变化时，暂停对应广告并保存原因；两个组长期承接同一任务且数据过少时，可以合并但保留历史映射；同一组出现明显不同的页面和后端标准时，再拆分。结构服务于判断，不追求计划和单元数量。
对小团队而言，一张共享表也能完成第一版治理。关键是列名稳定、事实可核对、修改有日期、下一步有人负责；不必在还没有清楚业务结构时先购买复杂工具。
先让方法可用，再决定是否系统化。
常见错误是一次放入多个产品，用一个首页承接，广告之间使用不同承诺，只看点击率，以及让销售反馈停在“线索不好”。合格的需求单元最终留下需求卡、搜索词处理记录、广告版本、页面版本、来源字段、承接结果和下一轮决定。它让每一笔花费能够回答一个业务问题，而不只是让广告后台看起来整齐。