# 演示后客户沉默，结局在会议结束前就已注定 > 一份写明日期、双方负责人且由 FDE 撰写技术部分的共同行动计划，比跟进邮件管用得多。 原文: https://fdetimes.net/zh/guides/mutual-action-plan-after-demo/ 演示很顺利。Agent 准确读出了一家物流公司的样例发票，运营负责人频频点头，接着有人说：“不错。我们内部讨论一下，再回复你们。”两周过去了，收件箱依然空空如也。 做前线部署工程师（FDE）久了，谁都遇到过这种情况。常见的反应是发一封“跟进一下”的邮件，然后再发一封。 但结果通常在演示的最后五分钟就已定下：要么你带着有日期、有负责人、有决策者的下一步离开，要么你带走的只是一句谁也不受约束的承诺。 很多人认为这是销售的事。实际上，FDE 是客户在技术层面信任的人，也最清楚试点需要哪些数据、哪些权限，以及 IT 部门谁必须签字批准。因此，下一步计划只有由 FDE 撰写技术部分，才切合实际。 ## 沉默通常意味着还没有计划 解决这个问题的工具是共同行动计划（MAP）。Rework 的 MAP 指南提出了三项要求。第一，每个里程碑都必须有具体的日历日期，而不是“两周内”或“尽快”。 第二，每个里程碑在买方和卖方都必须有一名指定负责人。第三，决策者必须明确确认这些里程碑可以实现。 日历日期之所以重要，是因为没有日期的里程碑会不断拖延，为销售团队开发工具的公司 Sybill 指出了这一点。对这家物流公司来说，“IT 下周会看一下”不会出现在任何人的日程上；“11 月 20 日，IT 工程师批准数据流图”则是一项负责人知道自己会被追问的任务。 第三项要求最常被忽略。光有运营负责人的认可还不够，有权说“同意”的人必须亲自看过里程碑，并确认它们切实可行。 ## 何时拿出计划，才不会让客户觉得被催 Rework 提醒，演示一结束就拿出 MAP，很容易被看作促单手段。所以时机和表述方式与内容同样重要。Sybill 建议，只有当客户在会上确认了三件事后，再提出计划：这个问题值得解决；他们知道预算走哪条路径；他们希望推进。 套用到发票演示上，这三项确认可能是：运营负责人说手工录入发票占用了人力，解释这笔开支要经过首席财务官，并主动问下一步是什么。三项中缺任何一项，都不要急着拿出里程碑表，继续追问，直到弄清楚为止。 这三项确认也化解了上述提醒与“在会上就定下下一步”之间看似存在的矛盾：客户刚说完想推进，里程碑表就是在回答他们的问题，而不是促单手段。 三项都到位后，把计划作为技术计划提出。不要问“你们什么时候签约”，而要说“试点要跑起来，我们需要这几样东西；请告诉我你们这边谁能负责每一项”。 ## 最后五分钟的话术 物流公司确认了全部三项后，FDE 可以这样说： > “结束前我们先商定三件事。第一：哪个指标能证明试点成功，我好把它写下来。 > > 第二：我需要一个月的匿名化发票，你们的 IT 团队需要批准我们的接入方式。你们这边谁能负责这两件事，什么日期之前能完成？ > > 第三：试点结束时，由谁决定是否继续推进？我们现在能不能把和这个人的会议排进日程？” 如果运营负责人回答“这得问我老板”，你就得到了一条重要信息：眼前这个人不是决策者。下一步是请求和那位领导开一个简短的会。会上先草拟下面这张里程碑表，并在一小时内发出： | 里程碑 | 日期 | 客户方 | FDE 方 | |---|---|---|---| | 商定书面成功标准 | 11 月 13 日 | 运营负责人 | FDE 起草 | | 确认时间表切实可行 | 11 月 16 日 | 首席财务官 | FDE 和客户负责人 | | 提供样例数据，IT 批准接入 | 11 月 20 日 | 负责的 IT 工程师 | FDE 发送数据流图 | | 试点开始（30 天） | 11 月 23 日 | 运营负责人 | FDE | | 试点结束 | 12 月 22 日 | 运营负责人 | FDE 对照标准提交报告 | | go/no-go 会议 | 12 月 23 日 | 首席财务官 | FDE 和客户负责人 | 在真实的表格里，负责人一栏写的是人名，而不是职位。里程碑一旦延误，你需要知道该找谁，而那个人也需要知道这项任务归他。 ## 试点需要结束日期 表格的最后一行最重要。市场进入咨询公司 Echai Ventures 认为，试点要以签约而不是不了了之收场，需要四样东西：书面成功标准、指定的决策者、结束日期和价格。 上表只有前三项。价格需要与客户负责人商定，并在 11 月 23 日前写进计划，免得 go/no-go 会议又开启一轮新的谈判。 这里的试点恰好 30 天，从 11 月 23 日到 12 月 22 日，遵循的也是这家咨询公司的建议：90 天的试点早已失去紧迫感，交易往往就“死”在这里。 对 FDE 来说，这个期限在技术上也有帮助：它迫使你选一个范围窄、可衡量的工作流，比如一个月的发票，而不是承诺集成所有系统。 11 月 16 日这个里程碑并非随意设置。根据 Stackmatix 关于把试点转化为合同的指南，有预算权的指定经济买家应从试点一开始就参与进来，试点也应以与同一个人召开的正式 go/no-go 会议结束。 如果首席财务官只出现在最后一行，签字的人就要在必须做决定的那天才第一次听说这个项目。 ## 点头的人不一定是决策者 在 MEDDPICC 框架中，决策流程是客户完成采购所经历的一系列步骤、审批和日期，经济买家则是对预算拥有最终决定权的人。演示中最热情的人，往往不是这个人。 Exec 的 MEDDPICC 指南给出了一个检验方法，用来区分真正的内部支持者和只是给你反馈的人：你不在场时，这个人会不会替你推销？如果你怀疑运营负责人在内部会议上根本不会提起试点，你的计划就建立在一个不会推动它的人身上。 还有一个风险：内部支持者中途离职或调岗。Stackmatix 建议另找接替者或向更高层级上报，而不是等新来的人主动找你。 ## 会后保持推进势头 计划只有保持更新才有用：每次通话后更新，并在每封跟进邮件里附上最新版本。这样，“跟进一下”的邮件就变成一个具体问题：“IT 那边 11 月 20 日的进度还能保证吗？” 如果客户一直回避，不肯写日期、不肯指定负责人，就要把这当作信号。正如 Rework 所说，不愿对计划作出承诺的客户，通常也还没准备好对交易作出承诺。 **要点:** 不肯在计划里写下日期的客户，通常还没打算购买。 看到这个信号时，不要加大施压，而要直接问是什么让他们犹豫。尽早知道交易不会成，远比拖着一个没有终点的试点划算。 ## 常见错误 第一个错误是以“我会发些资料过去”结束会议，这样活儿全落在你身上，客户却什么都不用做。第二个是接受“下个月初”这样的里程碑，因为这类里程碑必然拖延。 第三个是只和最终用户一起制定计划，到试点结束才发现签合同的人从没听说过这件事。 第四个是过早拿出里程碑表，客户还没确认问题值得解决，整场演示就显得像推销。最后一个是任由试点无限期拖下去，没有 go/no-go 会议。 从职业发展看，这是一项值得在简历上写清楚的技能。与其写“支持演示”，不如描述你如何把演示转化为有书面标准和 go/no-go 会议的试点。 面试 FDE 岗位时，可以问团队里谁负责在演示后商定下一步；答案会告诉你公司对你的期望。 下次客户说“我们内部讨论一下”时，可以这样回答：“当然。那我们现在先定下由谁来讨论，以及我哪天跟你们跟进。” **本周动手试试:** - 重新打开最近一次演示后的跟进邮件，划掉所有“尽快”“下周”之类的说法，换成日历日期和具体的人名。 - 下次演示前，写下三个需要确认的问题：这个问题是否值得解决，预算要经过谁，客户是否希望推进。 - 针对每一个正在跟进的客户，问问自己：你不在场时，对接人会不会替你推销？如果不会，写下你还需要见的那个人的名字。 ## 信源 - [Mutual Action Plan (MAP): How to Build One](https://resources.rework.com/libraries/pipeline-management/mutual-action-plan) - [How to Create a Mutual Action Plan After a Sales Call [2026 Guide]](https://www.sybill.ai/blogs/mutual-action-plan-after-sales-call) - [They want a pilot before they commit. How do I run one that ends in a contract instead of a shrug?](https://echai.ventures/gtm/gtm-sales-process/they-want-a-pilot-before-they-commit-how-do-i-run-one-that-ends-in-a-contract-instead-of-a-shrug) - [Enterprise Pilot to Paid Contract: A Startup Conversion Playbook](https://www.stackmatix.com/blog/enterprise-pilot-to-paid-contract) - [MEDDPICC: The Complete Guide to the Sales Qualification Framework](https://www.exec.com/learn/meddpicc-the-complete-guide)