用 Make 串起从客户需求到交付承诺的端到端流程

很多团队在引入 AI 之后遇到同一个问题：模型给出的答案时好时坏，原因往往不在模型，而在于同一个业务概念在不同系统里有不同的名字、不同的编码、不同的计算口径。要让 AI 真正参与业务交付，需要先把「工作怎么走」和「信息怎么连」这两件事理清楚，再用自动化工具把它们固定下来。Make 适合承担后半段：把已经梳理清楚的步骤、判断和审批，变成一条可重复执行、可观测的流程。这篇教程面向业务负责人、流程负责人和负责落地自动化的实施人员，讲的是如何围绕一个具体的业务交付物——一份包含产品、价格与交付承诺的客户报价——把端到端流程搭起来并验证效果。

准备工作

在打开 Make 之前，先把下面这些前置条件准备好。这一步做不扎实，后面搭出来的流程只会把混乱自动化，跑得越快错得越多。

1. 选定一个具体的业务交付物

不要从「我们要做 AI 转型」这种目标出发。选一个可以被清楚描述、有明确责任人的交付物，例如：

一份客户报价：包含批准的产品、价格、商务条款与交付承诺。
一份生产计划：包含已验证的产品配置、作业指令与确认过的排期。
一份产品设计：包含已验证的规格与测试要求。
一次客户问题处理：包含批准的解决方案与已完成的跟进。

本教程以客户报价为主线，因为它的输入来自销售、约束来自制造、结论要回到客户，天然横跨多个团队，最能暴露信息不一致的问题。

2. 找到这个交付物的流程负责人

需要一位对结果负责的人，而不只是对某个环节负责的人。这个人要能拍板三件事：哪些步骤可以删、哪些审批必须保留、每个决策由谁签字。没有这个角色，流程梳理会停在讨论阶段。

3. 盘点重复劳动与等待点

把工程、制造、销售、交付四个环节的现状画出来，重点标出三类位置：

重复录入：同一个信息被不同团队在不同系统里各录一遍。
等待审批：任务卡在某个人手里，而这个人其实只需要看一眼。
人工转交：信息靠邮件、表格、聊天工具在团队和系统之间搬运。

这些位置就是后续要交给自动化处理的地方。注意，质量检查与必要审批要保留，简化的是冗余环节，不是控制点。

4. 统一产品标识与业务规则

这是最容易被跳过、也最容易导致失败的一步。需要确认：

产品身份：工程、制造、销售三方能识别出同一个产品，即使各自使用不同的编码。
关系：客户需求与产品规格、所需部件、制造能力、交付承诺之间的对应关系。
业务规则：产品兼容性、质量、制造、定价、交付各自的判定规则。
复用：工程、制造、销售的流程与 AI 代理使用同一套已批准的产品信息和规则。

现实中销售和工程经常给同一个产品用不同编码。可以由 AI 辅助找出可能的匹配项，但必须由对应团队确认，确认后的定义要在各团队与代理之间复用，而不是每次重新比对。

5. 对齐关键指标的计算口径

如果同一个业务指标在不同团队有不同算法，AI 会依据取到的数据源给出不同答案。需要与业务负责人逐项确认：每个关键指标怎么算、由哪个系统提供权威数据、定义如何在团队与代理之间复用。

同时确认 AI 能取到三类信息：

业务数据：产品就绪状态、成本、制造产能、交付状态。
公司知识：已批准的产品规格、质量标准、客户协议、作业程序。
工作上下文：未关闭的问题、待审批事项、近期决策。

6. 账号与连接

准备 Make 账号，并为流程中涉及的每个系统准备可用的连接凭据（例如产品主数据系统、订单或报价系统、审批系统、通知渠道）。各套餐的功能范围、操作次数配额与价格会调整，具体以官网当前信息为准。连接时遵循最小权限原则：流程只需要读的产品主数据，就不要给写权限。

操作步骤

第一步：把流程简化到可以自动化的程度

