我是 Kota，宇鯨智能的創辦人，從 2021 年開始了一人公司，協助中小企業透過 Data / AI 技術進行數位轉型。

我特別關注想要建立新的服務模式、獲取營收的製造業。這背後需要進行大量的流程再造和數位管理，也需要藉由 AI 技術自動化瓶頸的步驟，這些是我特別擅長的領域。

看起來只差最後一哩路

前幾篇一路梳理下來，我原本規劃的 CRM 已經逐漸成形。一開始只看到客服，後來發現 B2B 業務才是主要營收來源，所以把業務流程一起納進來；接著又發現公司雖然認為商機管理重要，但實際上沒有固定的 Pipeline Review，因此前段商機紀錄暫時不強推。走到這裡，我覺得離一套可以落地的 CRM，好像只差最後一段：報價。

業務和客戶確認需求之後，要開立正式報價單。問題是，公司原本就有一套 ERP，客戶資料、商品資料和報價都已經放在裡面。業務只要在 ERP 選好客戶、加入報價品項，就可以直接套用既有的報價格式，產生一份 A4 PDF 給客戶。這套流程已經用了很久，業務也很熟悉。

如果我要讓新的 CRM 從商機一路管理到報價，勢必要和 ERP 串接。偏偏這套 ERP 沒有適合的 API。

技術上，其實不是完全沒辦法

看到沒有 API，我的第一個直覺是：「那就想辦法串。」因為這套 ERP 是 web-based，所以無論是用 RPA 模擬使用者操作，或是寫客製化爬蟲，把 ERP 裡的資料和報價檔案抓出來再同步到 CRM，技術上其實都做得到。

但真正讓我猶豫的問題開始變成：值得嗎？如果只是為了讓 CRM 的流程看起來完整，我就得多維護一套高度客製化、依賴既有 ERP 畫面與操作方式的整合。ERP 只要改版、欄位移動、畫面改掉，RPA 或爬蟲就可能需要重新調整。

這時候我面對的選擇不再是「ERP 沒 API，要怎麼串？」而是：值得不值得為了 CRM 的完整性，長期養一套這麼客製、維護成本又高的整合？

更麻煩的是，使用者也不買單

如果沒有整合，業務的工作流程會變成：CRM 記錄商機 → ERP 開報價 → 回 CRM 補報價與進度。對業務來說，原本只需要在 ERP 做一次的事情，現在變成要在兩套系統之間切換，而且報價這件事情，原本的 ERP 已經做得很好。所以從業務角度看，新的 CRM 並沒有讓這一段工作變簡單，反而增加輸入和切換系統的成本。

這讓我開始重新想一件事情：我要為了系統架構看起來完整，逼使用者改變一個原本已經好用的工作流程嗎？ 如果商機管理是非常強烈的需求，也許這個代價值得；但前面已經發現，這些商機資料並沒有被管理端固定使用。現在又發現，要把報價一起拉進來，還得付出額外的整合與使用成本，這時候「完整 CRM」的價值開始變得沒那麼理所當然。

真正有感的需求，反而出現在訂單成立之後

我後來繼續訪談業務，也要求加入業務、美編和工廠平常使用的通訊群組。進到群組後，我才發現，不但群組每天的訊息量非常大，而且我幾乎每天都會看到業務在群組裡標註某個人，詢問「這一單現在做到哪裡了？」、「這個客戶在問，可以確認一下進度嗎？」、「這個檔案好了嗎？」

被標註的人如果剛好在忙，可能過了好幾個小時都沒看到，甚至一整天沒有回覆。這時我才發現，對業務來說真正痛的事情，其實發生在訂單成立之後。印刷訂單不像一般電商，下單後隔天就能出貨；有些訂單從確認、製作印刷檔、排程到真正完成，可能要十天以上。業務是面對客戶的人，所以客戶一追進度，第一個被問的一定是業務。

但訂單進到美編和工廠之後，業務其實看不到完整狀態。現有方法只能去看 Google Sheet，可是 Google Sheet 不一定反映最新狀況，有時候資料甚至是錯的。最後最快的方法，還是直接走去問美編，或是在群組裡標註某個人。問題是，這些詢問沒有形成工作紀錄，今天某個人知道這一單發生了什麼事情，不代表其他人也知道；如果剛好有人請假，其他人甚至可能完全不知道這一單之前發生過什麼。

看到這些狀況之後，我開始重新思考需求的優先順序。前面的 CRM 商機管理，是「管理上希望有」；後面的訂單進度，則是業務幾乎每天都真的會碰到。

最後，我們把 CRM 砍掉一半

所以我最後做了一個很大的取捨。原本設計中的完整 CRM，大概想處理「客戶接觸 → 商機 → 報價 → 成交 → 訂單 → 後續執行」，最後我把前半段先切掉。商機紀錄先不做，Sales Pipeline 先不做，CRM 和 ERP 的報價整合也先不做，系統的起點直接移到訂單已經成立之後。

也就是當客戶確認報價、訂單成立，工作要開始往美編和工廠走的那一刻，才進入新的系統。接著處理客服或業務建立工作、派單給美編、美編主管分配工作、記錄處理狀態、讓業務看到後續進度、保留每一次交接的紀錄，並且讓整個 Order Fulfillment 的進度可以被追蹤。

原本想做的是 CRM，做到最後，真正留下來的核心反而變成了派單與訂單履約追蹤系統。

如果只看功能清單，這個結果其實滿奇怪的。一開始客戶找我是為了 AI 智能客服，後來我認為應該做 CRM，最後卻把 CRM 砍掉一半，做成派單與訂單履約追蹤。

我當時實際在比較的，主要是：

1. Business Value：這個功能是不是真的解決每天發生的問題。
2. Adoption Cost：第一線為了使用它，要多做多少事情。
3. Integration Cost：開發這個系統要付出多少客製整合與長期維護成本。

當我把這三件事情放在一起比較之後，完整 CRM 並不是做不出來，只是當下最值得做的，只有後半段。

這個專案也讓我留下了一個很深的印象。從 AI 智能客服，到 CRM，再到最後的派單系統，幾乎每往現場多走一步，原本認為正確的答案就會再改一次。這也得感謝客戶的信任，願意讓我走進實際工作的現場，看見文件和訪談之外的狀況。

到這裡，這套派單系統為什麼會從 AI 智能客服一路演變而來，差不多已經交代完整。下一篇我想回頭整理這整個案例：一個 AI 智能客服案，最後為什麼會變成派單系統？這幾次改變 Scope 的過程，到底和 FDE 有什麼關係？

有興趣知道更多的，也歡迎和我聯繫交流( kota@yujing.io )！