Salesforce 導入：成本、時程與失敗模式

一個 Salesforce 導入案，是以一行授權費被核准的，卻是以一個大型專案被交付的。授權那一行是公開的，按使用者、按月計算，寫進董事會文件裡也很好辯護。把這些授權變成一套真的有人用的系統，所需的一切都在那一行之外，而正是這個部分決定了商業計畫裡的那個數字能不能撐過第一季。

Salesforce 以英鎊公開英國價格。Sales Cloud Enterprise 按年付費時是每位使用者每月 £140，Unlimited 是 £280。五十位 Enterprise 使用者就是每年 £84,000，而此時還沒有人設定過任何一個欄位。對於把這個組織送上正式環境的服務，我們的內部估算是首年授權支出的 1 到 3 倍，落在區間的哪個位置並不是隨機的。有四件事會推動它，其中只有一件是技術性的。

接下來最重要的一個詞是採用。因為一套技術上完全正確、卻沒有人使用的系統，不是部分成功。它是全損，而且還附帶一張維護帳單。

一個 Salesforce 導入要花多少錢？ 授權通常是比較小的那一半。Salesforce 在英國給 Sales Cloud Enterprise 的標價是每位使用者每月 £140，五十位使用者就是每年 £84,000，而我們對其上導入服務的內部估算是首年授權支出的 1 到 3 倍。推動這個倍數的是：需要串接的系統數量、來源資料的狀態、流程客製的程度，以及這家機構願不願意改自己的流程去配合產品。

一個 Salesforce 導入到底包含什麼

一個 Salesforce 專案有六條成本線，而定價頁上只出現其中一條。

第一條是授權，按使用者、按月，公開標價。第二條是導入服務，也就是那些設定組織、建置設定做不到的東西、並且推動專案的顧問與開發者。第三條是資料移轉，它在導入裡被當成一項工作來估算，實際表現卻像一個獨立的專案。第四條是整合串接，把 Salesforce 接到那些已經存著你資料的系統上。第五條是教育訓練與變革管理。第六條是持續的日常管理，它從來不會出現在商業計畫裡，因為它在其他所有帳單都付清之後才開始。

一份只寫了授權的商業計畫，不是錯了一點點。常見的偏差是兩到四倍，而這個差距幾乎全部落在第三、第五和第六條上。

授權是那個小數字

Salesforce 的英國 Sales Cloud 價格是公開的，並且以英鎊標價。

Starter Suite 是每位使用者每月 £20。Pro Suite 按年付費是 £80。英國中端市場買方最常落到的 Enterprise 是 £140，因為它是第一個帶 Web API 的級距。Unlimited 是 £280，並且包含一個 Full sandbox 與 Premier Success Plan。Agentforce 1 Sales 訂在 £440。若單獨購買，Premier Success Plan 的價格是淨授權費用的 30%。

由此有兩點。從 Pro Suite 跳到 Enterprise，每位使用者每月要多付 £60，五十位使用者就是每年 £36,000，而這一跳往往是被某一項串接需求逼出來的，而不是業務團隊要過的任何功能。另外，支援方案是一個百分比，所以它隨授權帳單成長，而不是隨你實際用掉的支援成長。

服務與授權的比例，以及推動它的因素

真正能拿來規劃的數字不是人天單價，而是首年服務費用與首年授權支出的比例，因為這個比例穩定到足以拿出來爭論。

以下是我們從英國中端市場專案裡得出的內部區間。一個接近原生的單雲上線，資料乾淨、沒有串接，大約落在首年授權支出的 0.5 到 1 倍。一個典型的導入，有兩三個串接、適量的自訂物件與自動化，落在 1 到 3 倍。一個多雲專案，帶著舊系統資料、五個或更多串接與大量流程客製，會跑到 3 到 5 倍，有時更高。這些是我們的估算，不是公開數據；如果有合作夥伴報出一個所謂業界固定比例，應該問清楚它從哪裡來。

