CIO关注:CRM系统遭遇云计算的烦恼_SaaS_云计算

CIO关注:CRM系统遭遇云计算的烦恼

2011/12/02

　　早期的CRM相当的简单：人是人，公司是公司。往CRM数据库里插入新的人员也相当明确，不管是直接进入或是通过跨云的整合访问CRM系统。经探究，发现有两个因素复杂化了CRM系统。在众多的联系人里建立领导关系，CRM系统就变的更复杂了。相当有意思的是，一些CRM系统为B2C用力建立一个person-count概念。销售人员声称这些领导才是最初的机会，尽管这些对象在CRM系统中必须单独放置。为了好玩，他们增加了一个命名账户模式，向联系人里添加领导关系，尽管这些领导处于一个标准销售模式。

　　如何往CRM系统中添加新人员记录呢？我们来看看。

　　领导vs联系人

　　返回到最基本来说，你也许会说“无论如何我们为什么都需要领导关系，每个人都只是单纯的联系人不可以么？”事实上，有些案例可以说明这样做事完全正确的（当然，其他人认为这是完全错误的）。一般来说，对于领导人，我们对其的了解很少，而我们与联系人的沟通很多，了解很深。通常情况下是，领导人很少会和账户捆绑，但是联系人肯定能捆绑上。

　　领导人在CRM系统中有些特殊的性能：

　　1.系统将会通过规则向领导分配代表

　　2.领导底下有的不只是个人，是一个团队。

　　如果你们企业有一个成熟的领导组，这些特征将会非常有价值。
　　
　　如果你是一个纯粹的B2B公司，没有一个成熟的领导组合和一个单纯的命名式的销售账户模式，你很有可能丢失一些领导表格。实质上，每个人都是一个联系人，因为你不仅仅对于你命名的账户感兴趣。

　　在众多的B2B公司里，尽管你没有一个成熟的领导组，你也不能取出领导表格。如谷歌的Adwords、滴管营销系统和社交网络工具等云中的销售系统，他们重视基于领导对象运作的。这些和你的CRM系统整合的云可能不允许你使用联系对象来代替。

　　更进一步来说，如果你是一个B2C的商店，使用的是person-accounts模式，你就会后悔你放弃了领导关系。

　　人VS账户

　　在B2C的世界里，消费者都是个人。即使他们是公司的一部分，系统中不再使用上述方法来处理他们。公司在做电子商务和接受信用卡的时候，这个问题就很普遍了：每一笔购买都是持卡人JohnDoe消费的，但他却没有一个真正的账户与其绑定。在一些系统中，就会将这些公司归为“个体”。

　　这时就有了person-account这个模式，这个模式让上述的情况变得简单化，这个模式就是使用一个包含联系人和账户的混合对象。当浏览到person-account对象时，本质上来说并不是一个联系人，而只是一个账户。因此往你的CRM系统中插入一个新的联系人时，如果你用的是person-account对象，那么你插入的其实是一些账户。除非你很细心，不然在会计那是会出错的。

eNet硅谷动力