CRM试用还只看演示就输了？把自己的客户数据导进去，走一遍日常动作
CRM试用别只看演示，导入真实客户数据把销售日常动作走一遍
一、演示看到的是最好的一面
演示环节的信息量其实很小。对方会挑最顺的路径走一遍：客户资料很干净、跟进记录很完整、报表一点就出来。这套操作被演练过很多次，不会出错。
问题在于，演示展示的是「在理想数据下能做什么」，而日常要面对的是「在真实数据下会遇到什么」。这两件事差得很远。演示里的客户名字整齐划一，真实数据里同一家企业可能有三种写法；演示里的跟进记录条条完整，真实数据里很多记录只写了寥寥几个字。
所以演示可以看，但它的作用是了解大致方向，不是做判断。把演示当成试用，是选型里最常见的省事方式。代价通常在上线之后才付。
- ● 演示展示的是理想数据下的最好路径
- ● 把演示当试用，代价会在上线之后才出现
图1：试用要用自己的数据，才看得出问题
演示还有一个容易被忽略的问题：它展示的往往是最理想的路径。真实的日常里，客户名字重复、记录只写了一半、附件找不到，这些才是常态。你觉得呢？
用理想状态下的表现去判断日常体验，偏差会很大。
试用之前建议先想好要验证什么。什么都不带就进去试，出来往往只剩下「感觉还行」。
把要验证的几条写在纸上带进去，试完逐条打勾或者打叉。
二、试用的第一件事：把自己的数据带进去
真正的试用从导入自己的数据开始。
做法上不必搬全部，挑出一小段有代表性的内容就够：一批有重复情况的客户、几条长短不一的跟进记录、一份带附件的报价。导入之后先看一件事，数据是不是完整地进去了，有没有字段被截断、有没有内容被丢掉。
这一步往往就能暴露出不少问题。有些方案对字段长度有限制，长文本进来会被切掉；有些方案对附件有另外的存放方式，导入之后要找一下才知道放到了哪里。不绕弯子，这些问题在演示里永远看不到，因为它们只会在真实数据上发生。
导入之后还要看第二件事：这些数据能不能被检索到。用日常真的会用的方式去搜几次，比如按行业搜、按上次联系时间搜、按某个关键词搜。搜得到，说明这一层可用。
- ● 挑一小段有代表性的数据导入，先看完整性
- ● 再用日常的方式搜几次，看能不能找到
图2：派单这类规则，试用时就试着配一遍
走动作的时候，建议安排一次异常路径的尝试。日常最顺的那条路谁都会走，真正决定体验的往往是异常情况：客户名字重复了怎么处理、记录填错了能不能改、同一条被别人先改了会怎么样。
这些情况在演示里不会出现，在日常里却经常遇到，提前试一次比上线之后临时应对要从容得多。
导入数据之后，建议顺手做一次随机抽查。抽几条记录，和原始内容逐字比对，确认没有错行、没有截断。
抽查花的时间很短，但它是判断这次导入是否可信的最直接方式。
还有一个细节：试用的时候要用自己平时用的设备。桌面端试得顺，不代表手机端也顺，而很多一线同事主要在手机上操作。
设备不同，体验差别很大，这一点在试用时最容易被忽略。
有条件的话，让参与试用的同事各带自己常用的设备来试一遍。
三、真实的动作走一遍，卡点才会暴露
数据进去之后，接着要做的不是看功能菜单，而是把自己日常的动作走一遍。
动作要挑最常做的那几个。比如录入一条新客户、把一条商机往前推一个阶段、生成一份阶段分布、把一个客户转给别人。每走一个动作，顺手记两件事：走了几步，中间有没有停顿。
「走了几步」这个数字很说明问题。同一个动作，有的方案需要几步就完成，有的需要先切页面、再选条件、再确认。走下来要十几步。单看一次不觉得有什么，但这些动作每天都要做好几遍。
「中间有没有停顿」指的是那些需要停下来想一想的地方：这个字段该填什么、这条记录归到哪一类、这里能不能跳过。停顿越多，说明系统的规则和日常习惯之间的差距越大。上线之后需要适应的时间也越长。
- ● 用最常做的几个动作走一遍，记录步数
- ● 停顿的地方，就是上线之后要适应的地方
图3：流程能不能配出来，试用时最清楚
试用的人数不必多，但岗位要齐。说到底，一个负责录入的人、一个负责查看的人、一个负责汇总的人。三种视角的反馈差别很大。
人齐了，问题也会暴露得更全。只看一个人的感受，容易把个人习惯当成普遍需求。
试用的时候，建议安排一个人专门记录，他自己不参与操作。操作的人容易沉浸在动作里，旁观的人更容易注意到停顿与犹豫。
记录的人不需要懂系统，只需要把看到的如实写下来。
四、让一线来试，不要让技术来试
试用由谁来操作，直接决定了试用结果的成色。
由技术同事来试，通常会得到偏乐观的结论：他们熟悉系统操作，遇到卡点会自己绕过去，也更容易对功能设计给出宽容的评价。但这些恰恰是最需要暴露的部分。
由一线来试，情况会不一样。他们不熟悉界面，遇到不顺手的地方会直接说出来，也会用自己习惯的方式去操作。这些反应才是上线之后真实会发生的情况。所以试用阶段最该做的一件事，是安排真正要用这套东西的人上手，哪怕只试一两个动作。
试的时候不要给太多指导。必要的说明给完就让他自己走，遇到问题先记下来，不要立刻替他解决。那些被记下来的问题，就是后续要重点确认的地方。
- ● 技术同事试出来的结论往往偏乐观
- ● 试用时少给指导，把卡点记下来就是收获
记录的时候建议按动作分条写，不要按感受写。写「新客户录入需要几步、卡在哪一步」比写「体验一般」有用得多，因为前者可以直接拿去和别的方案对比。后者只能靠回忆。
另外，记录里最好标明是谁试的。不同岗位的同事试同一个动作，感受往往不同，写清来源。后面回顾时才知道该问谁。
试用结束之后，建议安排一次简短的集体回顾。每个人说自己遇到的卡点，当场归类。集体回顾能避免个人的片面印象被当成结论。
记录里还可以加一栏：这条问题影响谁。影响一线的和影响管理者的，处理顺序应当不同。
写清影响对象，后面排优先级就有依据。
五、试用结束要留下什么
试用结束之后，最容易犯的错误是只留下一句结论。
比较有用的做法是留下一份记录：哪几个动作走了几步、哪些地方的字段对不上、一线提出了哪些意见、哪些问题是方案能改的、哪些是只能靠调整习惯来适应的。简单说，这份记录不用很长，但要在试用当天写完。隔几天再写会忘掉细节。
这份记录还有一个延续的用途：它可以作为后续验收时的对照。试用时记录下来的问题，交付时逐条看有没有解决；试用时觉得顺的动作，上线后确认还是顺的。有了这份对照，验收就不再是凭印象。
- ● 试用当天就写完记录，隔几天细节会忘
- ● 这份记录可以在验收时拿来做对照
图4：现场环节好不好用，让一线自己说
还有一条提醒：试用阶段的承诺要落到纸面。对方说某处能调整，就在记录里写明调整的方向和预计时间。双方确认。口头承诺在项目推进中很容易被遗忘。
试用结束之后还有一件事：把记录里的问题按「影响日常的程度」排一下。影响大的排在前面，影响小的可以后面再看。排序之后，讨论就有了先后。
六、大家问得最多的几个问题
1、问：试用多久比较合适？
答：以能否跑完几个真实动作为准，不必按固定天数。动作跑完、问题记完，就可以结束了。
2、问：试用要导入多少数据？
答：一段有代表性的就够，不必全量。重点是覆盖到重复项、长文本、附件这几种容易出问题的情况。
3、问：一线不愿意配合试用怎么办？
答：把试用安排在他们日常最烦的那一步上，让他们自己感受差别。空洞地讲好处，不如走一遍动作。海软CRM在试用阶段通常也会配合企业把真实数据导进去跑一遍，而不是只做一轮演示。
4、问：试用中提出的问题，对方说以后能改，怎么判断？
答：看它属于哪一类。配置类的通常很快能改；需要开发的部分，要问清在什么版本、什么条件下提供。
5、问：多个方案都要试用，怎么安排？
答：同一个动作在同一批数据上分别走一遍，记录步数与卡点，横向对比。这样比分别感受更靠得住。