先做减法。针对选定的交付物，逐条检查每个步骤，回答三个问题：这一步产生新的判断吗？这一步是必要的控制点吗？这一步能否由系统直接完成？

一个可以参考的对照是包装评审类流程：先分析人员的时间究竟花在评审本身、等待反馈，还是重复劳动上，再决定哪些活动交给 AI 执行与改进。这类流程优化后，评审时间可以从六小时降到平均三十分钟，整体周期从八周缩短到四周。这个数字不是承诺，而是说明「先简化、再自动化」能带来的量级。

简化完成后，把保留的步骤写成清单，标明每步的输入、输出、责任人和是否需要审批。这份清单就是后面在 Make 里搭场景的蓝图。

第二步：在 Make 中建立产品匹配与确认场景

第一个场景解决「同一个产品在不同系统里对不上」的问题。思路是：接收客户需求，取出候选产品，做编码与名称的比对，把不确定的匹配交给人确认，确认结果写回共享的产品信息。

场景结构大致如下：

触发器：监听新的客户需求，可以是表单提交、邮件到达或业务系统中的新记录。
读取产品主数据：按客户需求中的产品描述检索候选产品。
比对：将候选产品的编码、名称、版本与需求描述逐项对照，输出匹配候选与置信度。
分支：高置信度匹配直接进入下一步；存在歧义的匹配进入人工确认分支。
人工确认：把候选列表发给对应团队，由人选择正确项。这一步不能省，AI 只负责提出可能，确认责任在团队。
写回：把确认后的产品关系与定义写入共享信息，供后续场景和其他代理复用。

在 Make 中，分支用 Router 实现，人工确认可以用审批类模块或把任务推送到团队日常使用的协作工具。写回步骤要幂等：同一条确认重复提交时，不应产生重复记录。

第三步：建立共享信息层，让判断有据可依

第二个场景负责在生成报价前把三类信息聚合到一起：业务数据（产品就绪状态、成本、产能、交付状态）、公司知识（已批准规格、质量标准、客户协议）、工作上下文（未关闭问题、待审批、近期决策）。

在 Make 里，这通常表现为一个「取数」场景：并行调用多个数据源，把结果按统一口径整理成一份结构化记录，再交给后续的判断模块。要点有三条：

每个字段标注来源系统，便于出问题时回溯。
指标按已对齐的口径计算，不要在流程里临时定义算法。
缺失数据要显式标记，不要让空值静默通过，否则后续判断会基于不完整信息做出结论。

第四步：把决策与审批接进流程

第三个场景处理「有方案，但需要人拍板」的情况。典型情形是：报价已经准备好，但产能突然受限。此时流程需要做的是：

识别受影响的客户与产品承诺。
探索替代方案，例如换用另一个已批准的产品，或调整交付日期。
把候选方案连同影响范围提交给有权决策的人。
收到批准后，更新相关系统并协调后续步骤。

在 Make 中，这一步的关键是把「谁批准什么」写成明确的规则，而不是让流程自己猜。每个决策点都要能回答：优先级是什么、谁签字、批准后触发哪些动作。批准之后，流程应当完成三件事：触发对应的工程、制造、销售或交付活动；把已批准的信息传给责任系统；把例外升级给正确的人并跟踪完成情况。

需要强调的是，AI 可以执行已批准的决策，但审批责任和业务结果仍然在人身上。流程设计上要保证这一点不被绕过。

第五步：把结果落到真实业务产出

最后一个场景把批准后的信息写回业务系统，形成真正的交付物。对客户报价而言，产出应包含：已批准的产品、定价、商务条款与交付承诺。对生产计划而言，是已验证的产品配置、作业指令与确认过的排期。对产品设计而言，是已验证的规格与测试要求。

每个产出都要能回答三个问题：谁负责、需要谁批准、工作是否真的完成。在 Make 中，这意味着场景末尾要有明确的完成状态回写，而不是发出一条通知就算结束。

一个完整示例

