「這個功能我們早就有了」，然後呢？

看到別家公司發布新功能，做產品的人難免會冒出一句：

「這個，我們早就有了。」

我也能理解這種心情。團隊花時間做出來的東西，直到別人開始宣傳，市場才突然注意到，好像先前的努力沒有被看見。

但換到客戶的位置，問題其實不太一樣。

他不一定在意誰先做。他更想知道：這跟我的工作有什麼關係？能省掉什麼麻煩？我要花多少力氣，才知道它到底有沒有用？

功能做出來，是產品的進度；有人願意試、願意留下來用，才是市場的接受。

客戶要的不是另一個對話框

想像一個情境：週一的營運會議結束，主管想在週五前準備一個回購活動。這是用來說明工作方式的假設情境，不是客戶成效案例。

他要的不是「研究一下 AI」，而是先找出適合聯繫的客人、確認優惠條件，再把訊息準備好。

這時候，他看到兩種產品介紹。

第一種說：「我們的 CRM 也有 AI 對話框。」

第二種直接演示：「先問一個訂單問題，再看系統能幫你準備哪些活動草稿；哪些地方要補資料，也一起看。」

對我來說，後者比較接近客戶正在做的事。不是因為功能一定比較強，而是他比較容易判斷：這跟我有沒有關係。

「你可以直接用聊天的方式查資料。」這句話說明了操作方式，卻還沒有說清楚工作會變得怎麼樣。

換成一個營運主管熟悉的問題，可能就具體多了：

「哪些客人最近沒有回來買？」 「他們以前買過什麼？」 「如果想做一次回購活動，可以先幫我準備什麼？」

這時候，值得討論的就不是畫面上有沒有聊天框，而是原本要查資料、整理名單、構思活動的工作，有哪些真的能少做一點。

就像 metabiz mCRM 的操作畫面裡，從詢問訂單狀況，到準備優惠券、訊息與群發草稿，呈現的是一段工作，而不只是一個回答。

但畫面展示仍不等於成效證明。草稿能不能用、需要改多少、資料是否符合這家公司的情境，還是要實際確認。

我們應該把這些說清楚，而不是只說「我們也有 AI」。

圖一｜做出功能與持續使用之間，還有幾個需要被回答的問題。這是本文的分析框架，不是市場轉換率統計。

前篇從訂單提問到活動草稿談的是這段工作如何呈現。這一篇，我想再往前問一步：如果客戶還沒開始用，我們要怎麼讓他走進來？

「你試試看就知道了」，其實沒有那麼輕鬆

做產品的人，很容易把「試用」想得太簡單。

開個帳號，點幾個按鈕，好像沒什麼成本。

但對一個正在忙的主管來說，他可能得先弄懂介面、找資料、問同事資料在哪裡，再花時間判斷 AI 的答案對不對。

如果還要串接系統、調整格式，或請另一個部門配合，這已經不是隨手試一下，而是一件要安排時間的工作。

就算軟體免費，這些時間也不是免費的。

圖二｜試用要算整段工作，不只算 AI 產出那幾秒。圖中列的是成本項目，沒有假設任何節省比例。

更麻煩的是，試完發現不適合，時間不會退回來。

所以，當客戶沒有開始使用，我不會直接把它解讀成「他不懂 AI」，或「他不願意改變」。

也可能是我們要求他先付出的力氣，比他目前看得見的好處還多。

能不能先讓他完成一件小事？

我認為，更值得設計的不是更長的功能清單，而是更輕鬆的第一次體驗。

例如，先不用註冊，就能看懂一段完整示範：從提出營運問題，到取得資料，再到產出可以修改的活動草稿。

不是只有漂亮的答案，也看得到哪些地方需要補資料、哪些步驟還沒執行。

如果覺得跟自己的工作有關，再進入準備好的範例環境，換個條件、問個問題，看看結果怎麼變。這個階段不必整理自己的資料，也不會真的發訊息給客戶。

