这是一个 SasaDaily 假设商业案例。
不是：
Pipedrive 官方客户案例。
今天假设的是：
一家：
6 人小型工业设备代理商。
团队有：
1 位老板。
3 位业务。
1 位业务行政。
1 位技术工程师。
公司主要卖：
小型包装设备。
输送设备。
视觉检测系统。
以及：
工厂自动化周边。
这种 B2B 生意真正麻烦的地方，不是「找不到客户」
而是：
一笔 Deal：
常常要谈很多次。
第一次：
了解需求。
第二次：
技术确认。
第三次：
现场勘查。
第四次：
看 Proposal。
第五次：
谈价格。
中间：
可能还有：
Email。
电话。
设备规格。
样品测试。
主管批准。
采购流程。
真正成交：
可能已经：
一两个月后。
所以每次开会以前，业务都要重新把故事拼回来
星期三下午：
要去一间食品工厂：
谈自动包装设备。
业务出门以前：
先打开 CRM。
看：
这笔 Deal：
现在在哪里。
再找：
上次 Meeting Note。
翻：
Email。
找：
工程师之前问的规格。
确认：
客户预算。
上一次：
到底答应：
补哪一份数据。
如果这个客户已经谈了六星期
数据：
可能散在：
CRM。
Email。
Calendar。
业务自己的 Note。
技术工程师的纪录。
每次：
真正开始 Meeting 以前。
业务都先花：
十几分钟：
重新恢复记忆。
这不是：
Sales。
这是：
Context Recovery。
Meeting 结束后，另一轮行政才开始
客户今天说：
产线速度：
要再提高。
设备宽度：
可能要修改。
采购预算：
还没正式核准。
希望：
十一月以前：
完成。
业务回到公司：
还要：
整理 Note。
写 Next Step。
通知工程师。
更新 CRM。
判断：
Deal Stage：
要不要动。
修改：
Expected Close Date。
确认：
Deal Value：
还是不是原本那个数字。
最麻烦的是：这些字段不是单纯打字而已
它们其实：
都有：
商业含义。
客户说：
「这个方案看起来可以。」
不代表：
Deal：
已经成交。
客户说：
「预算大概 150 万。」
不代表：
正式 Deal Value：
就是 150 万。
客户说：
「希望十一月可以上线。」
不代表：
公司已经承诺：
十一月一定交机。
所以这家公司导入 Nova，不把目标设成「让 AI 自己管 CRM」
而是：
把目标改成：
让 AI 把需要人工判断以前的行政工作先做完。
整个流程：
拆成：
三段。
会前。
会中。
会后。
第一段：会前让 Nova 先做 Deal Brief
Pipedrive Nova：
可以在 Meeting 前：
根据：
Deal Context。
Organization。
Contact History。
Recent Activity。
以及：
可用的 Email。
Calendar Context。
先整理：
Pre-call Brief。
对这家设备代理商来说：
业务出发以前：
不再从：
第一封 Email：
重新读。
而是：
先看一份：
会前 Brief。
Brief 先回答几个实际问题
这个客户：
要解决什么问题？
上次：
确认了哪些设备规格？
目前：
还有哪些 Technical Question？
客户：
最近一次回复：
讲了什么？
这笔 Deal：
现在在哪一 Stage？
下一步：
原本答应做什么？
但 Nova 的 Brief 不是「真相来源」
真正的：
设备规格。
正式报价。
合约。
测试结果。
仍然：
回原始数据。
AI Brief：
只是让业务：
更快进入状况。
不是：
把所有原始文档：
全部丢掉。
第二段：Meeting 时不要让业务一半时间都在打笔记
如果今天：
是：
Google Meet。
Zoom。
Teams。
可以：
让 Nova AI Notetaker：
以可见 Participant：
加入。
如果：
业务直接：
到工厂现场。
则可以：
在符合告知与同意要求的情况下：
使用：
Nova Companion：
从电脑取得：
Meeting Audio。
对这家设备公司来说，现场会议特别有价值
因为：
工厂现勘：
很少是：
干干净净坐在会议室。
客户可能：
一边走。
一边说：
「这里现在一分钟跑 40 包。」
「未来希望再加一条线。」
「这里空间不能再往右。」
「这个位置操作员一定要保留。」
业务如果：
一路低头记。
很容易：
漏掉真正重要的：
现场 Context。
AI Transcription 可以帮忙留下 Conversation
但：
这里有一条：
不能省。
先处理 Participant Notice／Consent。
Pipedrive 明确要求：
Meeting Organizer：
仍然要负责：
符合所在地法律。
公司政策。
以及：
参与者的选择。
所以：
「Companion 没有 Bot」
不能理解成：
可以：
偷偷录。
第三段：会后真正省时间的是 CRM Update Suggestion
Meeting 结束后：
Nova：
可以先整理：
Summary。
Key Takeaway。
Next Step。
并提出：
CRM Update Suggestion。
例如：
Deal Field。
Person Field。
Organization Field。
以及：
公司的 Custom Field。
对工业设备业务来说，最常见的可能是
客户：
增加：
一项需求。
Nova：
建议：
更新：
Deal Note。
客户：
提供：
新的联系人。
Nova：
建议：
补 Contact。
Meeting：
确认下一次：
技术 Review。
Nova：
整理：
Next Step。
这种信息：
如果清楚：
业务只要：
Review。
不用：
全部重新输入。
但三种字段，这家公司规定永远不能「看到就按 Approve」
第一种：
Deal Stage。
第二种：
Deal Value。
第三种：
Expected Close Date。
原因：
很简单。
这三个：
直接影响：
公司怎么理解：
Pipeline。
例如客户说：「方案原则上没问题」
Nova：
可能认为：
这笔 Deal：
应该：
往下一 Stage。
但业务知道：
客户真正流程：
还需要：
工厂主管。
采购。
财务。
三边：
批准。
所以：
「原则上没问题」
不等于：
正式：
Proposal Accepted。
Deal Stage 要跟公司自己的条件走
这家公司：
可以自己规定：
只有：
需求确认。
技术可行。
正式 Proposal 已送。
决策者已加入。
预算已确认。
到某一个条件：
才能进：
下一 Stage。
不是：
客户讲得：
比较开心。
Stage：
就往前。
Deal Value 更不能只抓 Meeting 里的一个数字
客户说：
「我们预算大概 150 万。」
可能代表：
Budget Ceiling。
不一定：
是：
正式报价。
工程师：
Meeting 里又说：
「如果多加 Vision System，大概再多 30 万。」
也不能：
直接：
把 CRM：
改成：
180 万。
因为：
正式报价：
可能：
还没有算：
Installation。
Training。
Shipping。
Warranty。
Discount。
Expected Close Date 也是一样
客户说：
「希望十一月以前完成。」
这可能是：
希望的：
Project Timing。
不是：
Deal：
真的会在：
某一天 Close。
如果：
这家公司：
Forecast：
又直接依：
Expected Close Date：
去看未来 Revenue。
乱填：
就会：
让老板以为：
十一月：
真的有这笔收入。
所以公司订一条很简单的 Review Rule
Nova：
提出：
CRM Update。
业务先看：
客户原话。
再看：
CRM 现值。
最后：
才看：
AI 建议。
三个：
对得起来。
才：
Approve。
不完整：
Edit。
证据不够：
Skip。
技术字段还要再多一道 Engineer Gate
例如客户说：
「希望速度提高到每分钟 70 件。」
Nova：
可以：
把：
Requirement：
整理进 CRM。
但是：
不能：
顺手改成：
「设备可以达到每分钟 70 件。」
第一句：
是：
客户要求。
第二句：
是：
公司技术承诺。
完全不同。
所以技术工程师只确认四类事情
设备规格。
Performance Claim。
Integration Requirement。
现场限制。
AI 可以：
把客户要求：
整理得很完整。
但是：
能不能做到：
仍然：
由 Engineer：
确认。
正式报价则由业务与老板确认
Nova：
可以：
知道：
Meeting 里谈过：
价格。
但是：
它不负责：
最后：
Discount。
Margin。
Payment Terms。
Warranty。
Shipping。
Installation Fee。
这些：
会直接影响：
公司收益。
所以：
AI 可以：
整理 Evidence。
不能：
替公司：
做 Commercial Decision。
交期也一样
工厂客户最常问：
「如果这星期下单，十一月底以前能不能装好？」
Meeting 里：
工程师可能说：
「正常状况应该有机会。」
这不能：
直接变成：
正式：
Delivery Commitment。
因为：
还要：
看：
Supplier Lead Time。
Inventory。
Custom Part。
工程调度。
现场施工。
所以这家公司把 AI 能做的事情画得很清楚
Nova 可以：
准备 Brief。
留下 Transcript。
整理 Summary。
找 Next Step。
提出 CRM Update。
但是：
以下几件：
人一定确认：
技术是否做得到。
正式价格是多少。
折扣多少。
Deal 到底有没有进下一 Stage。
预计成交时间是否合理。
交货日期能不能正式承诺。
那这样真的能省多少时间？
开始算：
SasaDaily 假设数字。
这家公司：
3 位业务。
一星期合计：
大约：
12 场有效 Sales Meeting。
包含：
在线 Meeting。
以及：
工厂现勘。
原本每场 Meeting 前
平均花：
15 分钟。
重新看：
CRM。
Email。
旧 Note。
12 场：
就是：
180 分钟。
也就是：
3 小时。
每场 Meeting 后
平均：
25 分钟。
整理 Note。
写 Follow-up。
补 CRM。
更新 Stage。
Next Step。
12 场：
就是：
300 分钟。
5 小时。
所以 Meeting 本身以外
一星期：
光 Sales Admin：
大约：
8 小时。
这还没算：
真正和客户开会的时间。
只是：
Meeting 前后的：
行政。
假设导入 Nova 后
每场会前：
不用自己从头找。
只需要：
5 分钟：
Review Brief。
12 场：
60 分钟。
每场会后
Nova：
先整理：
Summary。
Next Step。
CRM Suggestion。
业务：
平均：
10 分钟：
回 Transcript。
确认：
高影响字段。
12 场：
120 分钟。
加起来变成每周约 3 小时
原本：
8 小时。
导入后：
3 小时。
理论上：
少：
5 小时／周。
一个月：
用四周估算：
约：
20 小时。
如果把业务与管理时间的内部成本假设为每小时 NT$600
20 小时：
理论时间价值：
约：
NT$12,000／月。
但这里：
一定要讲清楚。
这全部都是：
SasaDaily：
为了示范 ROI：
创建的：
假设数字。
不是：
Pipedrive 保证：
每家公司：
装了 Nova：
每月一定省：
12,000 元。
Pipedrive 真正的官方客户案例可以当参考，但不能直接照抄
澳洲 PropTech 公司：
Snug：
实际测试 Nova。
Pipedrive 公布的案例中：
Snug 表示：
每场 Sales Meeting：
在：
Preparation。
Note-taking。
Transcription。
Follow-up。
等工作：
最多可以少：
大约：
30 分钟到 1 小时。
但：
这是：
Snug 自己的流程。
不是：
所有公司：
固定成果。
所以这家设备代理商不拿 Snug 的数字当 KPI
只测：
自己的。
第一个 KPI：
Meeting Prep Time。
第二个：
Post-meeting Admin Time。
第三个：
CRM Update Lag。
Meeting 结束后：
多久：
正式数据：
才更新完成？
第四个 KPI：AI 建议修正率
例如：
Nova：
一星期提出：
40 个 CRM Update。
其中：
20 个：
直接 Approve。
12 个：
Edit。
8 个：
Skip。
这就可以：
慢慢看出：
哪些 Field：
可靠。
哪些：
仍然需要：
高度人工判断。
第五个 KPI：重要 Next Step 漏失率
真正值得问：
不是：
Transcript：
写得漂不漂亮。
而是：
Meeting 里：
明明说：
星期五：
要补：
设备 Layout。
Nova：
有没有：
抓到？
如果：
一直漏：
真正重要的 Follow-up。
再漂亮的 Summary：
都没有用。
公司第一个月也不会一次让全部业务自由使用
第一周：
只开：
Pre-call Brief。
先看：
会前准备：
到底省多少。
第二周：
开始测：
Meeting Transcription。
先处理好：
客户告知。
Consent。
公司 Recording Policy。
只选：
适合的：
一般 Sales Meeting。
第三周：
开始使用：
CRM Update Suggestion。
但：
所有 Change：
都 Review。
不追求：
「一键全过。」
第四周：
再看：
哪几种 Field：
最稳。
哪些：
错得最多。
接着：
替：
Deal Stage。
Value。
Expected Close Date。
加入：
更清楚的：
团队规则。
一个月后，可能会发现真正要改的不是 Nova
例如：
三位业务：
自己对：
Deal Stage：
定义：
完全不同。
A：
客户说：
有兴趣：
就往前。
B：
一定等 Proposal：
才往前。
C：
等采购正式出现：
才算。
那么：
AI：
当然：
很难：
帮公司：
维持一致。
这时 AI 反而逼公司把 Sales Process 说清楚
什么叫：
Qualified？
什么时候：
进 Proposal？
什么条件：
才算：
Negotiation？
Expected Close Date：
到底：
代表：
客户希望日期？
还是：
公司合理预测？
Deal Value：
到底：
放：
List Price？
正式 Quote？
还是：
Weighted Value？
以前这些规则不清楚，也能勉强工作
因为：
大家：
都放在：
自己脑袋。
但：
要让 AI：
协助：
就必须：
变成：
可以说明。
可以验证。
可以重复的：
Rule。
这才是：
AI 导入：
最有意思的地方。
它不只省行政
也会把：
原本靠经验：
模糊运作的：
工作流程：
逼出来。
这家公司最后：
真正得到的：
可能不是：
一个：
会做 Meeting Summary：
的 AI。
而是一套：
更一致的：
Sales Process。
每一场 Meeting 都变成同一条线
会前：
知道：
现在谈到哪。
会中：
保留：
客户真正说过什么。
会后：
整理：
Next Step。
提出：
CRM Update。
高影响数据：
由人确认。
接着：
下一位同事：
再打开这笔 Deal：
看到的：
就是：
比较新的：
Context。
这对 B2B 长周期 Sales 特别重要
因为：
一笔 Deal：
不一定：
只有一个业务。
可能：
业务。
Engineer。
老板。
行政。
轮流：
加入。
只要：
中间某次：
Context：
没有留下。
下一场 Meeting：
大家：
又重新问一次。
客户：
就会开始觉得：
「你们公司到底有没有在记？」
AI 真正省掉的，是「把 Context 搬来搬去」
不是：
取代：
Salesperson：
和客户：
创建关系。
也不是：
取代：
Engineer：
做技术判断。
更不是：
让 AI：
自己：
谈价格。
答应交期。
客户最后愿意买设备
不是因为：
CRM：
填得很漂亮。
而是因为：
你：
真的理解：
工厂问题。
设备：
真的：
做得到。
报价：
合理。
交期：
可信。
出了问题：
有人：
负责。
这些：
仍然：
是人的工作。
Nova 比较适合拿走的，是旁边那些重复行政
Meeting 前：
重新找数据。
Meeting 中：
一直打 Note。
Meeting 后：
重新抄一次。
同一个信息：
从 Conversation：
再搬进：
CRM。
这些：
如果：
AI 可以：
先完成。
人的时间：
才真正回到：
客户。
所以这个案例最值得学的，不是「工业设备公司也可以用 Nova」
而是：
AI Workflow：
最适合先改：
工作前后的重复整理。
不要：
第一天：
就让 AI：
替你：
做商业承诺。
先把：
找 Context。
记录。
整理。
搬数据。
拿掉。
再看看：
真的省多少时间。
如果每星期真的拿回 5 小时
业务：
可以：
多跑：
一场工厂。
多追：
两个重要 Deal。
更仔细：
准备：
Proposal。
或者：
只是：
不要晚上：
再花一小时：
补 CRM。
这才是：
AI 把时间还给人的：
实际样子。
如果你也想知道自己的工作里，哪一步最适合先交给 AI，留言「流程」，我可以先帮你看看从哪一步开始。
今天，和 AI 一起进步一点。
每天学会一个 AI 技巧。
每天节省一点时间。
每天提升一点能力。
SasaDaily，陪你一起成长。
推荐阅读
AI 商业案例｜保险业务如何利用 AI 每天多出 2 小时？从找话题到成交追踪全面升级
今日 AI 工具｜2026/08/28：Claudeforce，把 Salesforce 直接接进 Claude，37 个 Sales Skills 帮你查 Pipeline、备会议、更新 CRM