套到 £84,000 的例子上，下限是 £42,000，中間是 £84,000 到 £252,000，上限是 £252,000 以上。這個跨度本身就是全部的故事。一個只聽過大概跟授權差不多的買方，其實是把錨點放在了一個兩端相差十倍的區間的中點上。

推動這個比例的四個變數

只有四件事能可靠地把一個 Salesforce 專案從一個區間推到下一個區間，而每一次範圍討論都應該在有人報數字之前把這四件事確認清楚。

第一是需要串接的系統數量。每多一個，就是一套獨立的設計、一組獨立的憑證、一條獨立的錯誤路徑，以及在對方廠商發版時會壞掉的另一個東西。串接的成本不是相加，而是比相加略差一點，因為失敗模式是相乘的。

第二是來源系統裡的資料品質。不是資料量，是品質。下面會專門展開，因為它是整個專案裡被低估得最穩定的一條。

第三是流程客製的程度，也就是目標設計離產品裝好即用的樣子有多遠。

第四是這家機構願不願意改自己的流程去配合產品。這是對成本與成敗預測力最強的單一因素，卻幾乎沒有人把它納入範圍討論，因為這是一個關於人的問題，卻出現在技術評估的場合。

改變的意願是一個範圍問題

一家把自己的業務流程調整成 Salesforce 商機模型的機構，得到的是一套便宜、可升級、支援良好的系統。一家堅持要 Salesforce 複刻它現有試算表的機構，得到的是一套昂貴、而且每次版本更新都要打一架的系統。

在需求訪談階段，線索就在措辭裡。當一位關係人說，我們需要系統照我們的方式運作，客製預算就要翻倍了。當一位關係人說，先給我看它本來應該怎麼運作，並且告訴我為什麼，預算就要減半了。這兩句話都合情合理。便宜的只有一句。

處理這件事的誠實做法是給它標價。在提案裡放兩個數字，一個是標準模型的，一個是客製的，讓差額去說話。當一個買方看到，一套階段命名慣例要花 £18,000 的自訂自動化外加長期的升級風險，他通常會去改命名慣例。而一個只被告知這我們做得到的買方不會。

需求訪談，以及一次好的訪談會產出什麼

需求訪談是最常為了拿下案子而被砍掉、事後又最常被檢討的階段。一次只產出簡報的訪談，是一次業務活動。一次產出四份成果物的訪談，才是一次工程活動。

第一份是流程圖：一條潛在客戶變成營收所經過的實際步驟順序，標出決策點與負責這些決策的人，而且是從觀察實際工作得來的，不是靠請主管口述。

第二份是資料模型：物件、欄位、關聯、選項清單的值，並且每個欄位都要有一位具名的人負責維護。沒有歸屬的欄位，最後會變成沒人填的欄位。

第三份是串接清單：每一個向 Salesforce 送出資料或從中接收資料的系統，連同方向、資料量、頻率、用來關聯記錄的識別碼，以及連線失敗時會發生什麼。

第四份是一個可衡量的完成定義。不是業務團隊正在使用 Salesforce，而是類似這樣：本季結案的商機中有 90% 填了負責人設定的結案日期、金額與階段，而且每週的管道會議直接從 Salesforce 儀表板上開，會議室裡不出現試算表。

在競標流程中，軟體 RFP 指南可以直接套用：問每一個投標方訪談會產出什麼，然後淘汰那些說不出成果物名稱的。

時程是在資料移轉裡消失的

移轉的報價是按建置費用的一個百分比給出的，消耗掉的卻是它的好幾倍，原因是一個誤解：團隊按記錄筆數來估算，而移轉工作量是隨來源資料品質變化的。

從一個維護良好的系統裡搬 200 萬筆乾淨的記錄，帶著可靠的主鍵，認真做一週就夠了。而把散在一套舊 CRM、三份地區試算表和一個會計套件裡的 4 萬筆記錄搬過來，沒有共同識別碼，備註欄位裡還塞著十一年的自由文字，那要兩個月，而且上線時依然是錯的。後一個工作記錄數只有五十分之一，工作量卻是八倍。

