Pipedrive Nova：
現在可以在：
Sales Meeting：
結束後。
直接建議：
CRM：
要不要更新。
例如：
Deal Stage。
Deal Value。
Expected Close Date。
Contact Detail。
甚至：
Custom Field。
這很方便。
但：
最不能做的，就是看起來合理就全部 Approve。
今天只學：
一個非常簡單的：
30 秒檢查。
先看三個東西
客戶原話。
↓
CRM 現值。
↓
AI 建議。
順序：
不要反過來。
為什麼第一個一定看「客戶原話」？
因為 AI 最容易做的一件事：
就是把：
一段模糊的人話。
整理成：
一個很乾淨的欄位。
例如客戶說：
「如果預算最後過的話，我們希望月底前可以處理，大概抓 30 萬左右。」
人聽得懂：
裡面其實有：
很多不確定。
如果預算最後過。
希望月底前。
大概。
左右。
但 CRM：
喜歡的是：
乾乾淨淨的：
Value。
Date。
Stage。
這時：
AI 很可能：
自然地想：
把模糊內容：
變成：
結構化資料。
問題不是 AI 在亂寫
而是：
Conversation：
和：
CRM Field：
本來就不是：
同一種東西。
Conversation：
允許：
可能。
大概。
希望。
回去確認。
再看看。
CRM：
卻要求：
你最後：
填一個值。
所以第一步：
不要先看：
AI 建議得像不像真的。
先回到：
客戶到底說了什麼。
例如 Nova 建議把 Deal Value 改成 30 萬
先不要：
Approve。
先問：
客戶說的是：
「正式報價就是 30 萬」？
還是：
「預算大概 30 萬」？
兩句：
完全不同。
第一句：
比較接近：
已確認 Deal Value。
第二句：
可能只是：
Budget Range。
如果公司：
CRM 裡的 Deal Value：
定義是：
正式預估成交金額。
那：
到底能不能填：
就要看：
你公司的規則。
第二步：看 CRM 現值
假設：
現在 Deal Value：
原本是：
25 萬。
Nova：
建議：
30 萬。
不要只問：
「30 萬對不對？」
還要問：
「25 萬原本為什麼在這裡？」
可能：
是上一次：
正式 Proposal。
可能：
是業務：
初步估算。
可能：
是客戶：
之前確認過的 Budget。
也可能：
根本是：
三星期以前：
留下的舊資料。
現值不是一定正確
但它提供：
Context。
如果：
客戶只是：
隨口說：
「預算大概 30 萬左右。」
而 CRM：
現在：
25 萬：
是：
昨天才寄出去的正式報價。
那你：
就不應該：
因為 AI 聽到：
30 萬：
直接把正式欄位：
蓋掉。
Pipedrive 已經把這個比較直接做進 Nova
Nova：
會把：
目前 Pipedrive 的值
放在：
AI 建議值
旁邊。
讓你：
直接比較。
不是：
AI 說：
「請改成 30 萬。」
你就只能：
Accept。
你可以：
看：
Before。
After。
再決定：
Approve。
Edit。
或：
Skip。
更重要的是：如果 CRM 在 Nova 產生建議後又被別人改過
Pipedrive：
還會：
標示：
這個欄位：
已經發生變化。
這個細節：
非常重要。
因為多人團隊：
最容易發生：
Meeting：
上午結束。
Nova：
產出建議。
下午：
另一個業務。
或 Manager：
已經更新：
CRM。
晚上：
你才回來：
Review Nova。
如果：
沒有提醒：
你可能：
把：
比較新的資料：
又蓋回：
舊的 AI 建議。
所以第二步不是只看「Nova 想改什麼」
而是看：
現在正式紀錄到底是什麼。
這就是：
Current Value。
第三步：才看 AI 建議
現在：
才問：
Nova：
想改成什麼？
然後：
把它和：
客戶原話。
CRM 現值。
一起看。
這時：
通常只有三個結果。
Approve。
真的清楚。
可以寫進去。
Edit。
方向對。
但：
數字。
日期。
或：
欄位內容：
需要修正。
Skip。
這段對話：
根本還不足以：
改正式紀錄。
Deal Stage 最容易被誤判
例如：
客戶說：
「內容看起來沒問題，我還要回去讓 CFO 看一下。」
AI：
可能認為：
Deal：
已經：
向下一階段前進。
但：
你公司的 Pipeline：
可能規定：
只有：
Decision Maker：
正式批准。
才能：
進下一 Stage。
那麼：
「內容看起來沒問題」
根本：
還不夠。
Stage 不是情緒
客戶：
很熱情。
不是：
一個 Stage。
客戶：
說：
「很有興趣。」
也不是：
一個 Stage。
真正的：
Stage：
應該對應：
公司自己的：
可驗證條件。
例如：
需求已確認。
正式 Proposal 已送。
決策者已加入。
Budget 已核准。
Contract 已簽。
每家公司：
不一樣。
所以可以直接替 Nova 寫欄位規則
Pipedrive：
允許使用者：
針對不同 CRM Field：
設定：
Instruction。
例如：
告訴 Nova：
Expected Close Date：
要怎麼判斷。
Currency：
怎麼解讀。
哪些語句：
才足以：
更新某個 Field。
這非常值得用。
不要讓每一位業務自己猜「什麼算成交階段」
如果：
公司有五位 Sales。
每個人：
對 Stage：
定義不同。
AI：
也很難：
替你保持一致。
最好的方法：
不是：
一直要求：
Nova：
「判斷準一點。」
而是：
先把：
公司規則：
寫清楚。
例如可以這樣定義 Expected Close Date
不是：
客戶只說：
「希望下個月。」
就直接：
填：
下個月底。
而是：
只有客戶：
明確提出：
目標日期。
或：
公司內部：
依正式 Project Timeline：
已有明確預估：
才更新。
否則：
保留現值。
這不是：
Pipedrive 官方規定。
而是：
你可以依：
自己的 Sales Process：
設計的 Rule。
Expected Close Date 為什麼特別不能亂填？
因為：
它不只是：
一個備忘。
在 Pipedrive：
Forecast View：
會用：
Expected Close Date：
來安排：
Revenue Projection。
也就是：
如果：
AI 把：
「希望十月完成」
直接：
整理成：
一個確定 Date。
Management：
看到的 Forecast：
也可能：
跟著移動。
所以一個看起來很小的 AI Update
最後：
可能影響：
整個 Pipeline：
怎麼被理解。
這就是：
為什麼：
高影響欄位：
Review：
不能只花：
零點五秒。
Deal Value 也是一樣
客戶：
談到：
30 萬。
不代表：
Deal Value：
一定：
30 萬。
可能是：
Budget。
可能是：
上限。
可能是：
一個 Package。
可能：
還不包含：
另一項 Service。
AI：
沒有公司內部規則：
很難知道：
你真正希望：
這個 Field：
代表什麼。
所以今天這個三步法，真正是在問「證據夠不夠」
第一：
客戶原話。
真正說了什麼？
第二：
CRM 現值。
目前正式紀錄是什麼？
第三：
AI 建議。
為什麼要改？
如果：
三個放在一起：
還看不出：
為什麼：
這個欄位現在應該變。
就：
先不要變。
還有一個 Nova 很重要的限制：CRM Update Suggestion 主要依據 Meeting Transcript
Pipedrive：
特別說明：
Nova：
產生 CRM Update Suggestion：
是根據：
這場 Meeting Transcript。
同步進：
Pipedrive：
的 Email：
不會：
成為這個 CRM Update Suggestion：
的來源。
這個限制：
非常容易被忽略。
例如客戶會議中說：「我們考慮 30 萬」
兩個小時後：
又寄 Email：
正式確認：
最後採購：
只有 22 萬。
如果：
你晚上才：
Review Nova：
不能因為：
Pipedrive 裡：
也已經同步：
那封 Email。
就以為：
Nova：
提出 CRM Update 時：
一定有：
一起看。
沒有。
所以 AI 有資料，不代表這次推理用了全部資料
這是：
所有 AI 工作流：
都很重要的一個觀念。
Pipedrive：
可能同時：
有：
CRM。
Email。
Calendar。
Meeting。
但：
不同 Feature：
使用：
不同 Source。
Pre-call Brief：
可以使用：
更多 CRM Context。
CRM Update Suggestion：
則以：
Meeting Transcript：
作為來源。
不要：
全部混在一起理解。
如果會後又發生重大變化，先處理最新資訊
例如：
客戶：
會後 Email：
改價格。
改時程。
取消需求。
或：
正式確認。
那麼：
真正要更新 CRM：
應該：
依：
最新已確認資訊。
不是：
為了：
把 Nova Suggestion：
全部清空：
而全部 Accept。
Nova 的建議不是待辦清單
不是：
看到：
5 個 Suggested Update。
就代表：
你今天：
一定要：
Approve 5 個。
正確答案：
完全可能是：
Approve 2 個。
Edit 1 個。
Skip 2 個。
這才是：
Human Review：
真正有意義的地方。
還可以把欄位分成「低影響／高影響」
例如：
客戶電話：
如果在會議裡：
明確重新提供。
通常：
比較容易核對。
但：
Deal Stage。
Deal Value。
Expected Close Date。
這些：
一改：
就會影響：
Pipeline。
Forecast。
Sales Management。
就應該：
看得更慢。
不需要所有欄位都用同一個 Review 標準
這也是：
AI 工作流程：
很重要的觀念。
不是：
所有 AI 建議都要人工逐字重做。
也不是：
所有 AI 建議都直接 Accept。
而是：
風險：
不同。
Review：
深度：
也不同。
低風險欄位，確認後快速通過
高影響欄位：
回：
Transcript。
看：
原話。
看：
現值。
再：
決定。
這樣：
才真的：
同時得到：
效率。
和：
Control。
你甚至可以用 10 場 Meeting 測自己的 Review Rule
不要：
第一天：
就假設：
Nova：
很準。
選：
10 場：
一般 Sales Meeting。
記：
它：
對：
Deal Stage。
Value。
Close Date。
各提出：
多少次建議。
最後：
你：
Approve 幾次？
Edit 幾次？
Skip 幾次？
這比問「Nova 準不準」有用很多
因為你最後可能發現：
Contact Detail：
幾乎都：
可直接接受。
Deal Value：
大部分：
需要人工改。
Expected Close Date：
最容易：
把「希望」整理成：
確切日期。
那麼：
你的 Review Process：
就可以：
跟著調整。
接著再把經常出錯的欄位規則寫進 Nova
例如：
如果：
「大概。」
「希望。」
「可能。」
「預計。」
這些語氣：
不能：
單獨作為：
正式 Close Date：
依據。
就：
把規則：
寫進：
該 Field Instruction。
AI：
會更知道：
公司真正想要：
怎麼解讀。
但 Field Instruction 也不是保證
它只是：
提高：
一致性。
Meeting Transcript：
仍然可能：
轉錯。
Speaker：
可能：
辨識錯。
客戶：
本來就：
可能：
講得模糊。
所以：
真正重要的欄位：
仍然需要：
最後一眼。
今天只記一個動作就夠了
Nova：
會後跳出：
CRM Update Suggestion。
不要：
先看：
Approve。
先看：
客戶原話。
再看：
CRM 現值。
最後：
才看：
AI 建議。
因為 AI 最擅長把模糊資訊整理得很乾淨
問題是：
現實世界：
本來就：
沒有那麼乾淨。
「有興趣」
不等於：
成交。
「大概 30 萬」
不等於：
正式 Deal Value。
「希望月底」
不等於：
確定 Close Date。
「我要回去確認」
更不等於：
Stage：
已經前進。
CRM 最重要的不是欄位填得快
而是：
欄位代表的事情是真的。
AI：
可以：
把：
找資料。
整理會議。
提出更新。
這些：
重複工作：
先拿走。
最後：
人只需要：
做一件真正值得做的事：
判斷這個變更，現在到底成立了沒有。
如果你也想知道自己的工作裡，哪一步最適合先交給 AI，留言「流程」，我可以先幫你看看從哪一步開始。
今天，和 AI 一起進步一點。
每天學會一個 AI 技巧。
每天節省一點時間。
每天提升一點能力。
SasaDaily，陪你一起成長。
推薦閱讀
AI 一分鐘教學｜2026/09/12：Plaud Agent 產出簡報前，先分「已確認／AI 整理／待決定」三層
AI 快問快答｜2026/09/12：Plaud Agent 做出的 PPTX 已經引用會議 Context，就可以直接寄給客戶嗎？
今日 AI 工具｜2026/08/28：Claudeforce，把 Salesforce 直接接進 Claude，37 個 Sales Skills 幫你查 Pipeline、備會議、更新 CRM
