案例分享:电信行业零售业务CRM架构

最近跟一个客户讨论销售领域的移动化需求,谈到了他们的零售业务系统的整体框架,觉得很有分享的必要。

这次聊到的客户是电信行业的巨头,说的是他们的零售业务。电信公司么,卖出去的无非是设备和服务。大体的业务分成对大企业级的专门销售(enteprise sales)和对最终消费者及小型用户的零售(retails)。架构比较简单直接,库存财务什么的在ERP,客户主数据在CRM。不过零售不是由销售的员工去做,而是交给批发商(Dealers)。有意思的地方就在于,他们给批发商提供了一个统一的第三方批发管理系统(Dealer System)。在CRM上只管到零售销售线索的创建、验证和第一级分发(按照地区)。之后销售线索同步到Dealer System,地区分销商根据批发商的情况再进行分发,所有的详细线索跟踪在Dealer System完成。Dealer System最终通过批发商使用移动终端一方面直接与ERP的库存取得联系出货,一方面同步交易数据到后台。批发商和分销商再据此和客户分成。

第一遍听下来觉得客户的这个解决方案过于复杂。冒出来的第一个问题是:为什么不放在同一个系统中处理?

因为人太多了?企业销售的负责员工大概200到300人,这些都是接受培训、服从规章制度价值观、必须按照指标完成任务的一般型销售。但是分销商就有1000多,加上批发商总数可能超过13000人。而且分销商和批发商都不是公司员工。这样一来,他们所负责的业务显然应该和CRM隔离开来。所以人多只是技术因素,真正背后的原因是业务上不允许把这批人也加入到CRM中来。

那么为什么不直接放权给它们自己建立系统管理,反而赞助他们系统(Dealer System)?

这是整个架构中比较微妙的一个环节。Dealer System由客户自己建立,免费供应给分销商和批发商使用。其内部有详细的经营网络,人员调配,业务追踪等功能,且提供了强大的Dashboard和移动应用的支持。这无疑增加了分销商和批发商的粘性。同时,通过Dealer System和CRM系统的接口,既控制了作为入口的销售线索来源,又掌握最终的出货和付款信息。在不增加CRM系统额外负载的情况下,轻松实现了对流程的全程监控。

这当中还涉及到很多别的思考,比如,统一的交易系统会不会造成不同地区Dealer的体验差距?比如如何在CRM端也实现细粒度的Dashboard?客户能够真正掌握Distributor和Dealer Agent的performance么?

客户的业务代表说,对于零售业务,我们不是特别关注他们太具体的控制细节。我深明觉厉!

看来我们在整理总结Best Practice的时候,千万要记住联系客户的实际,思考其既有的系统的合理和不合理的部分。对于这个客户,我只能默默地收回之前给他们推荐的基于标准CRM流程的移动应用了。

(完)

上一篇:基于ThinkPHP+AJAX的省市区三级联动


下一篇:if语句与switch语句