在承諾任何事之前先剖析來源資料

剖析就是在你同意一個日期之前先把東西數清楚。對每一個來源系統都做，而且要在提案裡的移轉那一行被簽字之前做。

按欄位數空值。對每一個你打算做成選項清單的欄位，數不同值的個數，因為一個有 340 個不同值的國家欄位不是選項清單，那是一個清理專案。數一數有多少筆記錄共用同一個候選鍵。量測日期、電話號碼與郵遞區號的格式一致性。數一數那些沒有負責人、沒有電子郵件、三年沒有任何活動的記錄，因為當你提議把它們留下時，沒有人會站出來替它們說話。

在一個中等規模的資料資產上，剖析要花兩到五天。這是整個專案裡最便宜的風險削減手段，而跳過它，正是移轉估算只會朝一個方向出錯的原因。

去重，以及平台給你的規則

Salesforce 有原生的重複管理，而它的限制會形塑你的設計。你可以為每個物件設定最多五條啟用的重複規則與一條啟用的比對規則，在使用多條重複規則時，每個物件啟用的比對規則可以增加到五條，而每條重複規則最多可以引用三條比對規則。

有兩個行為比這些數量更重要。比對鍵會在套用比對算式之前，把比較範圍縮到最可能的 100 筆重複記錄，所以一筆真的有超過 100 個近似比對的記錄不會被完整評估。而且這些規則在幾條常見路徑上根本不會執行，包括快速建立，以及在沒有啟用 Apex 潛在客戶轉換的情況下做 Lead 轉換，這正是一個已經打開重複規則的組織裡仍然出現重複記錄的原因。

所以去重是一項移轉工作，要在載入之前於暫存資料上完成，而不是一個你打開就不用管的執行期功能。原生規則是第二道防線。

external ID，以及 upsert 為什麼勝過 insert

每一個搬過來的物件都需要一個 external ID：一個帶索引的自訂欄位，用來保存來源系統的主鍵。這是整個移轉設計裡價值最高的單一決定，而且做出這個決定不花一毛錢。

有了 external ID，你就可以使用 upsert，它用這個欄位來決定是建立還是更新一筆記錄。如果這個值沒有比對到，就建立一筆記錄；如果比對到一次，就更新這筆記錄；如果比對到不只一次，回傳的是一個錯誤而不是一筆重複記錄。這讓每一次載入都成為冪等的，也就是說你可以跑兩遍而不會讓資料翻倍，也就是說你可以彩排。

有兩個細節會咬人。只有當欄位帶有唯一屬性並且勾選了不區分大小寫選項時，按 external ID 比對才不區分大小寫，否則 ABC123 和 abc123 就是兩筆不同的記錄。另外，如果這個欄位是一個沒有唯一索引的 external ID，執行載入的帳號需要檢視所有資料的權限。

搬歷史，還是搬有用的東西

預設的要求是全部搬過來。它幾乎總是錯的，而且會在三個各自獨立的地方讓你多花錢。

它花掉移轉工作量，因為最舊的資料最髒，占用的清理時間與它的價值完全不成比例。它花掉儲存空間，而儲存空間是一條真實的成本線：Enterprise、Professional 與 Unlimited 組織拿到的是10 GB 資料儲存空間外加每個使用者授權 20 MB，所以五十位 Enterprise 使用者合計是 11 GB，不是每人 11 GB。它還花掉採用率，因為一套塞滿死記錄的系統，會訓練使用者不要相信搜尋結果。

站得住腳的做法是：進行中與近期的記錄整批搬移，已結案的記錄只搬業務真正拿來做報表的那段期間，其餘的封存到某個還讀得到的地方。留著你根本用不上的個人資料是負債而不是資產，所以在這件事上，儲存空間的理由與法遵的理由難得地指向同一個方向。

設定還是程式碼

Salesforce 裡的每一個需求都可以用宣告式方式、用程式碼、或者兩者混合來滿足，而這個選擇決定了這套系統在未來十年裡的持有成本。就算你從不打開程式編輯器，這個區分也值得清楚地記住。

