如何使用这项资源方法
- 用途
- 先核清客户与经济结果，再沿实际业绩链查找偏差，区分经营条件与工作机制，按证据组织必要的SOP改进。
- 使用条件
- 使用前请核对对象、目标和约束是否适合当前任务；正文未明确的条件需要另行确认。
- 方法
- 步骤、输入与完成条件
- 依据与验证边界
- 文中案例用于演示分析和操作。应用时请用实际业务记录替换示例条件，再核对判断和结果。 本文未单独登记外部验证结果。公开发布不等于效果已经验证，请结合正文依据、假设与限制判断。
- 版本
- R1 · 修订 2026-11-04
- 原生配图与附件
这是可阅读、可引用的知识资源，不是已安装的 Skill。交给 AI 使用时，请保留来源与限制，并核对产出。
CC BY-NC-ND 4.0 · 原创文字内容适用，另有声明除外；第三方素材不适用。下载和机器读取不扩展现有许可，也不另行授权衍生作品、商业使用或模型训练。
客户联系了，需求表填了，报价发了，跟进记录也齐了。每一项任务都显示完成，月底却发现：订单没有增加，客户没有留下来，钱也没有按预期回来。
这时候，管理者容易想到两件事：再把流程写细一点，或者要求大家执行得更严格一点。
这两种做法有时有用，但先要弄清楚：现在的问题，究竟出在工作没有做好，还是做好的这项工作，本来就不足以带来预期结果？客户是否需要这个产品，是否接受这个价格，渠道找到的是不是合适的人，这些都需要放进来判断。
我认为，业绩没有达到预期时，可以先沿着业绩链查问题，再决定需要启动哪些业务、职能和动作层面的SOP。先把问题找到，流程改进才知道要解决什么。
先分清三个“完成”
这里的SOP（标准作业流程），是把一项工作的步骤、要求和例外处理写清楚，供团队执行和检查的工作指南。文中把与客户和经济结果相连的关键业务路径称为业绩链。
在早期的《SOP梳理设计方法论》中，业绩SOP指向与客户强关联、以经济目的为结果的核心业务逻辑，业务、职能和动作SOP为它提供支撑。我觉得这个起点要保留：看一项工作做得怎么样，要知道它最后支持什么结果。
其中，业务SOP处理跨角色的业务协作，职能SOP处理一项有明确结果的闭环任务，动作SOP说明具体操作。
实际使用时，还要把下面三个层面分开。
| 层面 | 要核对什么 | 能说明什么 |
|---|---|---|
| 活动完成 | 有没有按要求联系、整理、发送、操作 | 工作发生过，相关步骤可以追溯 |
| 过程结果成立 | 需求是否经核对，方案关键条件是否得到必要确认，交付是否达到约定 | 这一环节是否为后续工作提供了合格条件 |
| 客户与经济结果实现 | 客户是否购买、使用、验收，收入、回款和经营收益是否达到目标 | 这条业务链是否实现了本期要观察的结果 |
发出报价，只能说明报价被发出。客户有没有收到、有没有理解、是否接受，还要继续核对。即便签了合同，也要分别看交付、收入、成本和回款。
工作完成以后，检查不能停在完成记录上。每个关键环节都要继续问一句：这个动作想改变什么状态，现在有证据表明它改变了吗？
标准作业仍然有价值。它可以稳定已有做法，为培训、比较和持续改进提供基线。Lean Enterprise Institute对标准作业的说明也把它放在持续改善的过程中，而不是把写出标准视为终点。参考：标准作业
把“没有业绩”说成一个可以调查的问题
“业绩不好”太宽，团队很难据此找到同一件事。
先选一条具体业务，明确服务哪类客户、销售什么产品或服务，再写清本期要检查的结果、实际差距和观察期限。例如，“本期新增订单少于计划”与“上一批到期应收款未到账”，调查对象和处理方法就不同。
这里有三个口径，要先说清楚。
第一，签约、收入、回款和利润分别看。它们之间有联系，但不是同一件事。一次促销可能增加订单，也可能带来更多折扣、退款和履约成本。
第二，把可比较的对象放在一起。比较同类产品、相近客户和相同成熟阶段的业务，记录渠道、范围和条件的变化。本月拿到的线索，未必都能在本月形成订单；不能把本月全部线索与本月全部订单直接相除，就当成这批客户的转化情况。
第三，约定什么时候再看。交付与回款还没到约定期限，不能提前判为失败；已经过了观察节点，也不能一直用“销售周期长”搁置问题。对尚未结束的事项，保留当前状态、下一次核对日期和负责人。
本步要留下的是一句清楚的问题：哪一批业务，哪一个结果，在什么时间内，比原来的目标或基线差了多少？ 如果目标本身缺少依据，也要列为待核对事项。
沿实际业绩链，找出结果从哪里开始偏离
以一项项目型销售为例，可以先把业绩链画成：接触合适客户、核清需求、形成可接受的方案与条件、达成交易、履行交付、完成约定结算。不同业务的顺序和节点会不同，复购、续约、退货、返工与退出也要按实际情况保留。
接着，把每个关键节点原本需要形成的结果，与实际证据放在一起。
可左右滑动查看图示，也可打开大图。
图一：先明确未实现的结果，再沿实际业绩链核对客户状态、证据与偏差。这是项目型销售的检查示例；实际业务可以回访、重谈、返工或退出。打开可编辑SVG
检查时，既看数量，也看质量、等待时间和未继续推进的原因。需求表有多少份，不如继续问：有多少份核清了客户要解决的问题、采购条件和决策过程？交付任务完成了多少，也要看客户是否按约验收、是否仍有待处理事项。
如果某一段开始出现明显偏差，可以先围绕它调查。但发现偏差的位置，还不能直接当成原因。报价以后流失，可能与价格有关，也可能是需求理解错了、交付条件不合适，或者接触的人没有购买权限。回款延迟，也可能与前面的交付争议有关。
因此，顺着链条看哪里受阻，还要回头核对这一环节收到的输入。上一步留下的问题，可能在后一步才显现出来。
同时检查经营条件与工作机制
找到受阻环节以后，我建议把可能原因放在两组问题里共同核对。
一组检查这门业务目前是否成立。
| 经营条件 | 需要继续查什么 |
|---|---|
| 需求 | 问题是否真实、是否急迫，谁使用、谁决定、谁付钱，购买条件是否具备 |
| 产品 | 方案能否解决问题，质量、使用方式、交付与服务是否适合当前客户 |
| 价格与交易条件 | 客户是否理解总成本，预算、账期和合同条件能否接受，企业能否承担履约成本 |
| 渠道 | 是否接触到合适对象，渠道承诺与实际供给是否一致，线索来源是否发生变化 |
| 外部条件 | 客户预算、竞争选择、供给条件或其他约束是否发生变化，原来的判断是否还适用 |
另一组检查工作是否具备完成条件，以及现有做法能否得到需要的结果：前置资料是否合格，协作顺序是否合理，决策和交接是否清楚，资源与能力是否足够，标准是否适用，实际操作有没有偏离。
两组问题可能同时存在。例如，客户要求的交付时间变短，而内部确认供应能力的过程仍然很慢。这里既有外部条件变化，也有业务协作需要调整，不能只选一个理由解释全部问题。
调查可以使用订单、交付、验收、报价版本、沟通记录与财务记录，也可以请客户和参与者补充说明。不同来源相互核对，尽量找到发生了什么，而不是只收集支持原判断的材料。客户说“有兴趣”，与愿意按具体条件购买，支持的判断也不同。
证据还不足时，先把解释写成待验证假设。例如：“客户没有继续推进，可能是交期与采购时间不匹配。”接下来的工作是核对真实采购节点和可用交期。Strategyzer提出先识别关键假设，再设计测试、把证据返回假设的做法，可以为这一步提供参考。参考：从关键假设开始测试
查清什么问题，再组织什么改进
查完以后，要能说清下一步改什么。需要改哪一层，就组织哪一层的工作，不必把所有SOP都改一遍。
可左右滑动查看图示，也可打开大图。
图二：按证据选择必要干预。两组调查可以并行，几类行动也可能组合使用；每项改变要写明预期影响和复核条件。未到最终观察期限，不判定最终业绩失败；已出现的节点异常仍可及时查证。打开可编辑SVG
如果需求或产品判断出了问题，就重新核对服务对象、产品范围和价值主张。如果价格、交易条件或渠道不合适，就由有权限的人决定是否调整。原来的经营前提已不成立时，还要考虑缩小、暂停或停止这项业务，并安排已有承诺的处理。
如果问题在跨角色的业务协作，可以启动业务SOP改进。例如，报价承诺需要供应、技术与交付共同确认，就明确确认顺序、时限、例外处理和决定权限。
如果问题出在一项闭环任务，就继续看它的设计、完成方式和结果标准。缺条件就补条件，方法不合适就改方法，需要改程序时再修改职能SOP。例如，需求核实一直没有核清使用与采购条件，需要明确这项任务的输入、输出、责任与完成标准。
如果结果目标和任务设计已经清楚，问题出在具体操作，就修正动作SOP。例如，使用了错误的报价版本、漏核一个必要字段，或者交接时没有附上已确认材料。此时培训、工具辅助和操作检查才有明确着力点。
还有一种情况，是大家已经按要求执行，但流程仍然无法产生合格结果。这时需要修改方法或标准，不能继续用原标准证明执行没有问题，就结束讨论。
这些层次按工作关系区分，不机械对应某个部门。一项问题可以涉及多个角色，也可以由同一个人承担几项工作。
用一次小范围验证，检查改进有没有作用
举一个假设情境：一家提供设备配套服务的企业，联系人数、需求登记和报价发送都完成了，订单仍低于计划。这个情境用于说明方法，不是已验证的企业案例。
核对同一批客户后，团队发现部分报价超出了客户的采购窗口，另有部分方案不符合安装现场的条件。这个发现还不足以说明所有问题都来自报价速度，需要分别核实。
可以先选下一批条件相近的需求，调整需求核实与报价协作：在方案形成前确认现场条件和采购节点；对需要技术与供应协同确认的事项，约定反馈时间与例外处理。观察既包括资料合格率、确认耗时，也包括客户是否继续推进、实际成交、履约成本和后续回款。
如果需求核实更准确，报价也更及时，客户仍然不接受，就继续检查产品、价格及其他解释。如果成交增加，但返工和成本上升，也不能马上认定改进有效。多个条件同时改变时，要留下变更记录，避免把结果全部归功于其中一项。
第一次可以用一张简表，把改进做实。
| 记录内容 | 要写清的事情 |
|---|---|
| 结果偏差 | 对象、期间、指标口径、目标或基线、实际差距 |
| 断点证据 | 哪个节点受阻，资料在哪里，输入是否合格，还有什么解释 |
| 本次判断 | 当前证据支持什么，哪些仍待核实 |
| 必要行动 | 改经营条件，还是业务、职能、动作SOP；谁决定、谁执行，投入多少 |
| 复核约定 | 改进前约定何时检查过程与经营结果、与什么基线比较，什么情况下保留、调整或停止 |
等待观察也是一种明确状态，需要写明等什么、等到什么时候。暂停以后要安排客户、交付、款项和协作方的后续处理；恢复时重新检查条件。每轮都把结果和反例留下来，才有机会看清：这套方法在什么情况下能用，什么情况下还不行。
让流程回到企业共同创造的结果
把方法放到企业生态中，资源、运管、客户、资本各方都可以主动提出问题、提供专业贡献，或响应具体需求。精干的运管团队负责相应决策、规则和协调，把价值生产、销售渠道及客户关系接起来。相关参与者共同提供事实，有权限的角色作出取舍，并明确后续承接。
检查业绩链，是为了看清工作怎样支持客户与经营结果。它不意味着把全部经营风险压给某个执行者，也不能仅凭完成记录就确认全部贡献及权益。具体报酬、责任和权益，仍按实际业务、合同与制度分别确定。
我更愿意从一条真实业务开始：这次没有实现什么结果，证据显示问题在哪里，下一步需要改变什么，何时回来检查。
SOP能把已经理解的工作组织得更清楚，也要允许团队发现原来的理解不够。保持这个入口，流程才有机会随着业务一起改进。这套诊断方法的效果，仍需要在具体业务中通过持续记录、结果变化和反例检验。
方法来源与延伸阅读
本文承接早期《SOP梳理设计方法论》第2—4页的四向SOP关系、第6—9页的场景、前置任务、标准、试行与迭代思路。结果口径、同批业务观察、双向查证和必要干预的诊断路径为本次展开；两张图均按本文论证重新设计。
延伸参考：Lean Enterprise Institute：标准作业；Michael Ballé：在办公室环境实施标准作业时，先明确要改善的问题；Strategyzer：从关键假设开始测试。这些资料提供相邻方法参考，不构成本篇诊断框架效果已验证的证据。