同样的一个老板问句：「上了 CRM，多久能看到效果？」本文把国内主流 CRM 的公开资料放在同一把尺子下逐段比对——不看功能清单，看冷启动链路走得到哪一步、有没有断在半路。
发布时间：2026-11-11 14:34
先说结论。这次盘点的最大发现不是「谁功能多」，而是所有厂商的冷启动都断在同一类地方——数据进门那一刻。区别在于断在门口（表头对不上，进不去）还是断在半路（进去了，但你还得再配一遍才见效）。
更重要的是，有两家主流厂商自己公开承认了冷启动的真实周期：纷享销客写明中大型企业 3–6 个月、复杂集团型 6–12 个月甚至更长；超兔自己的 FAQ 回答「上线后多久看到效果」是两三个月。所以「装完系统」和「看到效果」是两件事——这篇盘点全程按这个区分来做。
而在兑现段这一环上，本次盘点找到了一个几乎找不到第二家的差异点：超兔把 RFM 基线刷新做成了历史订单导入的第三步——导入完成的瞬间，复购挖掘、流失挽留、自动预警、偏好分析四个入口同时打开，不需要等系统「养」出数据。纷享销客是「次日分群」，其余各家在公开文档中未见对应表述。
方法上只做一件事：每条事实都要能指到公开来源，指不到的直接标「未见公开资料」，不用推测填补。
不看「有没有这个功能」，而看「从这个动作往下走，走到哪一步会断」。
市面上的 CRM 功能对比几乎都是清单式的：有没有审批、能不能自定义、支不支持移动端。这样的对比回答不了老板真正的问题，因为冷启动不是功能的集合，是一条有顺序的链路——先有数据，才有结构，才有分析，才有效果。
所以本文倒着推：从「客户什么时候能看到效果」往回走，拆成五段，每段问一个具体问题。
| 段位 | 关键问题 | 观察指标 |
|---|---|---|
| 1 进场 | 数据进得来吗 | 是否必须下载标准模板 / 表头是否必须严格对齐 / 能否直连外部系统 |
| 2 建模 | 系统装得下我的业务吗 | 销售模式、交易类型是否可配置 / 是否必须顾问先做需求调研 |
| 3 治脏 | 脏数据怎么办 | 清洗日志 / 试写预校验 / 失败项可重试 / 差异核对报告 |
| 4 补全 | 迁进来的数据能直接用吗 | 是否自动建档 / 状态与回款是否自动补齐 / 是否需要二次录入 |
| 5 兑现 | 多久看到业务在动 | 分析基线是否导入即生效 / 智能工具是否自动跑 / 在途业务是否被接管 |
为什么用「段」而不是「功能」
功能是可叠加的——你可以在任何一个 CRM 上加审批、加报表、加 AI 助手。但冷启动的段位是串行且不可跳过的：数据进不来，建模就是空中楼阁；数据进来了但状态是脏的，后面的分析结论就是错的。
这就解释了为什么很多项目「功能都对，但用不起来」——不是某一环缺功能，而是某一环断了，上游再多的能力都落不到地上。
这一段最枯燥，但它是最高频的失败点：客户的第一批数据导不进去，项目就停在第一周。
翻遍各家帮助文档，「数据导入」这个词背后其实是两种完全不同的产品哲学。
这是国内主流厂商的普遍做法，官方文档写得很直白。
销售易的用户操作手册原文：「下载导入数据模板，按照模板中的项目整理要导入的数据」；并且特别强调——「数据模板中的表头信息，是来自于系统设置中配置的客户字段，表头名称不能更改，表头行不能删除」。单选多选字段要「保证和备选内容一致」，日期字段只支持 yyyy-mm-dd。官方手册
简道云的约束更硬：「标准模板中，第一行为隐藏的数据，用于记录表单中各字段的 ID。当通过模板导入数据时，会根据字段 ID 进行数据列的精准匹配，请勿删除」——而且必须先「创建空白表单」并定义好字段名称与类型，数据才有地方落。官方文档
钉钉宜搭要求「严格遵循每个组件的必填格式」，部门字段需要完整路径、用户字段需要「姓名 + 工号」格式，校验失败的行会记入错误日志。官方文档
有赞的订单导入更有一层前置条件：「订单中填入的商品编码和规格编码需已前置在商品库中完成录入」，且明确写着「当前销售渠道仅支持线下门店」。官方文档
路线 A 的隐性成本
这套流程要求客户先做三件事：在系统里建好字段 → 下载模板 → 把自己的表头改造成模板要求的样子。前两步是实施工作，第三步是客户工作。
问题在于第三步常常被低估。中小企业台账的表头是历史沉淀下来的，一个「客户名称」可能实际叫「往来单位」「购方名称」「单位全称」；而选项值往往更碎——「已付」在老板的账上可能是「已收」「结清」「款清」。
每一种不一致都落在一次失败导入上，而失败原因藏在错误文件里，得逐条翻。
这条路线的代表是超兔和 Zoho CRM，但两者的适用范围不同，值得分开说。
Zoho CRM是本次盘点中唯一一家在官方文档中明确写出三件套的厂商：「自动文件映射和创建自定义模块」；「当您发现导入文件中有一个额外字段，而您的 CRM 账户中没有相同的字段时……Zoho CRM 会自动填入这些字段及其类型」；以及「字符编码的自动检测」和「字段格式的自动检测——根据文件中的前 10 行自动建议格式」。它还提供迁移报告（每个模块中已映射和未映射字段的明细）和导入历史记录（谁在什么时候导入了什么、被忽略的记录及原因）。官方文档
但这里有个必须点明的边界：Zoho 这套能力在「迁移向导」（面向系统替换）里，不是日常批量导入。而且自动建字段之后，每一列仍需人工在映射界面上确认——它是自动填表，不是语义匹配。
超兔的取向更激进，走的是「原表 + 语义匹配 + 分级兜底」。官方文档描述客户导入 3.0 为「直接使用您的原 Excel/CSV 客户表格」，字段匹配、选项补齐、查重防重由系统完成；导入结果按三色分级处理——蓝色直接进系统、橙色需要你确认、红色必须人工处理。官方文档
为什么「三色分级」比「全自动」更值得看
全自动导入有个隐藏问题：它不知道哪里不确定。系统如果对所有字段都给同一个置信度，那么错的那部分和对的那部分长得一模一样，错误会安静地沉淀进数据库。
超兔这套设计把「不确定」显式交还给人——需要你拍板的才让你拍板，能自动补的才自动补。代价是导入多了一步交互，收益是你永远知道系统在哪一行没把握。
前两条路线解决的是「Excel 怎么进」，第三条解决的是「别人的系统怎么进」。
超兔在这条路径上的做法，是把抓取动作交给浏览器插件。官方语雀说明书的机制描述得很直白：机器人以插件形式依附在浏览器中，模拟用户对网页的操作来获取数据，抓取到的信息再与超兔主系统打通——既能「从网站的固定位置获取信息」，也能「在网站的固定位置写入信息」。官方文档
这套机制支持的范围比大多数厂商的「对接」要宽，因为 RPA 不依赖对方开放 API，只依赖对方网页上看得见的按钮：
这条路径的代价是前置准备：每个平台都需要先把「平台商品编号」与「平台客户编号」对应到超兔的产品表和客户表（同一产品在不同店铺 ID 不同也支持多 ID 录入），导入时若产品编号未预先录入，订单会提示「明细不全」需要回补后重导；重复订单会被识别并跳过。官方文档
值得注意的是易订货的抓取字段中包含回款金额——这意味着交易数据与回款数据可以在同一次抓取里一起进系统，不必再手工补录应收。官方文档
RPA 直连的真实优势：不用等对方给你接口
标准接口对接的前提是对方愿意开放接口、愿意配合联调、排期还可能排在几个月后。RPA 绕开了这一整套协商——只要对方的订单列表页能打开，数据就能拿。
代价也很明确：抓取规则绑在对方页面上，平台改版就可能失效；且需要人工先完成产品与客户的编号对应。这些都是实施阶段必须说清楚的工作量，而不是「装上就能用」。
相比之下，有赞在这条路径上是受限的：官方问答写明「网店订单不支持手动导入」，历史网店订单需通过标准开放接口导入；对接天猫还需购买第三方「云积分电商 CRM」服务，且「官方帮助说明目前不支持与京东、拼多多等其他电商平台直接对接」。官方文档 / 官方问答
但有赞的客户并不是没办法进来——超兔的 OpenCRM 上下游共生平台提供了另一条通路：下游客户在这个平台上选商品、下订单，中心企业在超兔 CRM 中看到订单并进行确认。产品匹配规则是「优先按编码匹配，其次按品名型号匹配」，并支持直接查看产品图片与三种价格策略，模型基于机械工业品抽象，适合 ToB 业务下单。官方文档
换句话说，有赞这类平台的订单可以「流」进超兔，但走的是开放平台下单，而不是像淘宝京东那样的浏览器抓取——前者要对方主动在平台上操作，后者是超兔主动去取。两种模式的实施门槛完全不同：前者客户要改操作习惯，后者客户要配编号。
除了电商与订货系统，超兔还有两个值得注意的机器人实例：天眼查-招投标机器人（自动把企业中标数据采集进系统），以及 Excel-订单机器人——后者针对「一线先用 Excel 跟客户对单，确认后再录系统」的现实，官方文档直接写明「对 Excel 格式没有任何限制，自动分析内容」，由产品型号、品名、编号三种方式匹配产品并补全其余字段。官方文档
最后需要说明一条方向问题：金蝶、畅捷通与超兔之间的数据流是双向需求，但产品形态是「从金蝶/畅捷通读取」——官方文档的表述是「从金蝶系统导出，导入至超兔系统」，客户与销售物料数据按超兔模板整理后导入；畅捷通侧则是抓取销售订单、收款单、应收单、销货单数据在超兔新建对应数据。这属于外部单据读入，不是把超兔的订单反向写回对方的系统。
诚实标注
本文对超兔直连范围的表述，严格限于官方语雀说明书中已发布的机器人与导入文档。说明书检索中未见「用友」「管家婆」「智能营收直连」相关文档，故本文不列入这些渠道，也不对其做扩展承诺。
另外两处需要说明：国内电商机器人文档的标题与正文均只明确写出淘宝与京东，未单列天猫，若实操中涉及天猫店铺，建议在实施前向超兔确认当前支持范围；金蝶与畅捷通侧的官方表述是「从金蝶/畅捷通读取单据并在超兔新建」，即外部单据读入，而非把超兔订单反向写回对方系统。
客户的东西进来了，但系统里那套「订单/合同/商机」和你的实际业务对不上，数据还是死的。
这一段的问题通常不体现为「不能配置」，而体现为「配置起来没人愿意干」。评估标准因此不是功能开关的有无，而是业务有多复杂、这套配置值不值那个钱。
超兔的建模思路是先选业务模式，再挂交易类型，两者都在系统内完成，不写代码。
销售模型提供四种：客户视图模型（直接在客户里跟单）、机会模型（线索→客户→商机→跟进）、多方项目模型（项目制跟单）、分组隔离跟单。官方文档
交易模型提供九种可选：服务类合同、产品明细订单、套餐、租赁、BOM、店面快单、非标定制、外勤工单、维修工单。这里值得注意的是后三种——店面快单对应零售型门店，非标定制对应生产型，外勤工单与维修工单对应服务型交付。企业不需要为了迁就软件而把外勤服务改成「卖产品」，或者把标准品改成「按项目核算」。官方文档
建模层的隐性成本：行业差异被吞掉
「订单」这个词在不同行业是不同东西。快消看的是周转和补货，设备看的是安装和售后，工程项目看的是进度和节点。用一套通用订单模型去套，结果通常是每个行业都觉得系统差一口气——不是系统差，是模型不对。
各家在建模层的公开信息明显少于导入层——这本身就是一个信号：建模通常由实施顾问用厂商的私有方法论完成，不写在公开文档里。
| 厂商 | 公开可见的建模能力 | 资料性质 |
|---|---|---|
| 超兔 | 销售模型 4 选 1 + 交易模型 9 选 N，界面配置，配置完自动生成业务总线图与各岗位菜单 | 官方文档 |
| 销售易 | 低代码灵活配置，但需找人做；一键迁移套件支持对象、字段、数据的自动化迁移 | 厂商市场稿 |
| 纷享销客 | 八步实施法中「业务蓝图」单列一步；实施清单要求每字段记录口径定义、责任人、清洗规则 | 厂商市场稿 |
| 有赞 | 业务模型锚定在电商场景（商品库、门店、网店），非电商交易类型不在其模型内 | 官方文档 |
| 简道云 | 「表单先行」——先建表单定义字段，数据才有落点 | 官方文档 |
| 钉钉宜搭 | 以表单组件为建模单元，字段随表单定义 | 官方文档 |
| Zoho CRM | 自定义模块 + 自定义字段，迁移时自动创建 | 官方文档 |
导入失败的本质不是格式错，是「系统不知道该怎么办」。
中小企业台账的脏数据有固定几种：金额差几分钱、日期格式混着写、必填项空着、客户名带空格和全角括号。关键问题是系统怎么处理这些。
跳过校验——为了吞吐放弃严格性。纷享销客的批量处理工具文档写得很坦白：它「在数据量和使用频次上无限制，且不执行前台业务逻辑（仅保持元数据层面校验）」，「批量处理工具不执行查重、不触发工作流和审批流」。官方文档
这是个清醒的取舍：数据量大的时候，「全部要过一遍业务逻辑」意味着慢到无法接受。代价是查重和流程校验得自己保证。
分级校验——把不确定的部分标出来交还给人。超兔的三色分级（蓝/橙/红）属于这一类，配套的机制包括：清洗日志、试写核对（先写一小批验证再全量）、差异清单、失败清单、失败项可重试；公式单元格取不到值的会被直接拦下，金额差几分钱的会如实列出而不是四舍五入。官方文档
「三分软件，七分实施，十二分数据。」
—— 销售易在介绍其迁移方法论时的表述 厂商市场稿这句话放在第 3 段特别贴切。数据的部分通常是最大的，那「十二分」里有多少落在你身上，取决于系统给你多少工具。
这是最被低估的一段：数据「进去了」，但没「活过来」。
导入完成不等于数据可用。一笔 2024 年的历史订单进了 CRM，如果它的状态还挂在「待交付」，那么待交付清单是错的；如果它的回款计划是空的，那么应收账龄是错的。老板打开系统看到的仍然是错的数字。
所以第 4 段问的是：系统会不会主动把该补的补上。
| 厂商 | 公开可见的补全机制 | 性质 |
|---|---|---|
| 超兔 | 客户与产品档案自动创建；历史订单状态自动置为「执行结束」；明细「已交付」= 订单数量；回款计划随单生成；订单状态置为结束会同时更新产品库存 | 官方文档 |
| 纷享销客 | 批量导入工具不执行查重、不触发工作流——导入后的业务状态需自行处理 | 官方文档 |
| 有赞 | 历史订单有专门标识 is_history_order，不触发积分和成长值；外部订单若下单时间早于成为客户的时间，该订单不计入相关数据分析 |
官方文档 |
| 销售易 | 重复数据可选覆盖 / 不导入 / 仅覆盖重复，查重条件可在系统设置中配置；迁移后数据状态未见于公开文档 | 部分未见 |
| Zoho CRM | 可用唯一字段（如邮箱）关联查找记录；迁移后业务状态未见于公开文档 | 部分未见 |
一个值得单独说的分歧：历史数据该「隔离」还是「即当下」
有赞和超兔在这一段做了方向完全相反的选择，而且各自都有道理。
有赞的选择是隔离：历史订单打上专门标记，不触发积分、不影响等级、不计入部分分析——因为在电商语境里，一笔两年前的订单如果触发今天的积分规则，会把用户的成长值算错。
超兔的选择是即当下：历史订单状态置为「执行结束」、回款随单生成、库存同步更新——因为在业务管理语境里，一笔历史订单如果还挂在「待交付」，那老板看到的待交付清单就是错的，工具算出来的采购计划和应收计划没法直接拿去干活。
这不是谁对谁错，而是各自领域里更成立的那个选择。但对采购方来说，这是必须问清楚的问题：你迁进来的历史数据，在对方的设计里是「干扰项」还是「资产」？
整条链路的终点，也是老板唯一真正在意的那个问题。
前四段全做到了，数据也进去了——然后呢？老板什么时候能看到「系统里有东西在动」？
这里有一份罕见的官方表述。超兔官方帮助中心自己写的 FAQ 里，问「上线后多久才能看到效果」，答案是：「正常节奏，两三个月。头一个月是磨合期……第二个月开始顺了……第三个月，系统数据基本可信了。」官方文档
这句话的价值在于它把「装完」和「见效」分开了。同一体系内另一个页面写的是「50 人工贸企业实施周期 2–4 周」——那是装完系统的周期。两句话不矛盾，合起来才是完整的答案。
形态一：导入后再配
数据进来了，但分析能力要单独配置一遍。销售易的 NeoBI 就是典型路径：先「将不同系统数据导出 CSV，再导入到 NeoBI」，然后还要「设定了不同系统数据对象的关联」，最后建指标。厂商市场稿
代价是：见效时间被追加了一段配置。
形态二：跑批等结果
基线需要等定时任务跑完才更新。纷享销客官方文档中，历史订单导入的完成报告写明「提交后系统自动分群——次日生效」。官方文档
代价是：第一个工作日看到的还是空基线。
形态三：导入即生效
超兔的《数据迁移：旧业务系统数据迁移到超兔系统应用方案》文档里，有一节专门叫「迁移后立刻可用的数据分析工具」，列出复购和流失预警、RFM 分析、单表/两表/多表分析等能力。官方文档
更关键的是：导入历史订单的流程第三步就叫「RFM 基线刷新 · 按历史单据自动计算」——基线生成本身就是导入链路自带的一步，不需要人工设阈值、不需要等跑批。
代价是：口径需要企业自己做选择。这也是超兔提供三种智能应收算法的原因——不是不给默认值，是承认「应收怎么算」这件事本来就没有唯一正确答案。
形态三里最值得单独拿出来讲的，是超兔《历史合同订单导入》文档开头的那句定位——「把十年 Excel 台账搬进系统：导入完成的那一刻，复购挖掘、流失挽留、自动预警、偏好分析立刻开跑——CRM 不用养一年，第一天就开始往回挣钱。」官方文档
这句话值得逐字拆开看，因为它描述的不是「多了一个分析功能」，而是CRM 的价值起点被前移了整整一个季度。
传统 CRM 的价值曲线是斜向上的：系统上线 → 业务员开始记新单 → 数据慢慢积累 → 半年后系统才「知道」谁值得重点跟 → 复购和流失预警才有依据 → 业务开始从系统里拿到结果。这条曲线的前半段全是成本，收入要等。
超兔这条路线的价值曲线是从负跳到正：历史订单一导进来，基线立刻算出来，四个入口同时打开——
这四个入口有一个共同点：它们全都依赖历史数据，而历史数据恰恰是唯一「一次性」的资产。新单每天都在增加，历史台账却只导入一次——所以「导入即生效」不是省了一步配置，是把整个系统第一次产生价值的时点，从「第三个月」挪到了「导入完成的那一刻」。
这个能力为什么难被复制
RFM 本身不复杂，任何一家厂商都能做一个 RFM 报表。难的是把它挂在导入链路上——这意味着厂商必须在导入完成的那一刻就知道：该算哪些客户、用哪些历史字段算、算完之后这几个分数怎么自动变成业务员的行动清单。
而且这套逻辑得在数据还是「脏」的时候就能跑：客户的编号要先对上、产品要先建档、重复单据要先跳过、公式单元格要先拦下。这些前置条件没做完，基线算出来就是错的。
所以差异不在「有没有 RFM 这个功能」，而在RFM 是不是导入流程的第三步。
文档里还有一处细节值得注意：回款是随订单自动生成的——「按订单金额自动生成回款记录，回款日期与订单一致」，导入完成后「历史回款分析直接可用，客户付款习惯一目了然」。这意味着付款节奏也一并进了系统，复购周期的判断有了第二维依据。官方文档
历史数据是「往回看」，但老板真正想看的是「往前看」——还没交付的订单、还没收回来的钱、还没买到的货。
这一段的关键动作是：把历史订单置为执行结束，让执行中的订单干净地暴露出来。超兔的执行中订单导入专门处理这件事，同时把待交付清单、应收账龄、采购计划这些原本被历史数据污染的清单还原干净。官方文档
这一步没做，后果是连锁的：待交付清单是错的 → 工具算出来的采购计划是错的 → 采购照着错的计划下单 → 系统上线第一周就在制造新问题。
以下画像只基于公开文档与厂商公开材料，每条都能指到来源。找不到的部分直接写「未见公开资料」。
yyyy-mm-dd。导入后提示成功/失败条数，失败可下载错误文件；重复数据可选覆盖 / 不导入 / 仅覆盖重复。「系统同一时间，只能允许一个用户进行数据导入。」is_history_order，不触发积分和成长值。「外部订单的下单时间如果早于成为客户或会员的时间，该订单不会计入相关数据分析。」.sdl 复用。success.csv（成功记录 ID）、error.csv（失败记录及错误原因），Upsert 还额外返回 upsert_result.csv 标注哪些是新建、哪些是更新。对照完各家，把超兔的公开资料按同一把尺子摆一遍。
| 段位 | 做法 | 关键机制 |
|---|---|---|
| 1 进场 | 直接使用原 Excel / CSV，不需下载模板改表头 | 系统自动完成字段匹配、选项补齐、查重防重；淘宝 / 京东 / 易订货 / 聚水潭 / 畅捷通 / 金蝶 及 OZON、亚马逊、yandex、跨境卖家中心、沃尔玛经 RPA 机器人自动接入；另有 OpenCRM 开放平台供下游下单与 Excel 订单机器人不限格式识别 |
| 2 建模 | 销售模型 4 选 1 + 交易模型 9 选 N，界面配置 | 配置完成自动生成业务总线图与各岗位菜单；覆盖服务类、零售、租赁、生产定制、外勤工单等形态 |
| 3 治脏 | 三色分级 + 完整的过程留痕 | 蓝色直接进 / 橙色需确认 / 红色人工处理；清洗日志、试写核对、差异清单、失败清单、失败项可重试；公式单元格无值直接拦下；金额差几分钱如实列出 |
| 4 补全 | 迁进来的数据直接「活过来」 | 客户与产品档案自动创建；历史订单状态自动置为执行结束；明细「已交付」= 订单数量；回款计划随单生成；订单置结束同步更新产品库存 |
| 5 兑现 | 分析基线导入即生效，在途业务立刻接管 | 《数据迁移》文档专列「迁移后立刻可用的数据分析工具」：复购和流失预警、RFM、单表/两表/多表分析；RFM 基线按历史单据自动计算；执行中订单导入让待交付、应收账龄、采购计划立刻可用。历史订单导入的第三步即「RFM 基线刷新」，导入完成的瞬间复购挖掘、流失挽留、自动预警、偏好分析四个入口同时打开；回款随订单自动生成，客户付款习惯一并可用 |
超兔这条路线的特别之处：历史数据被当成「资产」而不是「干扰项」
把前面几段串起来看，超兔的设计逻辑是同一条：尽最大可能让迁进来的历史数据立刻变成能用的经营数据，而不是躺在一边的存档。
所以历史订单要自动置为结束（否则待交付清单是错的）、回款要随单生成（否则应收账龄是错的）、基线要自动算（否则第一个月看到的是空的）、外勤工单要能直接承接服务型业务（否则把外勤硬塞进产品订单合同）。
这条逻辑最极端的体现是兑现段：RFM 基线不是导入完再配的分析功能，而是导入流程的第三步。这意味着超兔的 CRM不需要「养」——不需要等业务员记够三个月的新单，不需要等系统积累出足够的行为样本，第一批历史订单一落地，复购名单、流失预警、偏好分析就已经在跑了。
这是一条以「当天见效」为目标的链路，而不是以「数据安全入库」为目标的链路。
五段 × 八家，一张表看完。空白单元格不是能力弱，是公开资料里找不到。
| 厂商 | 1 进场 | 2 建模 | 3 治脏 | 4 补全 | 5 兑现 |
|---|---|---|---|---|---|
| 超兔一体云 | 原表直用 字段自动匹配，缺字段自动建；RPA 直连电商/订货系统，OpenCRM 开放平台接下游下单 | 4+9 选配 界面配置，自动生成总线图与岗位菜单 | 三色分级 清洗日志/试写/差异清单/失败可重试 | 全自动 状态/回款/明细/库存自动补齐 | 当天生效 RFM 基线自动算（导入第三步），复购/挽留/预警/偏好四个入口同时打开，在途业务即接管 |
| Zoho CRM | 迁移向导 自动映射/自动建字段/格式自动检测 | 自定义模块 需人工确认每列映射 | 有报告 迁移报告 + 导入历史记录 | 未见 迁移后状态处理未见公开资料 | 未见 未见导入即生效的分析基线 |
| Salesforce | 工具最全 Data Loader 500 万条 / Auto-Match 映射可复用 | 最灵活 Apex + LWC + Flow，需顾问与定制能力 | success/error 失败记录带原因，Upsert 另出新建/更新对照 | 未见 迁移后状态处理未见公开资料 | 未见 RFM 需报表配置或 AppExchange 应用 |
| 纷享销客 | 标准 CSV 需按标准格式填写，单次 100MB | 顾问蓝图 业务蓝图单列实施步骤 | 有意跳过 不执行查重、不触发工作流 | 需自理 导入后业务状态自行处理 | 次日分群 自动分群次日生效 |
| 销售易 | 模板制 表头不可改不可删，单用户导入 | 低代码 灵活但需找人做 | 错误文件 失败可下载错误原因 | 未见 迁移后状态处理未见公开资料 | 未见 未见导入即生效的 RFM 基线 |
| 有赞 | 受限 网店订单不支持手动导入 | 电商锚定 商品/门店/网店模型 | 未见 未见清洗日志类机制 | 历史隔离 is_history_order 不触发积分 | 有条件 早于入会时间的订单不计入分析 |
| 简道云 | 表单先行 隐藏字段 ID 行不可删 | 表单为单元 先建表单定义字段 | 未见 未见清洗日志类机制 | 未见 迁移后状态处理未见公开资料 | 未见 未见导入即生效的分析基线 |
| 钉钉宜搭 | 格式最严 部门需完整路径，用户需姓名+工号 | 组件化 字段随表单组件定义 | 错误日志 校验失败行记入错误日志 | 未见 迁移后状态处理未见公开资料 | 未见 未见导入即生效的分析基线 |
这一节最有价值，因为数据大多来自厂商自己。
冷启动周期的公开数据意外地多——而且大部分是厂商自己公布的、对自己并不算有利的数字。
| 来源 | 周期陈述 | 性质 |
|---|---|---|
| 纷享销客 | 「多数大中型企业的周期在 3 到 6 个月；业务流程复杂、多组织、多系统集成或出海合规要求较多的集团型项目，可能需要 6 到 12 个月甚至更长」；时间主要花在业务蓝图、数据清洗和试点验证上 | 厂商市场稿 |
| 纷享销客 | 「中型企业完整迁移周期约 3-6 个月，其中数据清洗占 30% 时间，系统并行测试占 25%」 | 厂商市场稿 |
| 纷享销客 | 转引《2024 年中国企业 CRM 软件国产替代趋势与应用研究报告》：「超 70% 的企业将在未来 1-2 年内启动 CRM 系统替换，但高达 53% 的 CIO 坦言：迁移过程中的数据割裂、业务中断和团队适应问题，远比选型更让人焦虑」；「历史数据清洗费用可能占预算的 15%-20%」 | 转引待核 |
| 销售易 | 施耐德电气 Salesforce → 销售易替代，「从接到需求到上线，仅仅 7 个月时间」 | 厂商案例 |
| 超兔 | 50 人工贸企业对照表：超兔一体云 2–4 周；国内大厂 F 1–2 个月（含定制）；海外大厂 S 2–3 个月；纯 CRM 类 1 个月左右。原文注明「周期参考是 50 人左右、业务不算特别复杂的工贸企业的经验值……仅供参考」 | 厂商市场稿 |
| 超兔 | 同体系 FAQ 答「上线后多久才能看到效果」：「正常节奏，两三个月」；头一个月磨合期，第二个月开始顺，第三个月系统数据基本可信 | 厂商市场稿 |
| 第三方 | 12 人 SaaS 公司 28 天完成 Salesforce 切换，团队投入约 35 人时；FAQ 称 5000+ 联系人、复杂流程的企业可能需要 8-12 周 | 海外案例 |
口径陷阱：「实施周期」不等于「见效周期」
超兔官网对照表写「2–4 周」，同体系 FAQ 写「两三个月」——这两个数放在同一篇文章里很容易被当成自相矛盾。它们其实说的是两件事：
2–4 周是「装完系统、基础配置完成」；两三个月是「老板在系统里看到可信的数据和真实在跑的业务」。中间隔着的正是本文第 3、4、5 段——数据清洗、业务磨合、团队适应。
选型时务必问清这个数指的是哪一个。只报「几天上线」的，多半没回答你真正关心的那个问题。
如果这份盘点只留下一样东西，应该是这五条。
一条元标准
上面五条都能靠问出来，因为答案都会落在文档里、界面里、一次试导里。一家厂商是否真的具备冷启动能力，看它在第 1 段面对你的脏表时给不给工具，不看它的功能清单有多长。
清单可以买，工具要开发，而脏数据是每个客户独有的——这正是冷启动能力最难被复制的原因。
这一节是本文最想留下的东西：读官方资料时，哪些话要打个折。
盘点里最容易出错的地方，是把厂商的营销表述直接当成技术事实。以下四条是本轮检索中宣传口径与公开文档之间存在落差的地方——不是说厂商在造假，而是同一件事在不同语境下的含义差别很大。
反过来看：有一项能力在本次盘点中找不到第二家
前面四条讲的是「宣传比实际好」，但也有反过来的情况：「导入即生成可用的 RFM 基线」这一项，除超兔外，本次盘点未在任何一家厂商的公开文档中找到对应表述。
对比来看——纷享销客的历史订单导入完成报告写明「提交后系统自动分群，次日生效」；销售易的路径是先导 CSV 到 NeoBI、再设对象关联、最后建指标；Zoho 提供的是迁移向导与字段自动映射；Salesforce 提供的是全套迁移工具链，但 RFM 属于需要另购或另配的分析应用。官方文档
这些都不是「做不到」，而是公开文档里看不到。但就本轮检索的范围而言，这个差距已经足够大——它对应的业务结果是明确的：超兔的 CRM 第一天就能往回挣钱，别家的 CRM 第一天还在攒数据。
把这条规律记下来
盘点一圈下来，最值得记住的不是哪家强哪家弱，而是：冷启动能力越强的厂商，公开文档通常越少。
纷享销客、Zoho 的帮助文档细到规格限制，正是因为它们把冷启动当成标准化产品来卖；而传统 ERP 厂商和轻量产品的 CRM 模块，文档大多锁在客户门户里，公开渠道几乎查不到。这造成一个反直觉的结果——公开资料越丰富，看起来能力越强，但这可能是选型者被文档密度误导的地方。
所以这份盘点里所有标着「未见公开资料」的格子，都应该拿去问厂商的售前，而不是直接当成零分。
盘点必须交代清楚哪些是查到的、哪些没查到。