什麼應該走宣告式

宣告式的意思是用設定做出來：物件、欄位、頁面版面配置、驗證規則，以及 Salesforce 的視覺化自動化建構工具 Flow。它由管理員修改，因為執行環境歸 Salesforce 所有，所以它能撐過平台升級，而且任何有相應權限的人都看得到它。

Salesforce 自己的記錄觸發自動化決策指南給出了一個可用的門檻。它從三個維度衡量自動化密度：一次資料變更會觸發多少個自動化、每筆交易的記錄量，以及下游更新會往關聯物件串連多遠。低密度，也就是少於十五個自動化、每批 1 到 200 筆記錄、最多一次下游寫入，應該用記錄觸發的 Flow。

同一份指南還給出了一條比這份清單上任何一條都更省錢的規則：每個物件只用一個進入點。在同一個物件上混用 Flow 與 Apex 觸發器，正是執行順序缺陷變成永久問題的原因。

什麼時候該寫自訂程式碼

中等密度屬於混合模式，由 Flow 編排、可呼叫的 Apex 承擔重活，這樣順序仍然看得見，而運算落在一個可測試的地方。高密度就直接屬於 Apex 觸發器，因為到那個程度，你是在用宣告式工具建一套它本來就不是為此設計的系統。

當邏輯真的複雜、當它需要被認真地做單元測試、當同一個操作被多個進入點呼叫因而只應該存在一份時，程式碼同樣是對的。如果這部分工作你打算委外而不是自己招人，我們的軟體開發服務正是為這條邊界而存在的，也就是平台到此為止、客製工程從此開始的地方。

術語會變，而舊術語是一個警訊

Salesforce 會淘汰工具，而一份按已淘汰工具寫成的提案，會告訴你它實際上是什麼時候寫的。Salesforce 已經在 2025 年 12 月 31 日停止支援 Workflow Rules 與 Process Builder。現有規則還會繼續執行，但沒有客戶支援，也沒有缺陷修正，官方建議的路徑是用 Migrate to Flow 工具搬到 Flow Builder。

每種選擇的長期成本

宣告式的東西建置更便宜、修改也更便宜，它的代價是稀釋：一百個沒有文件的 flow 會變成一套沒有人能預測儲存一筆記錄會發生什麼的系統。

程式碼建置更貴，但在規模上去之後推理成本要低得多，因為它可以被閱讀、被版本管理、被測試。它的代價是需要開發者，而一家既沒有 Salesforce 開發者、也沒有維護合約的機構，最終會沒有能力修改自己的系統。

代價最高的失敗不是上面這兩種。它是一套完全用宣告式方式做起來、而做它的合作夥伴隨後就走了的系統，留在一個沒有文件、也沒有具名負責人的組織裡。一切都在運作，而沒有任何一樣能被安全地修改，這和無人維護的客製軟體是同一個處境，我們在軟體維護到底要花多少錢那篇文章裡寫得很詳細。

串接，以及限制為什麼會改變架構

串接這件事，我們在Salesforce 整合的限制與真實成本那篇文章裡單獨談過。屬於這裡的重點是：平台限制是架構的輸入條件，而不是到第九週才發現的維運細節。

形塑架構的主要是兩個限制。Enterprise Edition 組織的 API 請求總配額是每 24 小時 100,000 次呼叫，再加上授權數量乘以每種授權類型所帶的次數，Salesforce 授權是 1,000 次，再加上另外購買的加購包。Salesforce 自己給的算例是：一個有 15 個 Salesforce 授權的 Enterprise 組織可以拿到 115,000 次請求。這個配額是組織層級的，不是按使用者分的，而且在正式環境裡，執行 20 秒或更久的同時進站請求上限是 25 個。

第二個是 Apex 調控器限制，按交易強制執行：同步 100 條、非同步 200 條 SOQL 查詢，SOQL 取回的記錄 50,000 筆，DML 陳述式 150 條，DML 處理的記錄 10,000 筆，堆積記憶體同步 6 MB、非同步 12 MB，CPU 時間同步 10,000 毫秒對非同步 60,000 毫秒。

