Escanear código QR Carregar código QR
Loja de dominios
Selecione o tipo de plataforma anti-bloqueio para evitar interceptação de links
Selecionar tipos de plataforma permitidos para acesso

避坑指南:聊聊CRM设计中常见的坑!

接着聊聊 CRM 系统设计。这次不聊概念,就讲几个实际踩过的坑,也是看别人反复栽跟头的地方。这些坑有的看起来像小细节,可一旦业务跑起来,影响会一层层放大,后期再改就特别痛苦。

先讲一个很经典的问题:把客户和订单直接绑死。很多早期设计习惯在客户档案底下直接建订单——客户成交了,销售就在客户详情里新建一个订单,这个动作看起来顺理成章。但麻烦往往出在续费上。客户通常有个跟进状态,比如“待跟进”“跟进中”“无意向”“已成交”之类,这些状态对销售管理和数据统计都很关键。如果订单直接挂在客户下面,一旦客户要续费,就得重新分配销售去跟进,客户状态又得从“已成交”改成“续费跟进中”之类的。这么一来,你没法单从客户状态一眼看出他到底有没有成交过,历史数据也搅在一起,统计和分析的准确性大打折扣。尤其当续费、增购越来越多,整个客户列表的状态就越来越乱。

解决这个问题的思路,是在客户和订单之间加一层“商机”。把每一次销售机会抽象成一个独立的商机,原来挂在客户身上的跟进状态,挪到商机上。订单不再直接关联客户,而是通过商机再关联到客户。这样,每次续费或者增购,只需要新建一个商机,这个商机有自己的跟进状态、自己的订单,之前已经成交的商机信息完全不受影响。客户还是那个客户,下面可以挂着多个独立命周期的商机,该完结的完结,该跟进的跟进,彼此清清楚楚。

另一个容易在早期设计里埋雷的,是把联系人和客户一对一绑死。不少系统会把联系人设计成客户的一个属性,包含姓名、电话、身份等等,而且为了防重,联系方式往往被设计成不可修改。表面看没什么问题,但实际场景一复杂,坑就来了。

举个例子,做少儿教育,目标客户是孩子,但来咨询的往往是家长。第一次可能是爸爸来问,系统里记下了爸爸的信息。可实际上,家里管孩子教育的大概率是妈妈,后续销售想跟进,发现联系人信息没法改,爸爸又不是关键决策人,这就很尴尬。再比如企业客户,X 公司的关键决策人王总,后来跳槽到 Y 公司,想在 Y 公司新建联系时,系统只允许新建,可王总在 X 公司积累的那些沟通记录、偏好、决策风格,都带不过来,销售得重新摸索,效率明显下降。

把联系人解耦成独立模块,和客户做多对多关联,就能解决这类问题。一个客户可以关联多个联系人,一个联系人也可以关联到多个客户。这样不光能记录妈妈、爸爸甚至祖辈的信息,还能标记谁是主要决策人。联系人跳槽了,直接让他关联到新公司,之前的历史沟通也能一起带过去,业务的连续性就好了很多。



还有一个坑,不太容易察觉,但影响可能更深——在设计流程或规则时,过度依赖人的自觉。CRM 系统里免不了要制定各种流程,比如订单审核、转案、对账这些。有时候为了图省事,或者怕流程太复杂被业务部门抱怨,就会在某个环节选择相信人性,觉得大家都会按规定来。



我们公司做教育课程时就踩过这个坑。学生买了课,销售在 CRM 里建订单,选课程商品,填支付记录。正常应该是财务核完学费到账,订单才能转到下游的学习系统去排课。但财务对账需要时间,为了让学生尽快上课,我们当时把流程设计成:先转案排课,再慢慢对账。这么做的好处很明显,财务不用被催,销售也能及时安排,用户体验好。但前提是,销售必须确认学生真的付了钱、金额正确,才去转案。结果呢?我们以为大家都会守规矩,实际上有差不多 10% 的订单学费出了问题——要么没到账,要么金额不对,课却已经上了。后续数据乱成一团,财务数据和系统数据对不上,每次都要花大量人工去核对修补。

后来我们顶着销售和财务两边的压力,硬是把对账环节挪到了转案前面,和订单审核绑在一起,成为转案的必要条件。刚上线那阵子,销售天天催财务,财务周末也压力山大。但问题必须解决,我们又和银行合作,接入了实时到账反馈,系统能根据银行返回的到账信息自动对账,完全不用人工介入。这下流程既守住了,效率也没丢,数据终于清净了。



最后一个坑,是关于功能配置权限的开放节奏。系统里经常会设计一些灵活的配置功能,让用户自己定制数据视图、查询条件、显示字段等等,这本来是好事。但什么时候把这种权限交出去,很有讲究。

我们做过一个页面标签自定义功能,用户可以根据自己的需要,自由添加页面标签,配置查询字段、显示字段和数据显示逻辑。功能上线后,确实方便了很多,不用一有新的展示需求就找技术改。但问题在于,我们过早把这个功能开放给了所有业务人员。虽然做过培训,但半年后一看,系统里建了密密麻麻一大堆页面标签,很多都是重复的、废弃的,维护成本反而上来了。后来我们收回了创建权限,先只对业务部门的经理开放,并且要求培训考核通过后才能用。就这么一个小小的调整,冗余标签的问题很快就控制住了。



这几个坑,其实不只局限于 CRM,很多 B 端产品的设计里都可能遇到。比如过早把强配置功能交给不熟悉的用户,或者在流程里过度依赖人工判断,最后都会用更高的成本还回来。做系统设计,有时候不得不直面人性的惯性和业务的真实压力,能用系统规则兜底的,就不要留给自觉性去赌。你如果在设计中也遇到过类似的麻烦,或者有其他踩坑经历,欢迎一起聊聊。