CRM系統遭遇雲計算 通用范式確定誰是誰

發現有兩個因素複雜化了CRM系統。 在眾多的連絡人裡建立領導關係， CRM系統就變的更複雜了。 相當有意思的是，一些CRM系統為B2C用力建立一 個person-count概念。 銷售人員聲稱這些領導才是最初的機會... 儘管這些 物件在CRM系統中必須單獨放置。 為了好玩，他們增加了一個命名帳戶模式 ，向連絡人裡添加領導關係，儘管這些領導處於一個標準HTTP://www.aliyun.com/zixun/aggregation/6524.html">銷售模式。 如何往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物件插入， 否則，作為領導人插入。

_*以上皆不是的話，就按照領導物件處理，但需要應用一些層級和評分規則 。 首先應用地理規則——哪個國家的？ 然後應用政府和行業規則。 最後應 用當地地理規則來分配相關銷售員和合作夥伴。 如果如果對於特定的領導 人又充足的資訊來使用地理規則，那就到一般的佇列中分配一條新的記錄 。

為了防止破壞資料庫，任何領導和連絡人的來源——無論是簡單的領導流 還是一個外部雲——在插入之前都需要遵守這寫規則。

(責任編輯：admin)