一個無視這些限制的設計，會在二十筆記錄上通過使用者驗收測試，然後在第一次真實的夜間載入時掛掉。那不是缺陷，那是一個按預設值做出的架構決定。

環境，以及一次 sandbox 重新整理會毀掉什麼

Salesforce 給你四種儲存空間與重新整理間隔各不相同的 sandbox，而選錯組合是一個會很晚才浮出水面的排程錯誤。

Developer sandbox 有 200 MB，每天可以重新整理一次。Developer Pro 有 1 GB，同樣每天可以重新整理。Partial Copy 有 5 GB，會按範本定義複製一份正式資料的樣本，每五天重新整理一次。Full 是正式環境的副本，每 29 天重新整理一次。Enterprise Edition 包含 25 個 Developer sandbox 與一個 Partial Copy；Full sandbox 隨 Unlimited 與 Performance 提供，或者當作加購項目購買。

Full sandbox 的 29 天間隔，是大家太晚才開始繞著它做計畫的那個限制。你唯一實際可用的移轉彩排環境每月只能重新整理一次，所以一次揭露出問題的彩排，要等一個月你才能乾淨地再彩排一次。在 Full sandbox 上做兩輪彩排，是一個九週的窗口，不是兩週。

Developer 與 Developer Pro sandbox 只複製中繼資料，所以開發者為了測試而載入進去的任何東西，重新整理之後都會消失。測試資料必須是一段放在版本控制裡、可以重複執行的腳本，否則團隊每重新整理一次就要損失一天，用來手工重建它。

發布管理：change sets 還是管線

你不能在正式組織裡開發 Apex，所以每一處改動都從別的地方開始，並且必須被搬過去。怎麼搬，是一個尾巴很長的決定。

Change sets 是內建機制。它只能帶你能透過設定畫面修改的東西，永遠不帶記錄；它要求兩個隸屬於同一個正式組織的組織之間建立部署連線；而一個進站 change set 是整批部署的，不是逐個元件部署的。它是靠點選組出來的，所以它不可比對差異、不可審查、不可重複，同一個 change set 由兩個人各組一次，內容就會不一樣。

對於一個只有一名管理員、每月發一次版的小組織，這樣是可以的。當第二個人開始改同一個組織的那一刻，它就不管用了，因為沒有合併、沒有歷史，而發布了什麼的記錄只活在某個人的記憶裡。

替代方案是一條以原始碼為準的管線：中繼資料放在 Git 裡，改動以差異的形式審查，部署從分支執行。它要花幾天來架設，然後把發布管理從一件靠記憶的事變成一件可重複的事。只要建置者不只一個，就把它當成建置工作的一部分，而不是以後再說的改善。

75% 涵蓋率規則不是一條品質線

把 Apex 部署到正式環境，要求單元測試涵蓋你至少 75% 的 Apex 程式碼，而且這些測試要通過。Salesforce 明確說過，涵蓋率能指示測試的有效性但並不保證它，而且測試應該斷言行為。

請從商業角度讀懂這句話的含意。75% 是一道門檻，而門檻是會被繞的。那些為了湊數字而不是為了斷言任何東西而寫的測試類別，一樣會通過、會部署，然後什麼都抓不到。當你審查一個合作夥伴的成果時，不要問涵蓋率是多少。要求看三個測試方法，然後數一數裡面有幾個斷言。

一個 Salesforce 導入失敗在採用，而不是上線

系統上線了，專案結束了，帳單付掉了，八個月後業務總監還在用試算表跑預測。什麼都沒壞。這是一個失敗的 Salesforce 專案最常見的結局，而且它對任何技術指標都是隱形的。

這筆帳很殘酷，因為授權成本不管怎樣都在繼續。五十位 Enterprise 使用者按每月 £140 算，無論系統用不用都是每年 £84,000，所以 40% 的採用率意味著光授權一項每年就有大約 £50,000 是純粹浪費，這還沒算把導入成本攤到任何東西上。

