CRM系统遭遇云计算 如何确定谁是谁

早期的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对象，那么你插入的其实是一些账户。除非你很细心，不然在会计那是会出错的。

因此对于B2C的CRM系统来说，作为一种存储的价值信息关系是非常重要的。

那范式又是什么呢？

往CRM系统中插入新的人员时，应该使用哪种对象插入呢？这个规则主要取决于你的领导-管理业务流程。但以下是几个基本模式：

*首先，确定此人是否在你的命名账户中。如果是的话，就将其作为该账户的联系人插入。

*接着确定此人是否是你目前的账户。然后按照企业的规则，按联系人或是领导对象插入。

*再者，确定此人是否是个体，如果你需要对其进行即时交易，就将其作为person-account对象插入，否则，作为领导人插入。

*以上皆不是的话，就按照领导对象处理，但需要应用一些层级和评分规则。首先应用地理规则——哪个国家的？然后应用政府和行业规则。最后应用当地地理规则来分配相关销售员和合作伙伴。如果如果对于特定的领导人又充足的信息来使用地理规则，那就到一般的队列中分配一条新的记录。

为了防止破坏数据库，任何领导和联系人的来源——无论是简单的领导流还是一个外部云——在插入之前都需要遵守这写规则。