搬纷享销客的数据之前，先盘自定义对象和审批流
搬数据这类事，大家以为难在数据多，其实难在配置。普通字段好搬，客户表、联系人表、订单表，导出来就是标准表格，走到哪都能导进去。真正搬不动的是两样：自定义对象和审批流。用纷享销客用得深的团队，搬家前先把这两样盘清楚，工作量才估得准。顺序也定了：先盘配置，再搬数据，反着来就是白搬。
自定义对象，一条一条盘
成熟团队用通用型 CRM，很少只用标准对象。项目立项、设备台账、投标记录，多半建成了自定义对象，每个对象下面挂着一套自己的字段和关联关系。盘的办法：把老系统里的对象列表截个图，每个对象问三个问题，谁在用、多久填一次、搬过去放到哪。顺带把每个对象挂了几个字段、关联到哪张表也记下来，字段数和关联关系直接决定降维的难度。天天在填的要搬，半年没人动的就别搬了。别一个人闷头盘，拉上真填这些表的销售一起，填表的人最清楚哪些字段是摆设。
盘完会发现三种去处。还在活跃的，数据挑重点迁；偶尔查一查的，导出成表格存档，要用的时候翻表；早就没人填的，连导都省了。一家做环保工程的客户盘出六个自定义对象，真要迁的只有两个，剩下四个都躺在第二、三种里。别一个人闷头定，去处的结论要拿到例会上让填表的人点头，搬完发现漏了要的，再回老系统翻一遍，工时翻倍。
千营没有自定义对象，这是要如实说清的边界。对象里的数据迁过来只能降维：项目信息并进客户详情的跟进记录，设备台账用「字段设置」在客户或订单上加字段，投标记录拿标签加「预约回访」顶。举一个实在例子：投标记录对象降过去，就是给在投的客户打上标签，再建一条开标当天的「预约回访」，开标结果出来写进记录。原来的关联关系拆散了，这是降维的代价，接受不了就别急着搬全量。
审批流，搬不动只能重建
审批流是纯配置，导不出表格，到了新系统只能照着旧的重新配一遍。先数一数老系统里有几条审批流，每条几个节点、谁审、超时怎么办，一张纸列完。数完常常吓一跳，用顺了的团队十来条不稀奇。列的时候把每条流挂在哪个对象上也注明，后面降维的时候对着看。
千营没有审批流模块，审批这活儿在线下走：合同审批照原来的规矩签，签完的结果写一条「跟进记录」，注明谁批的、哪天批的，合同扫描件传在记录附件里。节点多、管控严的企业会觉得退步，节点本来就一两道的小厂影响不大。要是数出来有超过五条、每条三四个节点的大流，讲句实话：要么留一部分在老系统用，要么选个自带审批的产品，硬降下来会出事。折中一步是给审批结果立个统一的写法，比如记录开头统一写"审批"两个字加节点名，回头按关键字一搜，哪单走到哪一步全出来。
数据本体的搬法
盘完配置，再说数据。客户和联系人从「导入线索」走模版进线索池，再「转为客户」自动映射，字段对不上的先在表格里对一遍，金额和日期列的格式先统一；在跑的订单手工「创建订单」，收款照合同拆分阶段收款；历史跟进记录只搬还在跟的客户最近半年的，联系人逐户补进客户详情页，三年前的旧账留在老系统只读查。老系统账号留三个月，别急着退。离职销售的客户进来后统一用「变更归属人」改到接手人名下。
导完的验证别跳过：每五十家抽三家，把老系统里的字段和新系统里的逐项对一遍，错一个字段说明模版映射有偏差，早发现早改，晚了就是几千条一起返工。抽检之外再抽几条跟进记录，看日期和内容有没有张冠李戴，记录串了客户，比字段错更难查。
工时怎么估
配置重建这块要单列。数据导入以天计，自定义对象的降维改造和审批流的线下化，往往要按周计，因为每一条都要有人判断放哪、舍哪。两个对象、一条审批流的团队，留两三周给这块是合理的；对象多关联复杂的，往上加。先拿一个业务线试搬，走通一遍再推全公司。试搬期间定一个每天收工动作：把当天搬完的条数和老系统里的存量对一下，进度和偏差心里有数。
搬之前还有个动作别省：拿老系统的对象清单和千营的功能清单摆在一起对一遍，对不上的那部分，要么接受降维，要么留一半在老系统里只读用着，别硬塞。两个系统并行的那几个月，规矩要先说死：新数据只进新系统，老系统只查不改，不然两头的记录越走越岔，到头来哪边都不是全的。哪些对象该留该舍，项目型销售CRM里按项目型团队的用法列了取舍标准，千营CRM免费版可以先建十家客户，试试降维后的手感，再决定搬不搬全量。