採用也是唯一一種技術團隊修不好的失敗模式。一個合作夥伴可以完全按規格做出來、滿足每一條驗收條件，然後留下一個沒人打開的東西。這就是為什麼需求訪談階段的完成定義必須是關於使用的，也是為什麼專案不該在上線那天就算結案。

真正能推動採用的做法

有四件事能可靠地改變採用率，其中沒有一件是教學影片。

分角色訓練，而且分開辦。業務代表與業務主管出於不同的原因使用系統的不同部分，一場合併的訓練對兩邊都教不好。按角色只訓練它自己的工作流程，別的都不講。

一個很小的必填欄位集合。挑出讓報表能跑起來的最少欄位，把這些設為必填，其餘全部留成選填。每多一個必填欄位，就多一個讓人把記錄填到一半就放棄的理由，而一套懲罰輸入的系統，得到的輸入會更少。

讓主管的報表依賴這些資料。真正管用的是這一條。如果每週的管道會議是從 Salesforce 儀表板上開的，會議室裡沒有試算表，資料就會被輸進去，因為另一個選項是在這場對話裡缺席。如果主管自己留著一份私人試算表，那麼 CRM 就是選配的，而且所有人都知道。

一位具名負責人，而且他每週有時間。不是一個委員會。是一個人，他擁有這個組織、持有管理員權限、被以採用率考核，並且為此分配了工時。沒有這一條的組織，從第一個月就開始衰敗。

失敗模式，以及它們的早期警訊

我們被請去修復的 Salesforce 導入失敗，大部分由六種失敗模式解釋，而每一種都會在損害出現之前很久就露出訊號。

複刻一個壞掉的流程。警訊是一份需求文件描述的是現有系統而不是想要的結果，而且用的是舊系統的欄位名稱。把一個壞流程自動化，只會讓它更快、更難改。

沒有邊界的客製。警訊是一份變更請求記錄上一條駁回都沒有。Enterprise Edition 允許每個物件 500 個自訂欄位與 200 個自訂物件，在你碰到平台上限之前很久，餘裕就已經足夠讓你做出一套沒人維護得了的東西。

沒有單一負責人。警訊是，誰擁有 Salesforce 這個問題的答案裡帶著一個和字。

什麼都搬。警訊是移轉範圍是按記錄筆數定義的，而不是按一個保留期決定定義的。

沒有測試環境紀律。警訊是有人說，直接在正式環境改就好了，不就是一個選項清單值。

衡量上線而不是使用。警訊是一份專案計畫的最後一個里程碑是一個日期，而不是一個數字。

小型、中型與複雜導入的時程

歷時與工作量是兩個不同的問題，而買方會把它們混為一談。以下是我們從英國中端市場專案裡得出的內部區間，不是公開數據。

一個小型導入，單雲上最多約 25 位使用者、最多一個串接、一個乾淨的資料來源，歷時 6 到 10 週，顧問投入 20 到 45 人天。一個中型導入，一到兩朵雲上 25 到 150 位使用者、兩到四個串接、有一次真正的移轉，歷時 4 到 7 個月，90 到 220 人天。一個複雜專案，150 位使用者以上、多雲、五個或更多串接、跨越不只一個國家，歷時 9 到 18 個月，400 人天以上。

在這些總量裡面，需求訪談占工作量的 10 到 15%，設定與建置占 30 到 40%，資料移轉占 20 到 30% 並且會隨來源資料品質變差而急劇上升，串接占 10 到 20%，測試、訓練與上線後加護占 15 到 20%。每一次膨脹的那一條都是移轉。

歷時之所以超過工作量除以團隊人數，原因並不是團隊的錯：sandbox 的重新整理間隔、關係人能不能挪出時間做使用者驗收測試，以及等待那個你需要其 API 的第三方。這份風險由誰承擔是由合約決定的，這也是為什麼固定價格與計時計料這個問題在 CRM 專案上比在大多數專案上更要緊。

CRM 專案裡的英國資料保護

