CRM上线前先盘数据家底，客户档案与跟进记录定字段与迁移量
CRM上线前先盘数据家底，客户档案与跟进记录定下字段和迁移量
一、数据类型这件事，为什么排在最前面
需求文档里的第一项通常不是功能，而是数据。原因很直接：系统的作用是把数据接住、串起来、算出来，数据的种类和样子决定它能被怎么接。
很多讨论绕来绕去绕不出结果，是因为大家在谈功能，而功能背后的分歧其实是数据。有人说要能看区域业绩，有人说要能看客户分级，这两句话听起来是两件事，落到纸面上其实是同一批数据要按两种口径切。把数据类型先摆出来，这类分歧会立刻现形。
所以顺序上，先列数据、后谈功能，比反过来要顺。反过来做，会出现一种常见的返工：功能都聊完了，才发现某类数据根本没有统一的来源，那条功能也就无从落地。
- ● 功能背后的分歧，本质常常是数据的分歧
- ● 先列数据后谈功能，能省掉一轮返工
图1：数据类型盘点清楚，模块边界跟着清楚
排数据类型的时候，有个顺序可以参考：先列已经在系统里的，再列在个人手里的。前者好找，后者要问。两遍下来，边界就清楚了。
个人手里那部分往往才是重点，因为它们决定了这次整理能收回多少东西。
列数据的时候还有一个实用的小技巧：按「谁最清楚」来分派。客户档案问销售，售后内容问服务同事，报价与回款问财务。各自报各自的，比一个人闭门整理要准。
分派之后，整理的人只负责汇总与去重，不必去猜。
二、按来源走一遍，比按想象写准得多
列数据类型最实用的方法是按来源走，而不是按分类想。
做法很简单：从早上打开电脑开始，把今天会碰到的客户相关内容一件一件过一遍。讲真，谁在哪个文件里查客户电话，谁在聊天工具里记拜访要点，谁在邮件里确认报价。谁在纸质单据上签字。走完一遍，把碰到的东西逐条写下来。
这样做的好处是它不会漏。凭分类想的时候，人会自动省略掉那些「不算正式数据」的东西，比如聊天记录里的口头承诺、纸质单据上的手写批注、邮件往来里的确认。而这些恰恰是后续最容易出问题的地方。它们存在，但没有地方放。
- ● 按来源走一遍，不容易漏掉非正式的记录
- ● 越是不像数据的东西，越容易在迁移时被丢掉
图2：客户信息从哪来，决定要不要接接口
这一层还有一处值得提前确认：字段的必填程度。哪些字段不填就不允许保存，哪些可以留空，这个决定会直接影响一线的录入体验。全部必填会让人抗拒，全部可空又会让数据残缺。
比较稳妥的做法是把字段分成三类：不填就不能继续的、可以先空着但会提醒的、以及完全不用填的。分完之后再逐条对照，争议会少很多。
走来源的时候，建议连「谁在用这份数据」也一起记下来。同一个字段，销售看、财务看、服务同事也看。三种用途对准确度的要求完全不同。
这个记录在后面定字段与权限时会直接派上用场，不必等到那个时候再回头问一遍。
三、客户档案与联系人：最基础的一层
最基础的一层是客户档案与联系人。这一层的内容看起来最简单，实际最容易出现重复和不一致。
同一家企业可能在不同的人手里被记成不同的名字，同一个联系人可能在两处有不同的电话。平时不觉得有什么，等到要把它们合到一起的时候，问题就来了：以哪一条为准，谁来判断这两条是不是同一家。
所以列这一层的时候，除了写清有哪些字段，还要顺手写清一件事：判断两家客户是不是同一家，依据是什么。是名称，是名称加所在地区，还是统一编号。这个依据要在迁移之前定下来，否则迁移现场会变成一场逐条确认的拉锯。
- ● 这一层的难点不在字段多少，而在判断重复的依据
- ● 判断依据要在迁移之前定下来
联系人这一层还有一个常见问题：同一个人在不同客户那里出现。平心而论，比如一家集团下的多个分支。联系人都是同一位采购。这种情况要不要把联系人单独提出来管理。需要在需求阶段给出答案。
答案不同，后面的字段设计与权限设置都会不同。
联系人这一层还要考虑一件事：会不会同时存在多个角色。采购、使用方、决策人、技术评估人，这些角色在不同业务里数量不同。记录方式也不同。
打算怎么记，属于需求阶段就要定的问题，因为它决定了字段的数量与名称。
这一层内容还要考虑存放方式。是全部写在记录里，还是允许挂附件。两种方式的检索体验差别很大，需求阶段就要有一个倾向。
四、过程类内容：跟进记录与沟通痕迹
第二层是过程类内容。这一层的样子最杂，也最容易在选型讨论里被忽略。
过程类内容包括拜访记录、电话纪要、报价沟通、样品寄送、方案确认。它们的共同点是没有固定格式，长度不一，有些是一句话，有些是一段话。有些干脆是一份附件。讨论功能的时候，大家说「要能记跟进」，但真正决定体验的是这一层内容怎么放、放在哪里、能不能被检索到。
还有一个更实际的问题：这一层内容的填写习惯。如果字段设计得过于规整，一线会觉得麻烦，最后只填结论；如果完全没有约束，检索时又找不到。这个平衡点在需求阶段就该讨论，而不是等上线之后再回头调。
- ● 这一层内容最杂乱，也最容易被轻描淡写地带过去
- ● 填写习惯与检索需求要一起考虑，不能只顾一头
图3：跟进记录算哪一类，先分类再决定
还有一类内容常被落在讨论之外：外部材料。比如客户发来的需求文档、资质复印件、对方提供的资料清单。这些东西在业务里不可缺，但很少有人在需求阶段提到它们。结果上线之后发现没有地方放。
列数据类型的时候顺手想一遍这类材料。比后面临时找地方要省事。
还有一类内容值得单独提一句：失败记录。谈崩的客户、放弃的机会、没能推进的线索，这些内容在很多团队里不被记录，但它们对后续判断很有价值。
要不要记录失败原因，属于需求阶段就要定的问题，因为它决定了记录字段的多少，也决定了填写时的感受。
五、交易与服务类内容：报价、订单、售后
第三层是交易与服务类内容。这一层的数据最规整，也最需要和其他系统打通。
报价、订单、回款属于金额相关的内容，通常已经在财务或者业务系统里有一份；售后工单、设备档案、回访记录属于服务相关的内容，往往散在服务同事的个人记录里。简单说，这两类内容要不要进入客户管理系统、以什么方式进入，是需求阶段必须给出的答案。
答案通常有三种：全部搬进来、只搬关键字段、或者保留在原系统里通过接口读取。三种做法的成本差别很大，而选择的依据是业务上需不需要在同一处看到它们。需要频繁同屏查看的，搬进来更划算；只是偶尔核对的，留在原处更省事。
- ● 交易类与服务类内容，性质不同，处理方式也不同
- ● 搬进来、搬关键字段、接口读取，是三条不同的路
图4：售后这类内容要不要一起管，早定
最后补一句：数据类型的清单不必一次做完。第一遍列出主要的几类，后面在实际操作中想到新的。随时补进去。清单是活的，比一开始就追求完整更实际。
还有一点值得提醒：清单写完，最好交给实际在用的人看一眼，请他们补充。整理的人凭印象列，往往会漏掉那些每天都在发生、但没人觉得像数据的部分。
六、常见疑问集中回应
1、问：数据种类不多，也要专门列一遍吗？
答：要。种类少的时候列起来很快，但正是这时候最容易漏掉那些「不算正式数据」的内容。
2、问：列表的时候要不要统计数量？
答：不必在需求阶段统计精确数量。写清有哪些种类、大概多少量级、由谁整理，就够支撑后面的判断了。
3、问：判断重复客户的依据，谁来定？
答：由业务上最了解客户的人来定，负责推进的人记录下来。这一条定得越早，迁移越省事。
4、问：售后类数据一定要进客户管理系统吗？
答：看使用频率。如果服务同事与销售经常要同屏查看，就值得进；如果只是偶尔核对，保留在原处通过接口读取也可以。
5、问：这一步做完，最大的收获是什么？
答：字段清单和迁移量会同时浮出水面。字段清楚，后面的功能讨论才有依据；迁移量清楚，实施排期才排得准。海软CRM在实施前通常也会先盘点一遍客户在用的数据类型，再据此规划字段与迁移步骤。