等到願意進一步確認，再用一小份去識別化的資料，測試一個明確問題，而不是第一天就搬進整套系統。

這是我認為值得設計的試用方式，不是宣稱 metabiz 目前已經把這些入口全部做好。

圖三｜逐步增加投入，每一步先回答一個問題。這是建議的體驗設計，不是已上線功能清單。

重點是：每往前一步，都先讓客戶知道多付出這一點時間，可以確認什麼。

第一次不用證明所有價值

一次小測試，不需要證明整家公司都該換系統。

回到那個週五前要準備好的回購活動，我會把第一次測試縮成這樣：

先準備一份可檢查的活動草稿，不急著真的發送。

如果測試環境支援，就用範例資料或一小份去識別化資料，固定期間與訂單狀態，先確認查詢結果，再準備活動訊息。缺少必要欄位，就先列出缺口；不要讓 AI 把沒有的資料補成答案。

最後拿這份產出，和原本的工作方式比較：

要確認的事	原本的做法	測試時記下什麼
找到可用資料	查報表、篩選、整理	連同資料準備，共花多久？
確認對象與條件	人工檢查期間、狀態與名單	有沒有漏掉、選錯，或需要重查？
準備活動	填優惠條件、寫訊息	草稿能沿用多少？修改花多久？
交給下一位同事	說明設定與待確認項目	對方能否接手，還要補哪些資訊？

這不是一張預先寫好答案的 ROI 表。測試前沒有數字的格子，就留白，做完再填。

比較時也要用相同資料範圍與完成標準。如果原本算到「可以交付」，新方式卻只算到「AI 吐出第一版」，看起來省下的時間就不公平。

如果沒有比較輕鬆，就要承認這次測試還沒有證明價值。

如果有，也不必立刻放大成「大幅降本增效」。少花一些整理時間，是釋放工作量；是否減少實際支出、帶來更多訂單，是後面要另外驗證的事。

讓客戶容易開始，也應該讓他容易判斷不適合、容易停下來。

這不是降低產品的價值，而是尊重他嘗試的成本。

如果試完還是不想用，先看卡在哪裡

有時候，問題不是功能不好，而是第一次體驗要求太多。

看不懂用途，就先改示範；資料難準備，就先縮小範圍；草稿需要全部重寫，就回頭檢查產出品質。不是每個問題，都該用「再教客戶一次」解決。

我會在測試前先約定：這次只完成哪一件事、願意投入多少準備時間，以及什麼情況就先停下來。資料不足或結果不可用，本身也是有效的測試結論。

讓客戶知道可以停，才不會把「試一下」變成一個不好意思退出的導入專案。

被看見之後，還要讓人走得進來

回頭看，「這個功能我們早就有了」並不是完全沒有意義。它代表團隊曾經投入，也可能有值得累積的經驗。

但它不能替客戶回答：為什麼我現在值得花時間試？

對我來說，下一步不是更大聲地證明誰先做，而是把功能放回工作裡，把第一次嘗試變得具體、輕巧，而且有結果可以判斷。

市場看到你，是一個開始。

讓一個原本不認識你的人願意說：

「這件事剛好困擾我，而且試一次，好像沒有那麼麻煩。」

才有機會走到真正的接受。

如果你也想從一件小事開始，可以和我們聊聊目前最想少做的一段工作，先討論適用範圍與需要準備的資料，不必一開始就決定導入整套系統。

---

本文為 Adam 的產品與市場觀點，非市場排名或成效實測。mCRM 的功能描述以 Adam 提供的操作畫面為背景，相關脈絡見從訂單提問到活動草稿的前篇觀點；畫面不代表已完成效能或營收驗證。回購活動情境與低門檻測試流程為說明及設計建議，不代表全部已上線。三張內文圖解由 metabiz 依本文整理，非產品截圖；封面為 AI 生成情境插畫。