這是一個 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
