本系列取材自真實經歷，人物、場景、對話與時間順序經過合成與小說化處理。文中假設案例與示意數字用於說明觀念。

我到管理室時，師父的晚餐吃到一半。許小姐來領件，他把餐具放好，起身核對資料，拿出包裹請她簽收。

許小姐看見餐盒，說不好意思打斷吃飯。師父回她沒關係，把收件紀錄補完才坐回去。我原本打算改天再聊，他說可以邊吃邊聽，我便把今天想到的問題說出來。

「假設有個大客戶跟你說，產品很有興趣，先免費試半年，效果好就買。你會答應嗎？」

師父問：「他要用這半年確認什麼？」

試用的長度，要對應要取得的答案

我說，大概就是確認產品好不好用。師父笑了一下，說這個答案太寬了。以客服草稿工具為例，是要看回覆能不能用、整個團隊能否導入，還是觀察一個特定旺季的工作？不同目的需要的時間和投入不同。

如果只是讓幾位客服操作，確認典型問題能不能處理，未必需要半年。若真的要跨過某個業務週期，就得知道期間內有哪些階段，不能前五個月都沒人用，最後才說還需要更多時間。

我問：「那免費試用和 pilot 有什麼差別？」

師父說，名稱也得看雙方怎麼約定。一般試用帳號可能讓使用者自行操作現成功能；pilot，也就是試點合作，通常會選定範圍，在具體工作環境驗證是否適合導入。若需要工程師協助資料、串接和結果分析，就要把這些服務一起談，不能以為開了一個帳號就完成。

試點可以付費，也可以在明確條件下不收費。付款本身不會自動讓驗證有效，免費也不代表一定沒有價值；更重要的是兩邊實際投入什麼，以及結束後要做哪個決定。

把成功條件和對方要投入的事情寫出來

師父用一個四週的假設試點說明。雙方先選一類客服詢問，由兩位指定使用者操作；客戶提供經允許使用的資料和現有處理方式，產品團隊協助設定。每週確認遇到的問題，最後一起比較處理時間和回覆品質。

我問：「成功條件是不是寫節省百分之幾就好？」

師父說，要知道怎麼量。從收到問題到最後送出，中間如果包含主管等到隔天才批准，就不能只用模型產生草稿的幾秒鐘說明整體改善。可以把不同工作段落分開，讓大家知道改善發生在哪裡。

品質也要一起看。如果速度快了，但更常出現需要更正的政策內容，就不能直接宣布成功。應該先約定哪些錯誤不能接受，哪些修改屬於正常編輯，以及誰負責判讀。

我追問：「那客戶要是一直不給資料，時間還是照算？」

師父回答，這就是雙方投入要先說清楚的原因。資料沒到、使用者沒有時間，或測試環境還不能用，都會影響試點。可以約定如何調整日期，但也要重新確認對方是否真的有條件進行，不能只把期限一直往後推。

結束時要做決定，延長也要有理由

師父拿起餐盒，吃了幾口。我看他有空再說，便問試點結束之後，客戶一句「再看看」要怎麼辦。

師父說，開始以前就應該知道誰會參與結果討論。使用者確認操作，主管判斷工作成果，採購或預算負責人則需要知道正式導入的條件。若一開始完全沒有找對人，做完才出現另一位主管說這不是現在的重點，就很難接下去。

假設結果達到約定目標，可以討論正式導入的範圍、價格和時程；若沒有達到，就一起看缺口；如果資料不足，則要指出還缺哪項證據、需要多少額外投入。延長本身可以合理，但必須知道這次延長準備回答什麼。

我問：「小公司怕失去大客戶，真的有辦法這樣談嗎？」

師父說，可以讓步，也可以分階段投入。例如先用現成功能完成小範圍試用，確認適合之後，再安排需要工程時間的整合。若一開始就答應半年免費客製、隨時支援，團隊可能還沒確認對方會不會買，就先承擔一份長期工作。

我說：「客戶可能會覺得你很計較。」

師父回答：「把要做的事講清楚，對方也比較知道要安排誰。一直說都可以，他也不知道你到底會交什麼。」

他把剩下的飯吃完，才補充今晚的重點：試點要有目的、期間、雙方投入和結束後的決定。 四週只是剛才的示例，半年也不必先判死刑；真正需要問的是，這段時間會產生什麼足以支持下一步的資訊。

毫無目的的免費半年可能只是浪費雙方時間。