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 当前的立场，而不是它的某份摘要。