下面把五个步骤串成一条最小可运行的链路：客户提出产品需求，系统匹配产品、聚合信息、生成报价草案，产能受限时走审批，批准后写回并通知交付团队。

场景一：需求接入与产品匹配

触发器：新客户需求（表单 / 邮件 / 业务系统记录）
  ↓
模块：检索产品主数据（按需求描述取候选）
  ↓
模块：比对编码、名称、版本，输出候选与置信度
  ↓
Router：
  分支 A（匹配明确）→ 写入「已确认产品关系」
  分支 B（存在歧义）→ 推送候选列表给对应团队 → 等待人工选择 → 写入「已确认产品关系」

场景二：信息聚合

输入：已确认的产品标识 + 客户需求
  ↓
并行取数：
  - 业务数据：产品就绪状态、成本、产能、交付状态
  - 公司知识：已批准规格、质量标准、客户协议
  - 工作上下文：未关闭问题、待审批、近期决策
  ↓
按已对齐口径计算关键指标，字段标注来源系统
  ↓
输出：结构化报价输入记录（缺失字段显式标记）

场景三：报价生成与产能校验

输入：结构化报价输入记录
  ↓
生成报价草案：产品、价格、商务条款、交付承诺
  ↓
校验产能与交付可行性
  ↓
Router：
  分支 A（可行）→ 进入场景四的写回步骤
  分支 B（产能受限）→ 识别受影响承诺 → 生成替代方案（换产品 / 调交付日期）
                    → 提交有权决策人审批
                    → 批准后进入场景四；驳回则记录原因并通知销售

场景四：写回与协同

输入：已批准的报价方案
  ↓
写回报价系统 / 订单系统（幂等写入）
  ↓
触发下游活动：工程确认规格、制造确认排期、交付确认承诺
  ↓
例外升级给对应责任人，并跟踪完成状态
  ↓
回写完成状态，关闭本次流程

跑通这条链路之后，用同一套结构去覆盖其他交付物：把「客户报价」换成「生产计划」或「产品设计」，替换取数源与写回目标，匹配与审批的逻辑可以复用。

怎么判断这件事做成了

验收要分三层看，不要只看流程有没有跑起来：

采用情况：人们是否在日常工作中真的在用这条流程，而不是绕开它走老路。
流程表现：工作是否更快完成、错误是否更少、返工是否减少、质量是否稳定。以包装评审为例，可以测评审耗时、评审轮次和整体周期。
业务结果：对客户的承诺是否兑现、客户体验是否改善、成本是否下降、财务结果是否变好。

这里有一个容易混淆的地方：节省的时间不等于节省的成本。产品提前上市意味着可能更早产生收入、更早触达客户或降低开发成本，但需要实际测量对收入、成本和利润率的影响，而不是假设「更快」自动等于「更赚钱」。同样，流程变快之后还要看团队是否因此完成了更多项目、质量是否维持、实际支出是否下降。

注意事项

不要跳过人工确认。 AI 可以提出产品匹配的可能，但确认必须由对应团队完成。把确认环节自动化掉，等于把错误固化进共享信息层。
指标口径必须先对齐。 同一个指标在不同团队算法不同，AI 会依据取到的数据源给出不同答案。口径没定，流程跑得再顺也没有可信结论。
简化不等于砍掉控制点。 要删的是重复劳动、无谓等待和人工搬运，质量检查与必要审批应当保留。
审批责任不能转移给 AI。 AI 执行已批准的决策，人负责批准和最终业务结果。流程设计要让这个边界清晰可见。
写回要幂等。 重复触发、重复确认在自动化流程里很常见，写回步骤必须能承受重复执行而不产生脏数据。
缺失数据要显式暴露。 静默通过的空值会让后续判断建立在错误前提上。
一次只改一个交付物。 先在一个交付物上拿到可测量的结果，再把方法复制到其他工作流，避免同时铺开导致无法归因。
配额与价格以官网为准。 Make 各套餐的操作次数、模块可用范围与计费方式会调整，搭建前请核对官网当前信息，避免流程上线后因配额不足中断。