臺灣首個 Consumer Goods Cloud
（增強版）導入

背景

本案客戶是一家臺灣速食業連鎖品牌，全台規模近 400 家門市，業務涵蓋直營、加盟與門市營運的整套生命週期。

在我們進場之前，客戶已經有一套既存的 Salesforce 環境，但因為長年缺乏一致的設計語彙與業務對齊，使用者體驗不佳、內部對既有系統的滿意度偏低。整合方面則走輕量路線——透過 Survey Monkey、Google Form 收集現場與營運資料，再用 Zapier 串接到 Salesforce 與其他系統。

客戶想做的不是「再加一塊」，而是把 Salesforce 這條主線重新拉直——讓門市端、總部端與加盟端的流程，能在同一個平台上順暢地運轉起來。

挑戰

客戶的業務本身是分散的：招收加盟主、門市管理平臺、合約簽署與履行、門市與加盟的服務、最終端的客戶服務——這些流程過去散落在不同工具與不同團隊裡，彼此銜接靠人工接力。

挑戰因此有三層：

1. 業務流程要被「縫」回同一條線。從加盟招收一路走到日常營運與客戶服務，必須在同一個平台上有一致的資料與一致的體感。
2. 既有資產要保留。Survey Monkey、Google Form、Zapier 串起來的輕量整合已經跑了一段時間，新平台必須與這些既有資料流共存，而不是要求企業「全部重做」。
3. 使用者要願意回來用。過去 Salesforce 在內部評價不高——這次重做必須讓使用者重新感受到一個現代、好用的 Salesforce。

解決方案

我們以 Consumer Goods Cloud 增強版（Consumer Goods Cloud Enhanced，消費品雲增強版）作為平台主軸——本案客戶是這個產品在台灣的第一個導入客戶。圍繞它，再結合 Sales Cloud、Service Cloud 與 Experience Cloud，把加盟、門市、合約、服務、客戶服務五段流程整合進同一個 Salesforce 平台。

幾個關鍵的設計選擇：

盡量用 Consumer Goods Cloud 的原生能力

Consumer Goods Cloud 增強版內建了三項我們大量倚賴的能力：

• Business Rule Engine（業務規則引擎）——以宣告式規則計算門市與加盟相關的業務邏輯（配比、結算、稽核條件等），把規則交給產品本身管，避免每個情境都靠客製。
• Discovery Framework（流程引導框架）——把現場拜訪、稽核、表單流程結構化，讓門市管理平臺有一致的執行節奏。
• DocGen（文件自動產生器）——請購單、檢查報告等門市端 PDF 文件由系統依資料模型直接產出，不再仰賴外部模板拼接。

這三項組合起來，已經涵蓋日常營運大部分的邏輯。

輕量整合：Survey Monkey、Google Form、Zapier

客戶既有的整合是 form-based 的——門市與營運端的資料靠 Survey Monkey 與 Google Form 收，Zapier 把資料路由到 Salesforce 以及其他系統。我們選擇沿用這個既有資料流，把它變成 Salesforce 內部資料的進入點之一，而不是要求客戶為了上 Salesforce 再導入一套企業級整合層。對這個規模的營運節奏，這個輕量做法已經夠用，也能讓現場團隊維持原本的填表習慣。

Experience Cloud 串起加盟主端的觸點

加盟主與門市端透過 Experience Cloud 與總部互動，讓「招收 → 合約 → 營運 → 服務」這條線在外部觸點上也維持一致。

三階段導入

整個專案分成三個階段推進，每個階段都對齊一段業務節奏，而不是一次把所有東西堆上線：

• 階段一：加盟招收與合約。把加盟主從接洽、評估到簽約的流程搬上 Sales Cloud，讓拓店這段最前緣的業務有完整的數位軌跡。
• 階段二：門市管理與服務。透過 Consumer Goods Cloud 的 Business Rule Engine、Discovery Framework 與 DocGen，把門市的日常營運、稽核、請購與服務邏輯成形——稽核完成後的檢查報告與門市請購單都從系統直接產出。
• 階段三：客戶服務與整合深化。Service Cloud 上線承接消費端服務，並把 Survey Monkey、Google Form、Zapier 既有的資料流更深地接進來，讓門市端的回饋與內部營運資料銜接得起來。

每個階段都是可獨立交付、可獨立驗收的單位——舊系統不需要等到第三階段結束才退場。

結果

專案交付後，客戶有了一個覆蓋加盟、門市、合約、服務與客戶服務的統一 Salesforce 平台：

• 原本散落的業務流程被收進同一個平台，跨團隊的資料與動作有了一致的依據。
• Consumer Goods Cloud 的原生能力（Business Rule Engine、Discovery Framework、DocGen）成功上線，邏輯多半由產品本身承擔，而不是由客製碼承擔。
• 使用者重新拿到一個現代的 Salesforce 體驗，內部對平台的觀感從負債轉為資產。
• 這個平台也為客戶後續的 Agentforce Enablement（Salesforce AI 代理人導入服務）奠定了乾淨、可擴展的基礎——Agentforce 不在這個專案的範圍內，但下一步可以從這裡長出去。

學到的事

這個案子讓我們把幾個原則寫進 EKel 接案的標準動作。

先用 OOTB（Out-of-the-box，產品原生標準功能），逼自己先用產品本身解。我們從一開始就守住一條線：能用 Salesforce 標準功能解掉的，就不要客製。Consumer Goods Cloud 增強版的 Business Rule Engine、Discovery Framework、DocGen 把大部分日常邏輯都接住了，這也是這個專案能把複雜度收得住的關鍵。

客製不是壞事，前提是值得做。當業務確實需要、產品本身覆蓋不到時，我們就客製——而 AI 輔助開發讓客製這件事的速度與品質都比過去高一個量級，使用者最後拿到的東西反而更貼近他們的真實作業節奏。

用工程的方式跑顧問專案。Jira + Confluence 跑敏捷，需求、決策、文件都留軌跡；CI/CD（Continuous Integration / Continuous Delivery，持續整合與持續交付）走現代的 pipeline，避免顧問業常見的「最後上線靠手工」。這讓三個階段彼此可以接得住。