做CRM選型的人最近應(yīng)該都繞不開一個名字——DeskcommCRM。我第一次接觸到這個系統(tǒng)的時候說實話是抱著半信半疑的態(tài)度去的畢竟市面上叫得上名字的CRM從國際大廠到開源項目一大堆憑什么要選一個聽起來不那么眼熟的方案但真正把Demo環(huán)境跑起來、把真實的業(yè)務(wù)數(shù)據(jù)灌進去、帶著銷售團隊用了兩個月之后我對它的看法有了實質(zhì)性的改變。這篇文章不打算做那種羅列功能點的產(chǎn)品介紹我想從一個甲方技術(shù)負責(zé)人兼產(chǎn)品推進者的角度把DeskcommCRM從選型評估、部署實施、數(shù)據(jù)遷移、系統(tǒng)集成到后續(xù)運維的完整過程以及過程中踩過的坑和復(fù)盤結(jié)論一次性講清楚。如果你正打算上CRM或者在幾個候選系統(tǒng)之間猶豫這篇文章能幫你省掉不少彎路。這里面的很多評估思路和實操細節(jié)不只是對DeskcommCRM有效換到任何一套CRM上方法論都是通用的。尤其是在買套裝還是自研標準功能夠不夠用集成到底怎么做才不死這些關(guān)鍵問題上我的經(jīng)驗應(yīng)該能給你一個比較靠譜的參照系。1. DeskcommCRM產(chǎn)品定位與適用場景分析1.1 它到底解決的是什么問題先說清楚DeskcommCRM在市面上屬于哪一類產(chǎn)品。它不是一個垂直行業(yè)的定制CRM也不是一個輕量級的客戶管理插件而是一套通用型、可私有化部署的客戶全生命周期管理系統(tǒng)。所謂全生命周期指的是從線索進入、分配到銷售跟進、商機推進、合同簽訂、訂單執(zhí)行到后續(xù)售后服務(wù)的完整鏈條它都能覆蓋到。這一點比很多只有客戶列表跟進記錄的輕量CRM要重得多也比那些只盯住銷售漏斗某個環(huán)節(jié)的工具要全面。在實際使用中我感受到它最核心的價值在于三點。第一客戶數(shù)據(jù)不再是散落在各個銷售手里的Excel和微信聊天記錄而是統(tǒng)一收口到系統(tǒng)里有權(quán)限控制、有操作留痕、有完整的時間線。第二銷售流程可以真正跑起來從線索到回款每個階段該做什么動作、卡在哪個環(huán)節(jié)超過多少天會觸發(fā)預(yù)警系統(tǒng)都能管住。第三管理層能拿到實時的、可信的數(shù)據(jù)以前做銷售預(yù)測靠感覺現(xiàn)在可以按階段轉(zhuǎn)化率、平均成交周期來粗略推算準確性高了一大截。這個定位決定了它的基本盤是幾十人到幾百人規(guī)模、有明確銷售流程、需要跨部門協(xié)作銷售市場客訴財務(wù)的中小企業(yè)和成長型公司。團隊再小一點Excel加上企業(yè)微信基本夠用花力氣上CRM反而是負擔(dān)團隊再大、業(yè)務(wù)流程再復(fù)雜標準品又往往扛不住得往更重的平臺型CRM或者定制開發(fā)去走。1.2 什么類型的團隊適合用什么情況要謹慎基于我這次落地的經(jīng)驗我建議你先對號入座一下再決定要不要繼續(xù)深入評估DeskcommCRM。適合它的團隊畫像大概是這樣的團隊有比較穩(wěn)定的銷售流程不是那種完全靠銷售個人自由發(fā)揮的打法客戶量大、跟進的線索多需要一個統(tǒng)一的地方來沉淀信息和記錄過程管理層對銷售數(shù)據(jù)的實時性有要求希望能看到每一天的漏斗變化而不是月底才拿到一張Excel匯總表有基本的信息化能力哪怕只有一兩個懂點數(shù)據(jù)庫和服務(wù)器的人也能把系統(tǒng)維護起來。反過來如果下面這些情況占了大多數(shù)我建議你要慎重公司處于極早期銷售就幾個人老板自己也說不清流程長什么樣這時候上CRM大概率是折騰業(yè)務(wù)流程極度特殊行業(yè)屬性非常強比如復(fù)雜的供應(yīng)鏈協(xié)作、極度個性化的報價規(guī)則標準產(chǎn)品要改造的地方太多公司連一個能做基礎(chǔ)運維的人都沒有而你們又選了私有化部署——這套系統(tǒng)雖然不算重但也絕不是裝完就不用管的東西。我當時選擇繼續(xù)往下走是因為團隊規(guī)模、業(yè)務(wù)復(fù)雜度、流程成熟度三點都匹配上了。選型這東西很多時候不是系統(tǒng)不好而是場景不匹配。先想清楚自己的位置再去看產(chǎn)品才不會跑偏。2. 選型評估我拿什么標準來檢驗和試用2.1 對方承諾的功能一定要用真實數(shù)據(jù)過一遍很多CRM選型項目死在哪死在廠商Demo做得太漂亮而自家真實業(yè)務(wù)數(shù)據(jù)一進去就原形畢露。所以我們的流程很明確所有入圍產(chǎn)品先不接受PPT演示和專人講解直接拿我們脫敏后的真實線索明細、客戶檔案、訂單記錄讓廠商導(dǎo)入到測試環(huán)境我們再模擬真實的銷售操作去跑一遍。這一輪下來就篩掉了不少產(chǎn)品。有跑大數(shù)據(jù)量明細時列表頁直接卡死的有導(dǎo)入關(guān)聯(lián)數(shù)據(jù)時外鍵關(guān)系處理不好的還有權(quán)限模型太簡單沒法做到銷售只能看到自己的客戶、主管能看到全組、大區(qū)負責(zé)人能看到區(qū)域內(nèi)所有客戶的層級隔離的。DeskcommCRM在這一輪表現(xiàn)是過關(guān)的。十萬級線索量、二十萬級的跟進記錄在普通配置的服務(wù)器上翻頁、篩選、導(dǎo)出都沒有明顯的性能問題。導(dǎo)入方面它支持標準的Excel模板分批導(dǎo)入并且對字段合法性手機號格式、客戶名稱去重、必填項檢查有前置校驗出錯的記錄會單獨標出來不會動不動就把整批數(shù)據(jù)打回重來。這對數(shù)據(jù)治理比較弱的團隊來說是相當友好的設(shè)計。另外還有一個細節(jié)我特別提一下DeskcommCRM的列表頁可以自定義列、保存?zhèn)€人視圖并且支持把視圖分享給同組或者全公司的同事。這個功能看起來不起眼實際用起來卻非常關(guān)鍵。銷售想看的字段和主管想看的不一樣主管和客服想要的篩選條件也不一樣。沒有好的視圖管理機制最后的結(jié)果就是每個人都在抱怨系統(tǒng)里找不到我要看的東西然后回到Excel主義。2.2 擴展能力和二開成本比功能列表更重要我見過太多團隊選CRM盯著功能清單一條一條對號入座卻忽略了這個系統(tǒng)未來能不能跟著業(yè)務(wù)一起變。CRM這東西一旦用起來數(shù)據(jù)會越積越多業(yè)務(wù)邏輯也一定會調(diào)整如果二開太麻煩后期的每一次需求變更都可能成為項目團隊的噩夢。關(guān)于DeskcommCRM我重點看了它的配置能力和二次開發(fā)接口這里給大家?guī)讉€可復(fù)用的判斷方法。第一看對象模型。系統(tǒng)內(nèi)置的客戶、聯(lián)系人、商機、合同這些對象能不能擴展自定義字段能不能新建自定義對象比如續(xù)費記錄項目交付里程碑這種業(yè)務(wù)特有對象。第二看業(yè)務(wù)流程。標準審批流能不能通過配置實現(xiàn)還是只能寫死。第三看自動化能力。能不能在客戶狀態(tài)變更這類事件上觸發(fā)后續(xù)動作比如自動給負責(zé)人發(fā)通知、自動創(chuàng)建跟進待辦。第四看API開放程度。有沒有完整的REST API能不能做到增刪改查、能拿到哪些數(shù)據(jù)范圍這些都直接決定了集成時的工程量。模板化的判斷標準之外我也多說一點我們在選型時的預(yù)期管理不要指望任何一套CRM開箱就能覆蓋你所有的流程細節(jié)一定會有差異化的部分需要做二次開發(fā)或者流程變通。DeskcommCRM的可擴展性在這個級別里屬于中等偏上的水平尤其是自定義對象這一塊比很多閉源SAAS產(chǎn)品要靈活不少。但靈活也意味著你需要有懂配置的人不是點兩下鼠標就能完成的。3. 部署實施從環(huán)境準備到數(shù)據(jù)上線的完整鏈路3.1 環(huán)境依賴與實際部署過程中容易被忽略的細節(jié)DeskcommCRM支持私有化部署這通常是一些對數(shù)據(jù)安全要求較高、或者希望深度定制客戶體驗的公司會格外看重的一點。我們當時選的是Docker Compose方式部署整體結(jié)構(gòu)還是比較清晰的應(yīng)用服務(wù)、數(shù)據(jù)庫PostgreSQL、緩存Redis、對象存儲文件上傳再加一個反向代理入口。官方提供了一套docker-compose.yml模板理論上可以做到一條命令拉起來。但真正實操的時候有幾個地方不仔細看就會踩坑。首先是數(shù)據(jù)庫連接參數(shù)里的時區(qū)設(shè)置。我們第一次部署完成后發(fā)現(xiàn)系統(tǒng)里記錄的時間比本地時間整整慢了8小時排查了半天最后定位到是數(shù)據(jù)庫連接的timezone參數(shù)沒有寫對。這個問題在測試環(huán)境少數(shù)據(jù)量時不容易暴露一旦早晚高峰大家都在錄跟進記錄時間戳錯亂的后果就很嚴重了。其次是文件存儲路徑的權(quán)限?？蛻羯蟼鞯暮贤郊?、產(chǎn)品資料這些文件容器里用的是普通用戶身份運行宿主機掛載的目錄權(quán)限不對就會導(dǎo)致上傳失敗。這個報錯不會在界面上給得很直觀往往是保存成功但附件列表為空或者直接拋出500需要去應(yīng)用日志里追蹤。部署文檔里其實有寫但在一大堆環(huán)境變量里很容易被忽略。第三是多實例部署時要注意Redis的共享配置。如果你打算用兩個應(yīng)用實例做負載均衡那么定時任務(wù)、 Session 這些必須借助Redis來同步否則會出現(xiàn)同一個客戶被兩個實例同時處理、定時提醒重復(fù)發(fā)送的奇怪現(xiàn)象。我們的處理辦法是把定時任務(wù)單獨拆到一個實例上跑應(yīng)用請求走另外的實例避免重復(fù)觸發(fā)。這個方案在很長一段時間內(nèi)都非常穩(wěn)定。提示部署之前務(wù)必把官方文檔里的環(huán)境變量表完整過一遍尤其是和數(shù)據(jù)存儲、時區(qū)、文件路徑相關(guān)的配置項不要想當然用默認值。寧可多花半天時間核對也不要在上線之后才發(fā)現(xiàn)時間不對、附件傳不上、任務(wù)重復(fù)跑。3.2 客戶數(shù)據(jù)遷移清洗、映射和校驗三步走數(shù)據(jù)遷移是整個上線過程中最枯燥、也最容易翻車的環(huán)節(jié)。我們當時把歷史數(shù)據(jù)從兩套Excel和一套舊的客戶管理小工具里導(dǎo)出來合并成一份規(guī)范的導(dǎo)入文件。光這一步就做了將近兩周原因很簡單同樣的一個客戶在Excel里叫A公司在舊系統(tǒng)里叫A有限責(zé)任公司電話一個填的是手機一個填的是座機還有大量重復(fù)錄入的線索這些數(shù)據(jù)問題不解決導(dǎo)進去就是災(zāi)難。我的建議是遷移動作嚴格按清洗、映射、校驗三步走。清洗階段重點做去重和補全。先用客戶名稱和聯(lián)系電話做兩輪模糊匹配把疑似重復(fù)的數(shù)據(jù)挑出來人工確認然后統(tǒng)一字段格式比如電話統(tǒng)一成11位手機號或帶區(qū)號的座機格式、日期統(tǒng)一成yyyy-MM-dd最后是補全規(guī)則所有必填字段必須有值沒有值就按業(yè)務(wù)規(guī)則填默認值比如來源渠道填歷史導(dǎo)入。映射階段把舊數(shù)據(jù)的字段對應(yīng)到DeskcommCRM的字段。這個環(huán)節(jié)要特別注意自定義字段的提前配置。DeskcommCRM里客戶對象除了標準字段之外你可以在后臺先建好客戶行業(yè)客戶等級建檔時間這些自定義字段然后在導(dǎo)入模板里選擇對應(yīng)關(guān)系。建議先在一個測試團隊里做一遍導(dǎo)入演練確認無誤后再正式執(zhí)行。校驗階段導(dǎo)入完成后不要急著通知大家系統(tǒng)上線了先跑幾組統(tǒng)計SQL或者用系統(tǒng)自帶的報表功能核對總數(shù)客戶總數(shù)對不對、聯(lián)系人數(shù)對不對、金額字段加總后和歷史賬目是否一致。還要抽幾個關(guān)鍵客戶翻一下詳情頁里的字段是否都正確。這些動作做完再向全公司宣布舊系統(tǒng)可以停用了。我們最后導(dǎo)入的數(shù)據(jù)量大約是客戶檔案3萬、聯(lián)系人6萬、歷史跟進記錄18萬。在DeskcommCRM里全量導(dǎo)入加索引重建總共花了一個多小時過程沒有報錯。這個表現(xiàn)我是滿意的關(guān)鍵是導(dǎo)入工具帶了批量提交和日志跟蹤哪一批出錯、哪一行被跳過都記錄得清清楚楚不像某些系統(tǒng)一導(dǎo)數(shù)據(jù)就整體失敗、連定位問題的入口都沒有。3.3 流程配置銷售階段、權(quán)限模型和審批流怎么設(shè)數(shù)據(jù)到位之后最重要的工作就是把業(yè)務(wù)流程在系統(tǒng)里搭起來。這一步如果草草了事后續(xù)再改的代價極大。我們重點配置了三塊銷售階段、權(quán)限模型、審批流。銷售階段配置直接決定漏斗報表能不能反映真實情況。我們當時的階段定義是初步溝通、需求確認、方案報價、商務(wù)談判、贏單/輸單。DeskcommCRM里可以對每個階段設(shè)置贏單概率這個值是管理層做銷售預(yù)測的基礎(chǔ)。這里我踩過一個具體的坑贏單概率設(shè)得過于樂觀比如初步溝通就設(shè)了20%方案報價就設(shè)了60%導(dǎo)致系統(tǒng)里預(yù)測的業(yè)績金額嚴重偏高領(lǐng)導(dǎo)看著數(shù)據(jù)以為今年任務(wù)穩(wěn)了實際到了月底發(fā)現(xiàn)差了十萬八千里。后來我們按照過去一年的真實轉(zhuǎn)化數(shù)據(jù)回算把初步溝通的贏單概率壓到了5%方案報價壓到了35%預(yù)測才慢慢接近實際。權(quán)限模型是另一個容易扯皮的地方。DeskcommCRM的權(quán)限體系支持按角色數(shù)據(jù)范圍的組合控制比如普通銷售只能看到自己名下的客戶銷售主管可以看到本部門下屬的所有客戶總經(jīng)理和高層可以看全公司數(shù)據(jù)。我們一開始把數(shù)據(jù)權(quán)限放得比較開結(jié)果有銷售發(fā)現(xiàn)同事的客戶信息可以直接瀏覽內(nèi)部鬧了不小的矛盾。后來重新梳理權(quán)限矩陣客戶和聯(lián)系人的查看權(quán)限嚴格按歸屬共享規(guī)則來共享規(guī)則統(tǒng)一走客戶團隊的邏輯只有被加入團隊的人才能訪問商機和合同的信息則跟隨客戶權(quán)限自動繼承。這個模式從落地到現(xiàn)在一直沒出過問題也強烈建議你們按數(shù)據(jù)跟隨對象權(quán)限控制到組的方式來設(shè)計不要搞人均全量可見的粗放授權(quán)。審批流設(shè)置相對簡單但要注意流程分支的條件順序。我們的審批場景主要是合同折扣審批低于標準折扣價自動通過超過標準折扣但小于5%走銷售總監(jiān)審批超過5%走總經(jīng)理審批。DeskcommCRM里這類條件分支可以在可視化編輯器中配置注意把判斷順序排好先判斷是否超5%再判斷是否超標準但不超5%順序反了就會走到錯誤的分支。上線后建議拿幾個典型單據(jù)做測試再投入使用。4. 與現(xiàn)有系統(tǒng)的集成打通接口、同步與失敗兜底4.1 對接類和同步類接口的分工CRM單獨跑得再好也得跟公司現(xiàn)有的其他系統(tǒng)打交道否則就會形成新的數(shù)據(jù)孤島。我們當時的集成需求主要集中在三個方向跟企業(yè)微信的審批消息打通、跟財務(wù)系統(tǒng)的訂單回寫、跟客服系統(tǒng)的客戶支持記錄同步。DeskcommCRM提供了比較完整的REST API接口風(fēng)格很常規(guī)Token鑒權(quán)支持標準的增刪改查。我們實際用下來發(fā)現(xiàn)它的API設(shè)計有一個好處接口返回的字段名和系統(tǒng)內(nèi)部字段名基本一致聯(lián)調(diào)的時候不需要來回翻文檔做映射表。不過有一點要提醒部分寫操作接口是沒有做冪等控制的也就是說如果網(wǎng)絡(luò)超時導(dǎo)致請求被重發(fā)可能會創(chuàng)建出重復(fù)的數(shù)據(jù)。這個問題在做集成方案時必須考慮到要么在應(yīng)用層加請求唯一ID去重邏輯要么在寫入前先查一遍是否已存在同樣的記錄。集成這塊我特別想強調(diào)推送和拉取兩種模式的選擇。我的經(jīng)驗是對實時性要求高、數(shù)據(jù)量小的場景用推送比如企微審批結(jié)果回調(diào)CRM對數(shù)據(jù)量大、時效性要求不那么高的場景用拉取比如財務(wù)回款記錄每小時同步一次。不要一上來就想搞實時雙寫系統(tǒng)間的強耦合往往意味著一起崩、一起慢維護成本很高。4.2 同步失敗兜底輪詢、重試和補償系統(tǒng)集成這東西跑通了不算本事穩(wěn)定運行不丟數(shù)據(jù)才算本事。我們在聯(lián)調(diào)階段就遇到過好幾次網(wǎng)絡(luò)閃斷導(dǎo)致同步失敗的情況如果當時沒有兜底方案那數(shù)據(jù)就會悄悄丟在某個角落里直到月底對賬才被發(fā)現(xiàn)。我們的兜底方案做了三層。第一層是接口超時重試對每一次API調(diào)用超時時間設(shè)為15秒失敗后按1分鐘、5分鐘、15分鐘三個間隔重試三次并記錄重試日志。第二層是本地消息表所有需要同步到CRM的數(shù)據(jù)先寫入本地待同步表狀態(tài)標記為pending后臺任務(wù)掃描表中數(shù)據(jù)不斷推進成功后更新為done重試超過5次標記為failed并告警人工處理。第三層是定時對賬任務(wù)每天早上核對一遍本地系統(tǒng)和CRM系統(tǒng)里當天的訂單金額總數(shù)、客戶數(shù)量有任何偏差就自動輸出差異明細。這套機制雖然不是純實時但保證了兩邊數(shù)據(jù)最終一致。注意不管用什么CRM跟外部系統(tǒng)的數(shù)據(jù)同步永遠不要只依賴一次接口調(diào)用成功。先落庫、再異步同步是標準做法。順序反了一旦網(wǎng)絡(luò)抖動或者接口變更丟數(shù)據(jù)的責(zé)任最后還是落在自己頭上。5. 運行維護與一次影響較大的故障復(fù)盤5.1 定時任務(wù)假死的排查過程系統(tǒng)上線穩(wěn)定運行了大半年之后我們遇到過一次影響較大的故障復(fù)盤過程我覺得非常值得寫出來分享。某天上午業(yè)務(wù)同事反饋說客戶的分配沒生效主管在后臺上傳了一批新線索也跑完了自動分配操作但線索一直停留在待分配狀態(tài)沒有掛到任何銷售名下。整個上午都沒有報錯信息界面上看著一切正常但數(shù)據(jù)就是不動。我們當時的第一反應(yīng)是查看后臺定時任務(wù)的執(zhí)行記錄。DeskcommCRM的定時任務(wù)模塊里能看到每一次運行的開始時間、結(jié)束時間和狀態(tài)結(jié)果發(fā)現(xiàn)自動分配的定時任務(wù)一直顯示運行中從凌晨一直卡到了上午。這就是典型的定時任務(wù)假死進程沒有崩潰但事務(wù)卡死既不結(jié)束也不報錯。接下來我們查應(yīng)用日志發(fā)現(xiàn)最早一條卡住的運行記錄是在凌晨4點當時正好有一個大批量的歷史數(shù)據(jù)清洗任務(wù)在跑鎖住了大量數(shù)據(jù)行。自動分配任務(wù)在嘗試讀取客戶數(shù)據(jù)時等不到鎖JDBC的鎖等待超時時間又被設(shè)置得很長于是一直阻塞在這里后面排隊的調(diào)度全部被堵住了。根因其實很常見兩個任務(wù)并發(fā)執(zhí)行數(shù)據(jù)庫行鎖沖突加上超時配置不合理導(dǎo)致整個任務(wù)鏈被拖死。這個故障本身的修復(fù)動作很簡單把卡住的任務(wù)殺掉、調(diào)整超時參數(shù)、重新執(zhí)行分配就好了。但它暴露出來的問題是我們對后臺任務(wù)缺乏有效的監(jiān)控機制等到業(yè)務(wù)人員發(fā)現(xiàn)異常才開始排查中間白白耽誤了好幾個小時。5.2 這類故障的根因和預(yù)防清單我們是后來一步一步把任務(wù)并發(fā)這塊補完善的。具體做了四件事你也可以直接把這份清單拿過去對照檢查自己的系統(tǒng)給所有定時任務(wù)加上超時熔斷機制。任何任務(wù)運行超過預(yù)設(shè)時限比如30分鐘就強制結(jié)束并標記為超時告警不允許無限期運行。雖然每個任務(wù)的合理時間不一樣但不能無限跑這條鐵律是通用的。錯峰調(diào)度。把重型的定時任務(wù)數(shù)據(jù)對賬、數(shù)據(jù)導(dǎo)出、批量導(dǎo)入安排在凌晨業(yè)務(wù)低峰期同一個時間段內(nèi)最多只允許一個重型任務(wù)在運行交叉執(zhí)行避免鎖競爭。關(guān)鍵任務(wù)失敗后的主動告警。這不是指任務(wù)拋異常時發(fā)告警而是指該跑的任務(wù)沒有跑、或者沒跑完也要發(fā)告警。我們加了一個心跳機制每個定時任務(wù)跑完都會更新一張監(jiān)控表外部隊列檢查監(jiān)控表里任務(wù)的最后運行時間超過N分鐘沒有更新就打電話告警。建立每次任務(wù)執(zhí)行情況的存檔視圖。DeskcommCRM的后臺有心跳記錄但我們自建了獨立的日志匯總把成功、失敗、超時的歷史記錄揉在一起再做一張趨勢報表對發(fā)現(xiàn)隱性異常很有用。那次故障之后還引申出另一個經(jīng)驗上線前一定要給所有集成任務(wù)和定時任務(wù)做一次斷網(wǎng)演練和死鎖演練。不要覺得這是制造麻煩實際上真正到了故障來臨的時候一套成熟的告警和恢復(fù)路徑能讓你在十分鐘內(nèi)定位問題而不是翻日志翻到崩潰。結(jié)尾的一點個人體會這篇文章斷斷續(xù)續(xù)寫了不少核心的選型、實施、集成、運維四個階段也都覆蓋到了。如果你正走在CRM落地的路上我最后想分享三點切身體會。第一CRM不是一個裝完就結(jié)束的項目它是需要持續(xù)運營、持續(xù)配置、持續(xù)跟業(yè)務(wù)節(jié)奏磨合的活系統(tǒng)。團隊的管理動作變了、考核方式變了、銷售流程優(yōu)化了系統(tǒng)就要跟著調(diào)。很多上線即失敗的項目問題并不在軟件本身而是沒有人持續(xù)去維護它、推動大家使用它、把系統(tǒng)數(shù)據(jù)當作日常工作的一部分。第二千萬不要低估數(shù)據(jù)質(zhì)量的重要性。系統(tǒng)可以換、流程可以調(diào)但臟數(shù)據(jù)一旦沉淀下來清理成本是成倍數(shù)增長的。從一開始就堅持必填校驗、去重規(guī)則和定期的數(shù)據(jù)審計后面會省下無數(shù)精力。第三一定要有一位內(nèi)部產(chǎn)品經(jīng)理式的角色能夠把業(yè)務(wù)需求翻譯成系統(tǒng)配置和開發(fā)方案并且跟蹤落地。這個角色不一定非要是產(chǎn)品經(jīng)理出身但一定要懂業(yè)務(wù)、能溝通、愿意深入到系統(tǒng)細節(jié)里。沒有這個人CRM項目大概率會變成一個昂貴的擺設(shè)。DeskcommCRM在我們的環(huán)境里已經(jīng)穩(wěn)定運行了很久整體下來我對它的評價是在通用型可私有化部署的CRM這個區(qū)間里它確實是把業(yè)務(wù)覆蓋度和靈活性平衡得比較到位的一個產(chǎn)品。但再好的工具也需要正確的使用方法希望這篇文章的經(jīng)歷和踩坑能幫你在自己的項目里避掉幾條彎路。