企業業務模式不同，誰來加粉最合適？

塵鋒

+ 關注

2022-04-06 16:22

616次閱讀

企業微信加好友（加粉）這一環節。作為整個企業微信私域體系落地執行的第一步，其重要性不言而喻，這也是最多私域項目“擱淺”的環節。

在關于加粉這一環節從哪里加、如何加、加上后如何運營的思考后，我們自然而然就會想到另一個更重要的問題：誰來加？

這個問題很關鍵，我們單獨用一期內容來探討。

企業業務模式不同，誰來加粉最合適？

一、關于誰來加粉的迷思

在過去的客戶交流以及項目實踐當中，我們發現關于誰來加粉這個問題，很少被企業當做一個重要的問題來思考，很多企業的處理方式都比較簡單粗暴。

常見的處理方式有兩種：

第一種常見的加粉方式是：在總部或者運營部門里單獨搭建一個運營小組，由幾個在線運營/在線客服的同事組成，所有的好友都由這個小組成員來承接，所有后續的服務和運營執行工作也都由這個小組來進行。

這樣做的企業非常多，比如Oatly燕麥奶、熱風、唯品會、麥當勞、京東運動（也是塵鋒運營顧問團隊服務的案例之一）、玉澤等品牌。

玉澤（上海家化）通過包裹卡等方式將用戶添加至【小澤】企業微信上，邀請用戶入群，在群內通過內容及活動進行運營轉化工作。

麥當勞餐廳通過門店物料將用戶添加至麥麥種草官企業微信上，邀請用戶入群，在群內通過內容及活動進行運營轉化工作。

Oatly燕麥奶通過包裹卡、公眾號引流等方式將用戶添加至小麥力企業微信上，通過1V1方式低頻次地開展運營工作。

這些品牌通過在線運營小組來開展加粉和運營工作，跨過了銷售渠道，與消費者建立了更直接、更有效的連接。

品牌可以更便捷地開展客戶連接和客戶運營，同時也可以更便捷地獲得消費者的反饋。這對于企業實現以客戶為中心的增長體系是非常重要的一步。

但并不是每一家企業都適合這樣做。一個知名的連鎖寵物醫院也采用了這種方式，寵物主人在寵物醫院的門店窗貼、門店前臺以及醫生桌卡上掃的企微二維碼，都加到了叫做【小乖/小新/豆豆寵物顧問】的身上，寵物顧問的定位是為寵物主人提供專業的寵物護理知識和指導以及福利禮品等。

寵物主人咨詢診療后的護理事宜，線上運營小組對寵物基本情況及治療過程缺乏了解，溝通效率低、體驗差，無法真正達到驅動業務增長的效果。

在這個場景里，在線運營小組的弊端就暴露出來了。

寵物主人接觸的是門店的前臺、醫生、醫生助理等，寵物主人會因為前臺的細心周到和醫生的專業耐心而對一家寵物醫院產生好感和信任，這種信任將能夠幫助一家寵物醫院獲得一個非常忠誠的客戶，甚至獲得一個忠誠客戶的整個寵友圈。

但是，當寵物主人在線進行咨詢的時候，這個帶著企業名稱小尾巴的在線寵物顧問卻對顧客和寵物以及診療過程一無所知。

這種缺乏基礎的關系很難建立起來，也很難真正起到作用，甚至可能會傷害顧客體驗，造成顧客流失。

第2種常見的加粉方式，與第一種相反，不額外設置運營小組，讓企業所有能接觸到客戶的員工都加粉。簡單來說就是能加的都加，加的越多越好。

這種方式很顯然能夠解決前面寵物醫院案例里發生的問題，很多高客單價的行業都會選擇這種方式，比如家裝行業、消費醫療行業以及企業服務行業等。通過這樣的方式，每個與客戶交流的人與客戶都有信任關系基礎，更容易基于關系實現增值和增長。

但這種方式也有弊端，除了企業的私域客戶池會存在大量重復客戶外，最大的問題在于關系交叉產生的管理問題。

比如某家裝企業，投放團隊的客服、銷售、設計師、管家都加了客戶，新媒體的團隊通過公眾號推文也觸達并加上了客戶，一個客戶可能有這家企業的5、6個員工的企業微信。其實這本身并沒有問題，對每個環節而言，企業微信都增加了線上的溝通渠道，可以更便捷有效地提升每個環節的效率和效果。

但是如果企業沒有對每個角色的服務形象和服務邊界做出清晰有效的設計，客戶就會感到困惑和混亂，更極端的情況是這家企業的不同部門給客戶的報價、保障條款也不同，企業完全可能因此徹底失去這個客戶。

二、不同業務模式下，企業該如何合理分配加粉和運營的職能？

我們建議企業可以參考以下方式進行設計和規劃：

對于B2C業務（低客單價C端業務）如快消品品牌商、零售商、平臺電商等，可以采用建立在線運營小組的方式，開展加粉和運營。
對于B2B和B2C業務（高客單價C端業務）如醫美、口腔、家裝、制造、教育、企業服務等，建議企業梳理業務流程，針對業務流程中的關鍵節點，增加加粉和運營工作。

比如在一家醫美企業的業務旅程中，投放團隊的客服、咨詢師、醫生都應該用企業微信添加客戶，但是一定要界定清楚每個角色的運營邊界，客服添加客戶企業微信與客戶交流是為了提升客戶到店率，咨詢師添加客戶企業微信是為了提升客戶的轉化率，而醫生添加客戶的企業微信是為了為客戶提供專業的診后咨詢、提高客戶的滿意度，每個角色為自己環節的指標負責。

這些職能的不同也應該要體現到企業微信的形象設計上，避免客戶產生混亂。

下表是一個簡單的運營設計框架：