CRM 是一個關於人的資料庫，所以 UK GDPR 基本上適用於它的全部內容，而每一次導入都會冒出三個問題。

這需要做 DPIA 嗎

ICO 關於什麼時候需要做 DPIA的指引，列出了來自第 35 條第 1 項的一般規則，也就是當處理很可能對人的權利與自由造成高風險時就需要做 DPIA，並且列出了 ICO 依據第 35 條第 4 項給出的那組作業。

其中有兩項正正好好落在一次典型的 CRM 移轉上。資料比對，定義為把從多個來源取得的個人資料加以結合、比較或比對，恰恰就是一次整併移轉在做的事。大規模剖析涵蓋 Lead 與 Account 評分。ICO 還指出，雖然這不是一條硬性規則，但在多數情況下，歐洲那套標準中有兩條同時成立就意味著需要做 DPIA。請注意，這份指引因為 Data (Use and Access) Act 帶來的變化目前正在檢討，所以要去看原文，而不是依賴某份摘要。

資料實際上放在哪裡

Salesforce 是一個全球平台，你的組織跑在哪個執行個體上是一件合約事項，不是一個可以假設的事。ICO 的國際傳輸簡明指南最後更新於 2026 年 1 月 15 日，給出了一個三步測試：UK GDPR 是否適用於該處理、你是不是在向英國境外的一個機構發起傳輸、接收方是不是一個獨立的法律實體。三個都是，它就是一次受限傳輸。

受限傳輸需要英國的適足性認定、適當的保護措施（例如國際資料傳輸協議、附錄或具拘束力的企業規則），或者一項例外。當你依賴保護措施時，ICO 期望你做一份傳輸風險評估。這是一次合約審查，不是一項工程工作，而且它應該發生在移轉之前而不是之後。

你的導入合作夥伴是一個處理者

當一個合作夥伴設定你的組織、載入你的資料、並且持有存取它的憑證時，他們就是在代表你處理個人資料。ICO 關於控制者與處理者的指引說明了由此產生的義務，而實務上的影響是合約層面的。

你需要一份書面協議，涵蓋成文的指示、保密、安全、次處理者、稽核權，以及合作結束時資料的刪除或返還。最後這一條是最常缺席的條款。一個把你客戶資料庫的完整副本放在 Full sandbox 裡放了十一個月、而合約裡對刪除隻字未提的合作夥伴，是一份攤在你這一側而不是他那一側的敞口責任。

該問候選合作夥伴什麼

六個問題，以及那些應該終止對話的答案。

問訪談會產出什麼。如果答案是一份提案，而不是一張流程圖、一個資料模型、一份串接清單與一個可衡量的完成定義，那他們是在賣東西，不是在劃範圍。

問他們打算怎樣剖析來源資料，以及什麼時候做。如果剖析發生在移轉估算被認可之後，那這個估算就是猜的。

問他們做自動化的預設選擇是什麼，並且聽聽有沒有密度這條論證。一個說永遠用 Flow 或者永遠用 Apex 的合作夥伴，手上只有一件工具。一個在 2026 年還指定 Process Builder 的合作夥伴，三年沒讀過一份停止支援公告。

問改動是怎樣從 sandbox 搬到正式環境的。change sets 這個答案，對一個只有一名管理員的組織是可以接受的，對任何比它更大的組織都是一個警告。

問上線之後由誰擁有這個組織，以及那是每週多少小時。如果他們答不上來，採用就不是任何人的問題。

問合作結束時，你放在他們 sandbox 裡的資料會怎麼樣，並且把答案寫進合約而不是寫在一封電子郵件裡。我們在技術實地查核指南裡寫下的同一條紀律在這裡同樣適用：去驗證聲明，而不是接受保證。

什麼時候答案不是 Salesforce

如果你只有大約十位以下的使用者、沒有串接需求、流程也裝得進一條五階段的管道，那麼 Enterprise 授權與它的導入都比這個問題本身要大。一套更便宜的 CRM，或者每位使用者 £20 的 Starter Suite，就夠用了，而且以後可以用你承受得起的代價換掉。

