本期的问题是：对招标文件中的每一条需求，你能立刻指出提案书在第几页作了回应吗？
想象一位评审专家，一边摊开你的提案书，一边摊开招标文件。看到第4.3.2条需求时，他开始翻页。答案大概就在某处，也许分散在两个章节里，也许是用你的说法而不是客户的说法写的。找不到，就没法给分。防止这一刻发生的工具就是合规矩阵：一张列出所有需求、并指向提案书中作答位置的表。对团队来说，它是检查清单和工作计划；对评审专家来说，它是一张地图。
本系列逐一解读APMP Foundation学习指南所概述的APMP知识体系。第1期讲解了合规性与响应性的区别，并对照介绍了合规矩阵和响应矩阵。从本期开始，进入把策略变成实际交付物的Create Deliverables部分，第一个主题就是矩阵本身：里面放什么、什么时候做、谁来用、怎样保持准确。
合规矩阵是什么，为谁服务
APMP知识体系把合规矩阵描述为承担两项任务的工具：管理应答的准备过程，以及向客户证明合规。两项任务都建立在一个简单的结构上：左边是需求，右边是答案所在的位置。
因此，矩阵同时是两类读者的检查清单：
- 你的团队用它确认每条需求都有答案、有负责人、在提纲中有位置。
- 评审专家用它从需求直接找到你的回应，不用四处翻找。
第二类读者很容易被低估。评审提案书很少是一个人唯一的工作，而且很多评审专家并不是项目所涉技术领域的专家。学习指南的建议是尽量让他们的工作又快又轻松，即使招标文件没有要求，也要附上矩阵。位置放在应答中第一个涉及招标需求的章节之前，让评审专家先拿到地图，再进入正文。
有时客户会在招标文件包里附上自己的矩阵。把其中的条目当作客户的硬性要求，但不要以为它就是全部。这一点下文还会再谈。
矩阵应覆盖的三个合规层面
“合规”常被简化成“需求都答了吗”。知识体系的视角更宽。合规的提案书会让客户觉得你经验丰富、专业、好打交道，而这种印象取决于三个层面：
| 层面 | 涵盖内容 | 检查问题 |
|---|---|---|
| 递交要求 | 应答必须如何递交 | 是否采用了规定的格式和装订、递交方式？是否回答了所有问题、填好了所有表格和附件？是否在截止时间前递交给正确的人、正确的地点？ |
| 需求 | 客户要你做的事 | 我们真的能提供这项服务吗？拟派人员真的能到岗吗？是否回应了每条需求背后的真实需要？有没有我们满足不了的需求？ |
| 内部合规 | 本组织自己的规则 | 法务等内部要求是否满足？商机是否按规定录入了CRM等系统？合适的人员和管理层级是否参与？提案书是否已获批准递交？ |
只跟踪第二个层面的矩阵，仍可能在第一个层面上失分，比如漏了一张表格或上传晚了；也可能在第三个层面上出问题，比如递交了一份没人批准的标书。因此很多团队把递交要求和内部审批也列为单独的行，或放在同一工作簿的另一张表里，让递交前只需检查一个地方。
在动笔之前建立
这部分最重要的原则是时机。合规矩阵和提纲一样，应当紧贴招标文件的结构，并且与提纲同步、在内容规划和写作开始之前建立。初稿写完再做矩阵，就像墙都砌好了才画平面图：你会知道问题在哪里，但想挪动什么都已代价不菲。
提早建立的矩阵能做到索引做不到的事：
- 成为写作者的行动计划。每位写作者都能准确看到自己的章节必须回应哪些需求。
- 把招标文件拆成任务包。需求可以分组，分派给合适的人，包括需要据此核算成本和报价的人。
- 明确责任。每条需求旁边都有名字，投标经理或提案经理的跟进就容易得多。
- 降低遗漏的可能。缺口会在还来得及补的时候以空白格的形式暴露出来。
在搭建提纲时，值得对每一行问几个问题：由哪个章节回答？谁来写？评审在哪里核对？怎么判断已经完成？
合规矩阵不是最后补上的索引，而是从一开始就照着施工的蓝图。
逐行拆解招标文件
建立矩阵的第一步，是业内常说的拆解（shredding）：逐行阅读招标文件，把每条需求单独拆成一行。英文招标文件中的信号是shall、must、will等义务性词语，中文招标文件中则是“应”“须”“必须”等表述；“列明”“说明”“提供”“证明”“论述”这类指令动词同样是信号。
需求常常成群出现。下面是为本文编写的一段话，形式在服务类招标文件中很常见：
招标文件 3.4 过渡。承包方应列明领导过渡工作的关键人员，并应说明在不中断服务的前提下从现有服务商接管服务的计划。投标人须提交填写完整的表格C（过渡进度表），并在过渡期内提供每周进展报告。
如果把这段话放在一行里，很容易只答了一部分：写作者把接管计划写得很详细，对人员一笔带过，表格则忘了。拆开后，它变成四行，每一行都可以分派、撰写和核对：
| 招标条款 | 需求（客户原话） | 提案书章节 | 负责人 | 状态 |
|---|---|---|---|---|
| 3.4 (a) | 列明领导过渡工作的关键人员 | 2.1 过渡团队 | 人力资源负责人 | 草稿 |
| 3.4 (b) | 说明不中断服务、从现有服务商接管服务的计划 | 2.2 过渡方案 | 解决方案架构师 | 审核中 |
| 3.4 (c) | 提交填写完整的表格C（过渡进度表） | 附件C | 投标协调人 | 未开始 |
| 3.4 (d) | 过渡期内提供每周进展报告 | 2.4 管理与报告 | 交付经理 | 草稿 |
学习指南还指出了拆解的另外两个好处。写作者得到一份精确的作答清单，评审得到一份精确的核对清单。而且由于每条需求各占一行，招标文件发生变更或提纲调整时，只需改几个单元格，不必重建整张表。
找出清单之外的需求
不要以为招标文件里编了号的需求，或客户提供的矩阵，已经包含了一切。知识体系提醒，有些需求从未被标注为需求，它们藏在正文叙述里，比如项目背景、现状与问题、工作范围中的某一句话。像“目前工作人员每月要花大量时间手工核对报表”这样的一句话，可能正是客户采购这个项目的真正原因。
找到并回应这些需求，不只是补上合规的漏洞，还向客户表明你读完并读懂了整份文件，向第1期所说的响应性迈进了一步。
用可排序的电子表格管理
知识体系推荐使用电子表格，理由很实际：矩阵一直在变。章节重新编号，或变更通知改写了某条需求，只要改单元格再重新排序即可。切换排序方式，同一张表还能回答不同人的不同问题：
| 排序依据 | 回答的问题 | 通常谁来问 |
|---|---|---|
| 招标文件章节 | 客户的每条需求是否都按客户的顺序被跟踪？ | 投标经理、最终合规审核人 |
| 提案书章节 | 我们提纲的每个部分要回应什么？ | 写作者、分册负责人 |
| 负责人 | 每个人负责什么、截止到何时？ | 投标经理、各位撰稿人 |
| 状态 | 哪些还未开始、在草稿中或在审核中？ | 投标经理、管理层 |
第1期给出了一套基本列。实际工作中，很多团队还会加上各章节的篇幅限制，以及每条需求对应的评分项，让写作者同时看到要写什么、以及会怎样被打分。
沿用客户的编号和措辞
有两个习惯能让评审专家用起矩阵来轻松得多。
使用招标文件的编号体系，矩阵里如此，提案书本身也如此。学习指南承认，这可能与你想要的叙述顺序冲突，但这样评审专家可以顺着清单打分，不必来回翻找。如果你的故事需要不同的展开方式，就在客户的结构之内讲，而不是另起炉灶。
使用客户的措辞。不要在矩阵里把需求改写成自己的术语。每一行都以招标文件所用的动词开头，因为动词告诉写作者评审专家期待哪一种答案：
| 如果招标文件说…… | 评审专家期待看到…… |
|---|---|
| 列明（Identify） | 具体的姓名、项目或角色，而不是笼统描述 |
| 说明（Describe） | 如何运作：步骤、顺序、职责 |
| 提供（Provide） | 交付物：表格、计划、证书，作为附件或写入正文 |
| 证明（Demonstrate） | 行之有效的证据：业绩、推荐人、证明点 |
| 论述（Discuss） | 你的判断依据，包括备选方案和取舍 |
换成自己术语的标题
“2.2 我们的无缝迁移方法论”——评审专家得自己判断这是在回答招标文件3.4 (b)。
使用客户术语的标题
“2.2 不中断服务的接管计划（招标文件3.4 b）”——评审专家一眼看到自己原话中的需求和它的编号。
一份矩阵，五类读者
只有投标经理打开的矩阵，只发挥了一半作用。知识体系列出了团队中不同角色如何阅读同一份文件：
| 角色 | 如何使用矩阵 |
|---|---|
| 投标经理／提案经理 | 提案内容的总体规划，也是把每条需求分派给负责核算成本、报价或作答的人的工具 |
| 分册负责人 | 确认本分册所有需求都已覆盖的检查清单 |
| 写作者 | 说明每个章节应写什么的指南 |
| 评审人员 | 界定每个章节应包含什么的评估工具 |
| 管理层 | 一览计划及其背后策略的概览 |
正如学习指南总结的那样，矩阵因此也是一张应答分派表：投标经理借助它把工作分给众多参与者，并逐项跟进。
一直更新到递交为止
建立矩阵属于规划，保持它准确则是一项持续到提案书递交的工作。知识体系列出了需要触发更新的变化：
- 提纲：章节名称、编号、顺序或篇幅分配发生变化。
- 团队：章节换了撰写人。
- 招标文件：说明、评分标准、需求或补遗发生变化。
明确指定一名团队成员负责更新矩阵。过时的矩阵比没有矩阵更糟，因为团队会继续相信它。评审、色队审查和最终合规检查，准确程度都取决于它们所依据的那张表。
盯紧否决项和部分符合的行
矩阵定稿前，有两类行需要格外留意。一类是标为否决项的需求：只要漏掉一条，提案书可能根本不会进入评审，所以要醒目标出、最先核对。另一类是标为“部分符合”或“不符合”的行。逐条对照客户需求，看看方案或答复能否更接近完全符合。对于剩下的差距如何坦诚说明，第1期已经讲过。
提交版：响应矩阵、对照表，也是展示优势的工具
团队使用的矩阵和提交的表格不是同一份文件。提交版在知识体系中称为响应矩阵，实务中也叫交叉索引表或点对点应答表。它去掉负责人和状态，只留下评审专家需要的内容：需求、招标条款编号，以及你作答的位置。如果篇幅限制放不下单独的表格，可以像第1期所说的那样，把同样的索引写进章节标题。
如果招标文件规定了这张表的格式，就严格照做。但学习指南指出，大多数招标文件并不规定格式，这就给了这张表发挥更大作用的空间。比如在关键需求旁加一列，简短写明对客户的收益，枯燥的索引就变成了制胜主题再次出现的地方：
| 招标条款 | 需求 | 作答位置 | 对您意味着什么 |
|---|---|---|---|
| 3.4 (b) | 说明不中断服务的接管计划 | 第2.2节，第14–17页 | 逐个站点分步切换，每一步都有回退方案，前台服务始终不停 |
| 5.1 | 提供24小时服务台 | 第3.1节，第22–24页 | 白天和夜间由同一团队负责，来电不会转交给另一支夜班队伍 |
新增的这一列要简短、基于事实。它出现在每位评审专家都一定会用的表里，位置宝贵，但不能让表格变得难以浏览。
常见错误
- 最后才做矩阵。到那时它只能记录缺口，无法预防缺口。
- 轻信客户的清单。招标文件的编号需求和客户提供的矩阵，条目数未必等于真实需求的数量。正文叙述也要读。
- 不再更新。变更通知来了，提纲调整了，撰写人换了，却没人改表。从那一刻起，团队就在按错误的计划工作。
- 改写客户的措辞。你的术语也许更好，但会让评审专家难以和自己的清单对照。
- 止步于合规。知识体系说得很清楚：合规性和响应性很重要，但并不是客户考虑的全部。完全合规的提案书仍然需要差异化优势、收益和有竞争力的价格。
下一份提案书的检查清单
- 通读整份招标文件，在动手做任何东西之前，连项目背景和工作范围的叙述也读完。
- 逐行拆解：每个义务性表述或指令动词一行，保留招标文件的编号和措辞。
- 补上在正文中发现的隐藏需求，并标出否决项。
- 与提纲同步建立矩阵，在动笔前为每一行指定提案书章节、负责人和状态。
- 覆盖全部三个层面：递交要求、需求和内部审批。
- 用电子表格管理，并为各个角色共享他们需要的排序视图。
- 指定一名更新负责人，在提纲、团队或招标文件变化后及时更新。
- 定稿前复查所有部分符合和不符合的行，能补的尽量补上。
- 提交响应矩阵（或在标题中注明招标条款编号），放在第一个回应需求的章节之前；客户规定了格式就照做，没有规定就加一列简短的收益说明。
在Contrl中
合规矩阵最耗时的是第一遍工作：拆解招标文件，并决定每条需求在哪里作答。在Contrl中上传招标文件后，它会提取需求、规定的提纲和评分标准，并把每条需求对应到该提纲的章节，因此在写任何一页之前，矩阵就已经存在。幻灯片写成后，每一页都会注明它回应的招标需求，需求与页面之间的对应关系就留在页面上，而不是放在一张需要有人记得去更新的单独表格里。
下期预告
矩阵告诉你每条需求将在哪里作答，包括那些要求给出数字的需求。第13期讲成本与价格数据（Cost and Pricing Data）：价格背后有什么，为什么政府客户和商业客户要求查看它的方式差别如此之大，以及展示定价逻辑为什么能提升整份提案书的可信度。
本文是基于APMP Foundation学习指南第4.2版（© 2025 APMP）的独立学习解读，该指南是对APMP知识体系的概述。本文对原材料进行了转述和评论，并未获得APMP认可。招标文件示例段落及其拆解行、排序依据表和指令动词表、标题对比、隐藏需求例句以及收益列示例，均为本文编写，仅为示例。权威原文和认证信息请见apmp.org。