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对象插入, 否则,作为领导人插入。

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

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