如果你真正的需求是一條沒有產品支援的工作流程，而其他一切都已經有人管了，那你是在買一個平台來裝一個應用程式。這通常是一個該做專用系統的情境，我們的客製軟體開發正是從這個前提出發的。自建還是採購的決策取決於那條形成差異化的流程是這門生意的核心，還是它周邊的一個細節。

如果沒有人願意擁有這套系統，就不要買。這是業務過程裡最難說出口的一句話，也是對浪費最可靠的預測。一套沒有主人的 CRM 不會大聲地失敗。它會安安靜靜地變成它本該取代的那張試算表的副本，同時每位使用者每月還在付 £140。

而如果目標是一層 AI 代理人而不是一套 CRM，那它是坐在一個跑得起來的導入之上的，而不是取代它。這筆帳我們在Agentforce 到底要花多少錢那篇文章裡算過。

把工作排成正確的順序

管用的順序是：先剖析資料，把訪談做到四份成果物，確定標準模型並且給每一處偏離標價，按每個物件一個自動化進入點來建置，在 Full sandbox 裡彩排兩遍移轉，按角色訓練，然後讓專案一直開著，直到一個使用數字達標，而不是直到一個日期。

會失敗的順序是：簽約、設定、把移轉拖到最後、只訓練一次、按日期上線、結束專案。

Mecanik 做的是這裡面屬於工程而不是授權管理的那些部分：針對真實平台限制的串接設計、移轉剖析與工具、設定走到盡頭時的客製開發，以及把 CRM 資料擺到客戶面前的前端工作。我們的軟體開發服務與聘請 Web 開發者頁面說明了我們的合作方式。如果你想在簽字之前，對一個合作夥伴的報價拿一個第二意見，你也可以只為這次審查聘請一位開發者。

常見問題

在英國做一個 Salesforce 導入要花多少錢？ Salesforce 在英國給 Sales Cloud Enterprise 的標價是按年付費每位使用者每月 £140，所以 50 位使用者光授權就是每年 £84,000。對於其上的導入服務，我們的內部估算是：接近原生的上線為首年授權支出的 0.5 到 1 倍，典型的中端市場專案為 1 到 3 倍，帶舊系統資料與大量客製的多雲專案為 3 到 5 倍。

一個 Salesforce 導入要做多久？ 我們的內部區間是：單雲、資料乾淨、最多 25 位使用者，6 到 10 週與 20 到 45 個顧問人天；25 到 150 位使用者、兩到四個串接，4 到 7 個月與 90 到 220 人天；帶舊系統資料移轉的多雲專案，9 到 18 個月與 400 人天以上。會膨脹的階段是資料移轉，因為它的工作量取決於來源資料品質而不是記錄筆數。

Salesforce 導入為什麼會失敗？ 幾乎總是失敗在採用而不是上線。一套技術上正確卻沒人使用的系統，是一筆還掛著授權帳單的全損。常見原因是複刻一個壞掉的流程、沒有邊界的客製、沒有單一具名負責人、把全部歷史資料都搬過來、沒有測試環境紀律，以及衡量上線而不是衡量使用。

Salesforce 應該用設定做還是寫自訂程式碼？ Salesforce 自己的決策指南用自動化密度來設定門檻。一個物件上少於十五個自動化、每批 1 到 200 筆記錄、最多一次下游寫入，應該用記錄觸發的 Flow。中等密度適合由 Flow 編排可呼叫的 Apex。高密度適合 Apex 觸發器。每個物件只用一個進入點，不要在同一個物件上混用 Flow 與 Apex 觸發器。

做 Salesforce 導入需要 DPIA 嗎？ 通常需要。ICO 把資料比對（也就是結合或比較來自多個來源的個人資料）與大規模剖析列為表明需要做 DPIA 的作業，而一次帶潛在客戶評分的整併移轉兩者都占。該指引目前因 Data (Use and Access) Act 正在檢討，所以請查看 ICO 目前的立場，而不是它的某份摘要。