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

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

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

　　那范式又是什么呢？

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

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

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

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

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

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