前陣子我一直在折騰一個叫DeskcommCRM的項目它是面向桌面辦公和內(nèi)外溝通場景的輕量級客戶關(guān)系管理系統(tǒng)。簡單說就是把你平時跟客戶打交道的聊天記錄、郵件往來、跟進(jìn)提醒、待辦任務(wù)全部收攏到一個地方跟客戶檔案串成一條線再自動生成幾張能看的統(tǒng)計報表。它適合銷售、客服、自由職業(yè)者也適合那種“客戶信息還躺在微信聊天記錄里”的小團隊。這篇文章我會完整記錄我從設(shè)計思路、模塊拆分、部署配置到上線運行踩坑的全過程盡量把能抄作業(yè)的步驟都擺出來方便想搭一套自用或團隊內(nèi)部 CRM 的朋友參考。1. 項目定位與整體設(shè)計DeskcommCRM 到底要解決什么問題1.1 從“客戶信息散落在聊天記錄里”談起先說一個我觀察到的普遍現(xiàn)象。很多小團隊不是沒有客戶管理意識而是壓根沒時間把客戶信息錄入一套正經(jīng)的 CRM 系統(tǒng)。業(yè)務(wù)員加了客戶微信談過什么全在聊天記錄里客戶打過電話說了什么可能只存在于記憶里報價單發(fā)了幾版、最后定了哪個價Excel 表里可能都沒有。等客戶突然來問“上次那個方案怎么樣了”你得翻半天聊天記錄還不一定翻得到。DeskcommCRM 想解決的就是這個問題。它不像大廠那種重營銷自動化、帶一堆復(fù)雜權(quán)限和流程引擎的 CRM而是把重點放在“溝通即記錄”上。每當(dāng)一條消息進(jìn)來、一個任務(wù)到期、一個報價單被確認(rèn)系統(tǒng)都會自動把信息掛到對應(yīng)客戶的名下。這樣即使業(yè)務(wù)員休假別人接手時也能快速看懂客戶聊到哪一步了。我在設(shè)計初期給這個項目定了三個原則數(shù)據(jù)先沉淀、記錄要自動、查詢要夠快。數(shù)據(jù)先沉淀指的是客戶資料和溝通記錄必須統(tǒng)一落庫記錄要自動是說能通過接口或?qū)肽玫降南⒉灰屓耸止ぬ畈樵円獕蚩焓钦f客戶檔案打開后所有歷史往來應(yīng)該幾秒內(nèi)就能拉出來而不是等報表跑半天。1.2 整體架構(gòu)與核心模塊劃分DeskcommCRM 的整體架構(gòu)并不復(fù)雜我把它分成四個部分桌面客戶端、管理后臺、后端服務(wù)、數(shù)據(jù)存儲。桌面客戶端提供快捷的客戶查詢和消息速記能力管理后臺負(fù)責(zé)完整的數(shù)據(jù)管理和報表查看后端服務(wù)統(tǒng)一暴露 API數(shù)據(jù)存儲使用 PostgreSQL 加 Redis。這四個部分選型時都有各自的理由。桌面端我沒有選擇純網(wǎng)頁方案而是用了能直接跑在 Windows 和 macOS 上的桌面殼這樣業(yè)務(wù)員可以像開微信一樣隨手打開不用每次先登錄瀏覽器也不容易開一堆標(biāo)簽頁導(dǎo)致客戶信息被淹沒。管理后臺做成網(wǎng)頁是考慮到老板看報表和配置字段時用瀏覽器更舒服。后端服務(wù)的選型上我用了 Node.js 的 NestJS原因是它模塊化程度高開發(fā)效率快而且團隊內(nèi)部更熟悉 JavaScript 技術(shù)棧。數(shù)據(jù)庫選了 PostgreSQL主要是看中它的 JSON 字段能力方便存儲靈活擴展的客戶屬性。核心模塊劃分成五塊聯(lián)系人管理、溝通記錄、任務(wù)跟進(jìn)、工單反饋、數(shù)據(jù)看板。聯(lián)系人管理管的是客戶檔案包括個人、企業(yè)、標(biāo)簽和自定義字段溝通記錄是對接郵件、企業(yè)微信、聊天記錄導(dǎo)入和電話備注的統(tǒng)一時間線任務(wù)跟進(jìn)負(fù)責(zé)創(chuàng)建待辦、設(shè)置提醒、追蹤跟進(jìn)周期工單反饋適合售后和客服場景記錄客戶報障、處理進(jìn)度和滿意度數(shù)據(jù)看板則把新增客戶數(shù)、跟進(jìn)次數(shù)、成交轉(zhuǎn)化率這類指標(biāo)統(tǒng)計出來。這套模塊劃分的底層邏輯是“客戶生命周期”。從線索進(jìn)來到跟進(jìn)中到成交再到售后每個階段都有對應(yīng)的模塊承載數(shù)據(jù)。線索進(jìn)來的那一刻聯(lián)系人模塊先建檔被銷售聯(lián)系溝通時溝通記錄模塊在工作銷售承諾了回訪時間任務(wù)跟進(jìn)模塊會提醒客戶出了產(chǎn)品問題工單模塊會記錄處理過程最終管理層要看整體經(jīng)營情況數(shù)據(jù)看板給結(jié)論。1.3 針對典型用戶的取舍做這類系統(tǒng)最大的坑是想一口氣滿足所有人。我一開始也列了一堆需求包括營銷郵件批量發(fā)送、客戶公海分配、銷售業(yè)績排名等等。但實際調(diào)研了一圈身邊需要 CRM 的團隊發(fā)現(xiàn)最有痛點的反而是那些最簡單的場景。于是我把功能目標(biāo)收斂成了“四個人都能用起來”銷售能快速記客戶客服能看清歷史負(fù)責(zé)人能安排任務(wù)管理層能看到數(shù)據(jù)。這個收斂過程做了不少取舍。比如營銷自動化我最終只保留了簡單的分組群發(fā)郵件功能而且必須手動觸發(fā)不會自動給所有客戶發(fā)促銷。原因是小團隊使用自動營銷的頻次很低卻對系統(tǒng)穩(wěn)定性和反垃圾要求很高投入產(chǎn)出比不劃算。又比如公海分配我最初設(shè)計了一大套規(guī)則后來砍成了一個簡單的狀態(tài)字段空閑中、跟進(jìn)中、已成交。有需要時團隊負(fù)責(zé)人手動重新指派即可沒必要一上來就做復(fù)雜的規(guī)則引擎。這些取舍讓我意識到輕量系統(tǒng)的核心價值不是“功能多”而是“維護成本低”。小團隊未必有專職的 IT 管理員系統(tǒng)太復(fù)雜出了故障沒人會修自然就被棄用了。所以我在設(shè)計每個功能前都會問一句這個功能如果讓一個不懂?dāng)?shù)據(jù)庫的人用他會不會用不會用就簡化。2. 核心技術(shù)點與功能模塊拆解2.1 聯(lián)系人檔案與完整體檢聯(lián)系人模塊不是簡單的一張表而是一套多層級的檔案結(jié)構(gòu)?？蛻艨梢允莻€人也可以掛在企業(yè)下面還可以有多個聯(lián)系人和多個標(biāo)簽。我在數(shù)據(jù)庫里設(shè)計了企業(yè)表、聯(lián)系人表、聯(lián)系人標(biāo)簽表這三個主要實體。企業(yè)表存儲公司名稱、行業(yè)、規(guī)模、地址聯(lián)系人表存儲姓名、電話、郵箱、職務(wù)、所屬企業(yè)標(biāo)簽表負(fù)責(zé)打標(biāo)比如“高意向”“已簽約”“需要續(xù)費”。這套模型的初期設(shè)計踩了一個坑就是標(biāo)簽到底存成單獨表還是直接用一個字符串字段。字符串字段確實簡單但要統(tǒng)計“所有高意向客戶”時必須用模糊查詢數(shù)據(jù)量大了性能會下降。單獨的標(biāo)簽表需要多維護一張關(guān)聯(lián)表但查詢時可以走索引速度穩(wěn)定。最終我選了單獨標(biāo)簽表并且限制一個聯(lián)系人最多打 20 個標(biāo)簽防止濫用導(dǎo)致查詢膨脹。在搜索體驗上我做了全局搜輸入關(guān)鍵詞能同時匹配聯(lián)系人姓名、電話、郵箱、企業(yè)名和備注內(nèi)容。這個功能的實現(xiàn)關(guān)鍵是在 PostgreSQL 里建了帶pg_trgm擴展的 GIN 索引。pg_trgm可以支持模糊匹配的加速數(shù)據(jù)量到幾萬條聯(lián)系人時搜索響應(yīng)依然能穩(wěn)定在 300 毫秒內(nèi)。第一次配置時我沒啟用這個擴展結(jié)果搜一個名字要全表掃描客戶多了以后明顯卡頓后來才加上。字段設(shè)計上我保留了八個默認(rèn)字段加若干自定義字段。自定義字段支持文本、日期、下拉選項三種類型足夠覆蓋大多數(shù)場景。不建議一上來就添加大量自定義字段因為每個自定義字段都要考慮檢索、展示、導(dǎo)入導(dǎo)出映射維護成本是線性增加的。我最后只在一個客戶檔案里用了兩個自定義字段客戶來源渠道和預(yù)計成交日期其他信息全部放進(jìn)備注里反正支持全文檢索。2.2 溝通記錄與消息集成溝通記錄模塊是本系統(tǒng)最重要的數(shù)據(jù)來源它解決的是“客戶到底跟你聊了什么”。我設(shè)計了一個統(tǒng)一時間線的數(shù)據(jù)模型把郵件、聊天記錄、電話備注、見面紀(jì)要全部以消息記錄的形式掛到聯(lián)系人時間線上。每條記錄包含發(fā)送方、接收方、正文、附件鏈接、發(fā)生時間、關(guān)聯(lián)的待辦任務(wù)。從接入方式看郵件是最容易打通的。我用 IMAP 協(xié)議監(jiān)聽指定郵箱賬號的收件箱通過郵件頭里的 Message-ID 做去重再按發(fā)件人郵箱地址匹配到系統(tǒng)內(nèi)的聯(lián)系人。如果發(fā)件人的郵箱不在聯(lián)系人庫里我會先自動創(chuàng)建一條“待確認(rèn)”狀態(tài)的臨時聯(lián)系人等有人確認(rèn)后再正式建檔。這一步很實用可以減少錄入成本也避免一堆垃圾郵件自動污染聯(lián)系人庫。聊天記錄的接入比郵件復(fù)雜一些。我實際使用的是企業(yè)微信的會話存檔接口和聊天記錄導(dǎo)出文件這兩種方式。會話存檔接口要額外購買企業(yè)的會話存檔服務(wù)不過拿到的數(shù)據(jù)很完整消息類型、發(fā)送人、接收人、時間戳都有。如果是外部聊天工具比如個人微信我不建議做任何自動抓取合規(guī)風(fēng)險太大最穩(wěn)妥的是支持 CSV 或 HTML 導(dǎo)出后手動導(dǎo)入。自動導(dǎo)入的痛點主要是數(shù)據(jù)格式不統(tǒng)一我在導(dǎo)入模塊里寫了一個字段映射界面讓用戶把源文件里的列名拖拽對應(yīng)到系統(tǒng)字段。比如源文件里有“客戶姓名”“客戶手機號”“最近聊天內(nèi)容”就手動映射到聯(lián)系人姓名、手機號、最近一條消息。這樣導(dǎo)入模塊可以兼容任何來源的數(shù)據(jù)不需要為每種格式單獨寫代碼。為了信息安全和合規(guī)我還在消息正文的展示層做了一個脫敏選項。對于身份證號、銀行卡號這類敏感信息系統(tǒng)默認(rèn)用*號遮蔽只有擁有管理員權(quán)限的人點擊后才能查看原文。這個功能雖然實現(xiàn)起來不難但對面向外部客戶展示的場合很關(guān)鍵防止銷售在投屏演示時把客戶隱私一并暴露出去。2.3 跟進(jìn)任務(wù)與提醒機制任務(wù)跟進(jìn)模塊的設(shè)計目標(biāo)很單純不讓任何一條承諾落空。業(yè)務(wù)員對客戶承諾“明天給您回電話”“下周給方案”這些承諾都該變成任務(wù)。我在這套系統(tǒng)里把任務(wù)分成兩類普通待辦和跟進(jìn)任務(wù)。普通待辦是自己安排的活兒比如“整理產(chǎn)品資料”跟進(jìn)任務(wù)則必須關(guān)聯(lián)到聯(lián)系人上并且有明確的截止時間和提醒方式。任務(wù)創(chuàng)建時的關(guān)鍵字段不多執(zhí)行人、關(guān)聯(lián)聯(lián)系人、任務(wù)標(biāo)題、詳細(xì)描述、截止時間、提醒時間。提醒時間支持提前 5 分鐘、30 分鐘、1 小時、1 天多個檔位也可以自定義。這里最重要的是任務(wù)狀態(tài)機待處理、處理中、已完成、已逾期、已取消。狀態(tài)不能隨意跳轉(zhuǎn)處理中的任務(wù)不能直接標(biāo)記為已完成必須先有處理結(jié)果備注否則系統(tǒng)會攔截并提示“請先填寫跟進(jìn)記錄”。提醒機制的實現(xiàn)我一開始用了個非常樸素的方案每五分鐘掃描一次數(shù)據(jù)庫里所有截止時間在三分鐘內(nèi)的任務(wù)然后發(fā)站內(nèi)信和郵件。這個方案在小數(shù)據(jù)量下沒有問題但任務(wù)量到了幾萬條時每五分鐘一次全表掃描還是有點浪費。后來我改成了 Redis 延遲隊列任務(wù)創(chuàng)建時把提醒時間戳推入 ZSet由單獨的 worker 定時拉取到期的任務(wù) ID再執(zhí)行通知發(fā)送。這樣掃描的壓力被分散到消息隊列數(shù)據(jù)庫幾乎不會因為這個邏輯產(chǎn)生慢查詢。提醒渠道上站內(nèi)信是基本盤郵件和企業(yè)微信機器人作為擴展。站內(nèi)信的優(yōu)勢是快打開客戶端就能看到數(shù)字角標(biāo)郵件適合正式場合比如給管理員發(fā)送日報企業(yè)微信群機器人適合團隊協(xié)作場景任務(wù)分配后群里立刻有人認(rèn)領(lǐng)減少互相催促。配置企業(yè)微信機器人只需要一個 Webhook 地址每條消息以 JSON 格式 POST 過去即可5 分鐘就能接通。還有一類任務(wù)要特別小心就是周期性跟進(jìn)任務(wù)?？蛻羰情L期經(jīng)營的單純的單次待辦會讓銷售人員忘記定期回訪。我加了“任務(wù)模板”功能管理員可以配置一個任務(wù)模板比如“每兩周回訪一次已成交客戶”系統(tǒng)在每次任務(wù)完成后自動創(chuàng)建下一次任務(wù)。這個邏輯不復(fù)雜麻煩的是避免重復(fù)創(chuàng)建我在模板表里加了last_triggered_at字段保證同一模板同一時間只會生成一個任務(wù)。2.4 可視化數(shù)據(jù)看板一個 CRM 如果只有信息記錄而沒有統(tǒng)計那它就是通信錄或記事本。數(shù)據(jù)看板是我花了不少心思做的板塊但我也很清楚小團隊不需要太多花哨的圖表核心看三塊客戶增長情況、跟進(jìn)執(zhí)行情況、成交轉(zhuǎn)化情況?？蛻粼鲩L情況對應(yīng)的圖表很簡單就是按天/按周統(tǒng)計新增客戶數(shù)同時附上累計客戶數(shù)。為了支持這個圖表我不需要在查詢時實時寫復(fù)雜的 group by只需要在聯(lián)系人表里維護created_at字段然后做日期維度聚合即可。數(shù)據(jù)量不大時直接 SQL 聚合完全夠用。但要注意時區(qū)問題我在統(tǒng)計時強制按應(yīng)用配置的時區(qū)做to_timestamp和date_trunc否則北京時間和 UTC 時間會差 8 小時每天統(tǒng)計數(shù)看起來都會偏一天。跟進(jìn)執(zhí)行情況看的是任務(wù)完成率。這里我關(guān)心兩個指標(biāo)完成率和逾期率。完成率等于已完成任務(wù)數(shù)除以已分配任務(wù)數(shù)逾期率等于逾期未完成任務(wù)數(shù)除以應(yīng)完成任務(wù)數(shù)。指標(biāo)計算本身不復(fù)雜難點在于定義“逾期”我使用的規(guī)則是截止時間超過當(dāng)前時間且狀態(tài)不是已完成或已取消才算逾期。如果一個任務(wù)被推遲過系統(tǒng)記錄due_at的最新時間取最新時間判斷。否則會出現(xiàn)“改了個截止日期統(tǒng)計時還算逾期”的尷尬。成交轉(zhuǎn)化率我按照銷售漏斗來做從“線索”到“初步溝通”到“方案報價”到“成交”四層。每個聯(lián)系人擁有一個階段字段統(tǒng)計時數(shù)出當(dāng)前處于各階段的人數(shù)。漏斗圖的實現(xiàn)用餅圖其實就行不需要復(fù)雜模型。真正要注意的是階段流轉(zhuǎn)歷史如果只是修改當(dāng)前階段字段以后想復(fù)盤“這個客戶在報價階段停留了多久”就會無從下手。所以我增加了一張階段變更歷史表每次階段變化都記錄原階段、新階段、操作人、操作時間這樣漏斗圖就不只能看當(dāng)前分布還能分析轉(zhuǎn)化速度和停滯時長。為了保證看板加載不卡我沒有讓前端實時去查統(tǒng)計接口而是先在后端做了聚合查詢接口再在前端用 ECharts 渲染。當(dāng)前數(shù)據(jù)量小聚合查詢都能在 1 秒內(nèi)完成。當(dāng)數(shù)據(jù)量翻了幾倍以后我打算用一個簡單的定時任務(wù)把每天的關(guān)鍵指標(biāo)寫入一張匯總表前端直接讀匯總表實現(xiàn)毫秒級打開。3. 實操部署與配置全程記錄3.1 環(huán)境準(zhǔn)備與依賴清單先交代一下我實際使用的部署環(huán)境方便你對照。服務(wù)器是一臺 4 核 8G 內(nèi)存的普通 Linux 云主機操作系統(tǒng)是 Ubuntu 22.04 LTS。這套配置跑 PostgreSQL、Redis、Node.js 服務(wù)端和一個 Nginx 反向代理日常使用非常寬裕。如果用 Docker Compose 部署內(nèi)存最低建議 4G否則 PostgreSQL 和 Node.js 同時啟動時可能內(nèi)存告急。依賴組件清單如下PostgreSQL 16主數(shù)據(jù)庫Redis 7緩存和延遲隊列Node.js 20后端服務(wù)Nginx 1.24反向代理和靜態(tài)文件服務(wù)可選SMTP 郵件服務(wù)用于郵件提醒和郵件接入我推薦用 Docker Compose 統(tǒng)一管理這些組件因為可以一條命令拉起整套環(huán)境也方便備份和遷移。服務(wù)器上先安裝 Docker 和 Docker Compose 插件然后準(zhǔn)備項目目錄結(jié)構(gòu)。我的目錄結(jié)構(gòu)是這樣的/opt/deskcomm ├── docker-compose.yml ├── .env ├── nginx │ └── conf.d │ └── deskcomm.conf ├── backend │ ├── dist │ └── package.json └── frontend └── htmldocker-compose.yml里定義了四個服務(wù)db、redis、backend、nginx。數(shù)據(jù)庫和 Redis 使用官方鏡像數(shù)據(jù)目錄掛載到宿主機上的./data/pg和./data/redis。后端服務(wù)使用自己構(gòu)建的鏡像Dockerfile基于node:20-slim把編譯好的dist目錄拷進(jìn)去后用node dist/main.js啟動。前端構(gòu)建完把靜態(tài)文件復(fù)制到./frontend/html交給 Nginx 服務(wù)。3.2 初始化數(shù)據(jù)庫與配置項環(huán)境變量配置是啟動前最關(guān)鍵的一步。我習(xí)慣將所有敏感配置放進(jìn).env文件中并在docker-compose.yml里通過env_file引用避免把密碼和密鑰寫死在代碼里。核心的配置項有這幾類數(shù)據(jù)庫相關(guān)POSTGRES_HOSTdb POSTGRES_PORT5432 POSTGRES_PASSWORDyour_strong_password POSTGRES_DBdeskcomm后臺應(yīng)用相關(guān)JWT_SECRETplease_change_to_a_random_long_string APP_TIMEZONEAsia/Shanghai DEFAULT_ADMIN_EMAILadminexample.com DEFAULT_ADMIN_PASSWORDchange_me郵件和提醒相關(guān)MAIL_HOSTsmtp.example.com MAIL_PORT465 MAIL_USERno-replyexample.com MAIL_PASSWORDsmtp_password WEBHOOK_QIYEWEIXINhttps://qyapi.weixin.qq.com/cgi-bin/webhook/send?keyyour_key數(shù)據(jù)庫初始化我用了遷移腳本的方式?jīng)]有直接用 ORM 的自動建表。這是因為自動建表雖然方便但后續(xù)加字段、改索引時很難維護版本變更。我在backend/migrations目錄下放了一系列按時間戳命名的 SQL 文件啟動時由遷移工具依次執(zhí)行執(zhí)行過的文件會被記錄到migration_log表里。這樣無論從哪個版本升級到新版本只需要把新遷移腳本放進(jìn)目錄里重啟服務(wù)即可完成升級。管理員賬號我建議用初始化腳本創(chuàng)建而不是寫死在數(shù)據(jù)庫遷移里。因為密碼明文寫在 SQL 文件里很不安全也很容易被提交到 Git 倉庫。初始化腳本會在服務(wù)啟動后檢查是否已有管理員賬號如果沒有就從環(huán)境變量讀取初始密碼經(jīng)過 bcrypt 哈希后寫入數(shù)據(jù)庫。首次啟動后應(yīng)該立刻登錄后臺修改密碼。3.3 啟動服務(wù)與驗證可用性配置完成后的啟動命令很簡單cd /opt/deskcomm docker compose up -d第一次啟動會自動拉取鏡像并構(gòu)建后端容器耗時取決于網(wǎng)絡(luò)和機器性能一般在五到十五分鐘之間。啟動后我用下面幾步驗證環(huán)境是否正常第一步檢查所有容器狀態(tài)docker compose ps所有服務(wù)的狀態(tài)應(yīng)該是Up如果backend容器反復(fù)重啟多半是環(huán)境變量配置錯誤查看日志定位即可docker compose logs backend第二步檢查健康檢查接口。后端服務(wù)里我加了一個簡單的/health接口會同時檢查數(shù)據(jù)庫連接和 Redis 連接返回{ status: ok }。如果這個接口返回 200說明應(yīng)用依賴的環(huán)境基本正常。第三步訪問前端頁面并登錄。Nginx 把根路徑/代理到前端靜態(tài)文件把/api前綴代理到后端服務(wù)。所以用戶在瀏覽器里只需要打開http://服務(wù)器IP就能進(jìn)入登錄頁。注意我第一次部署時忘記配置 Nginx 對 WebSocket 的支持導(dǎo)致桌面端的消息提醒推送一直是灰色的后來加了Upgrade和Connection請求頭轉(zhuǎn)發(fā)才解決。驗證完成后我還習(xí)慣做一輪樣例數(shù)據(jù)測試。建一個測試企業(yè)、一個測試聯(lián)系人、一條溝通記錄和一個任務(wù)確認(rèn)每個功能模塊都能正常寫入和查詢。如果所有操作都正常再開啟 SMTP 配置和 Webhook 配置把真實通知鏈路跑通。這個步驟別跳過因為很多問題只有在真實連接外部服務(wù)時才會暴露。4. 上線運行后的常見問題與排查記錄4.1 問題速查表系統(tǒng)上線這幾周我遇到過的、以及社區(qū)朋友問過的問題基本都集中在下面這張表里問題可能原因解決辦法登錄后一直提示“賬號或密碼錯誤”管理員初始密碼未修改或 JWT 密鑰變更導(dǎo)致舊 token 失效執(zhí)行初始化腳本重置密碼重新生成 JWT 密鑰并重啟郵件接入后收不到客戶郵件IMAP 賬號密碼錯誤或郵件服務(wù)器限制了第三方客戶端檢查郵箱設(shè)置開啟“應(yīng)用專用密碼”任務(wù)提醒遲遲不來時區(qū)配置錯誤或 Redis 隊列 worker 未運行檢查APP_TIMEZONE重啟 worker 并查看隊列積壓數(shù)量正則導(dǎo)入 CSV 后中文亂碼CSV 文件編碼不是 UTF-8用記事本另存為 UTF-8 或轉(zhuǎn)換編碼后重試看板統(tǒng)計數(shù)字對不上時區(qū)偏差或任務(wù)狀態(tài)歷史更新方式不對統(tǒng)一按應(yīng)用時區(qū)聚合確認(rèn)狀態(tài)變更寫入了歷史表客戶端連不上服務(wù)器Nginx 未配置 WebSocket 轉(zhuǎn)發(fā)在 Nginx 配置中增加 WebSocket 支持這張表我保存到了項目 Wiki 里每次有新人接手部署時先讓他們看一遍能省掉很多基礎(chǔ)咨詢。4.2 幾個值得注意的深坑第一個深坑是消息 Webhook 重復(fù)回調(diào)。企業(yè)微信的 Webhook 在極端情況下會重復(fù)推送同一條消息如果沒有冪等處理數(shù)據(jù)庫里會出現(xiàn)兩條一模一樣的溝通記錄。我處理的方式是在消息表上建立一個唯一索引(source_type, external_message_id)以后每條消息寫入時如果重復(fù)則執(zhí)行更新而不是新增。這個索引建好后重復(fù)回調(diào)的問題從根源上隔絕了。第二個深坑是數(shù)據(jù)庫連接池耗盡。剛開始我用的是默認(rèn)連接池大小后端服務(wù)同時處理大量請求時會報too many connections。排查下來發(fā)現(xiàn)并不是數(shù)據(jù)庫配置不夠而是有些接口在事務(wù)里做了長時間查詢一直占著連接不釋放。后來我調(diào)整了連接池上限到 20并給所有 API 加了超時時間超時的請求及時中斷。針對慢查詢給created_at、contact_id、remind_at這些頻繁查詢的字段都加了索引問題才徹底緩解。第三個深坑是忘記設(shè)置 Docker 容器的時區(qū)。容器里的默認(rèn)時區(qū)是 UTC而業(yè)務(wù)方在中國所有時間提醒都比真實時間晚了 8 小時。任務(wù)定在下午三點提醒實際到晚上十一點才推。這個坑很隱蔽因為從應(yīng)用日志看時間都是連續(xù)的很難一眼發(fā)現(xiàn)問題。解決方案是在docker-compose.yml里給容器設(shè)置環(huán)境變量TZAsia/Shanghai并且應(yīng)用內(nèi)的時間處理全部基于這個時區(qū)。第四個深坑是數(shù)據(jù)庫備份恢復(fù)后外鍵報錯。我一開始的備份腳本只備份了業(yè)務(wù)數(shù)據(jù)表沒有備份序列的自增計數(shù)器?；謴?fù)后新增聯(lián)系人時主鍵沖突是小事麻煩的是有些關(guān)聯(lián)表引用了錯誤的 ID。后來我在備份腳本里使用pg_dump --clean --if-exists并明確指定全庫導(dǎo)出模式恢復(fù)完還要執(zhí)行一次ANALYZE更新統(tǒng)計信息確保數(shù)據(jù)庫執(zhí)行計劃不跑偏。4.3 性能與備份建議再怎么說這也是一個長期運行的系統(tǒng)備份和監(jiān)控一定要做好。我用的備份策略是每天凌晨兩點執(zhí)行一次pg_dump全量備份同時把備份文件保留 14 天每天中午額外執(zhí)行一次增量邏輯把當(dāng)天的溝通記錄和任務(wù)變更記錄同步到一個歸檔表。之所以保留歸檔表是為了以后做數(shù)據(jù)分析時不用去翻巨大的主業(yè)務(wù)表。監(jiān)控方面我沒有引入重型的監(jiān)控系統(tǒng)只寫了一個簡單的腳本每五分鐘檢查三個指標(biāo)后端接口響應(yīng)時間、Redis 隊列積壓數(shù)量、磁盤剩余空間。如果響應(yīng)時間超過兩秒或磁盤剩余空間低于 20%就往企業(yè)微信群里推送告警。這套輕量監(jiān)控已經(jīng)幫我抓到了兩次磁盤寫滿前的問題都是日志文件沒有做輪轉(zhuǎn)導(dǎo)致的。順便一提Nginx 的 access 日志默認(rèn)無限增長我設(shè)置了按天切分并保留七天再配合 crontab 清理磁盤壓力就小了很多。對于數(shù)據(jù)庫性能我建議小團隊先不用考慮分表老老實實把索引建好。當(dāng)前系統(tǒng)里查詢最頻繁的是聯(lián)系人表和時間線記錄表這兩張表數(shù)據(jù)量在兩三萬條時正確建索引后查詢都是毫秒級。真要到了幾十萬條數(shù)據(jù)再考慮按時間分區(qū)或做只讀從庫不過對于大多數(shù)小團隊來說那已經(jīng)是幾年以后的事了。5. 使用經(jīng)驗與下一步騰挪空間5.1 這套系統(tǒng)幫我節(jié)省了什么說說真實的使用感受。原來我自己的客戶信息管理非常粗放微信置頂十幾個聊天窗口Excel 記錄報價和合同郵箱里躺著一堆方案文檔。有用但亂找東西全靠記憶。用 DeskcommCRM 之后變化最明顯的不是“有什么高級功能”而是“找東西變快了”客戶打電話來打開桌面端輸入手機號后四位所有歷史記錄都在那不用臨時翻手機聊天記錄。對團隊來說最有價值的其實是標(biāo)準(zhǔn)的“跟進(jìn)記錄”習(xí)慣。系統(tǒng)不會強迫你寫日報但每次任務(wù)完成時必須填寫處理結(jié)果備注這就養(yǎng)成了隨手記錄的習(xí)慣。月底看數(shù)據(jù)時負(fù)責(zé)人不再憑借印象評價誰辛苦而是能看到每個人跟進(jìn)客戶的數(shù)量和轉(zhuǎn)化率這些數(shù)據(jù)對績效復(fù)盤和資源分配很有幫助。另外我個人比較受益的是 “防止客戶流失”。以前有些客戶談著談著就沒了聲息其實很多時候是銷售太忙忘了回訪。系統(tǒng)里逾期任務(wù)會一直亮紅每天打開客戶端第一眼看到的就是“逾期未跟進(jìn)”的列表那種無形的壓力會自動推著銷售去把承諾推完。幾次體驗下來客戶的續(xù)費率確實比以前好了一些。5.2 想繼續(xù)擴展的方向DeskcommCRM 目前已經(jīng)能穩(wěn)定跑在日常業(yè)務(wù)里但我心里也列了一張擴展清單算是下一階段的規(guī)劃。第一個想補的是移動端適配?，F(xiàn)在桌面端和 Web 端都做得不錯但業(yè)務(wù)員出門拜訪客戶時在手機上快速查一下歷史記錄還是很有價值的。我不打算單獨開發(fā)原生 App優(yōu)先做一套響應(yīng)式的移動頁面保證在手機上能看客戶檔案、記溝通記錄、處理待辦任務(wù)即可。第二個想補的是日歷集成。目前任務(wù)的提醒是按時觸發(fā)的但如果能和 Google Calendar 或 Outlook 日歷打通把跟進(jìn)任務(wù)自動同步到日歷上銷售的時間管理就能更順。技術(shù)上不難主要是 OAuth 對接和雙向同步的業(yè)務(wù)邏輯要仔細(xì)處理。第三個想補的是輕量 BI。雖然現(xiàn)在看板提供了核心指標(biāo)但用戶還想自定義統(tǒng)計維度比如按產(chǎn)品線統(tǒng)計成交額、按地區(qū)分布客戶。我計劃把聚合查詢能力開放出來讓管理員可以選擇維度、指標(biāo)和時間范圍用簡單的拖拽配置生成自定義報表而不需要每次提需求都改代碼。第四個想補的是多租戶模式。目前系統(tǒng)是單團隊部署如果想做成 SaaS 版本對外提供需要把企業(yè)維度加入所有數(shù)據(jù)模型并處理好數(shù)據(jù)隔離和資源配額。這是一個比較大的改造我目前還在設(shè)計方案優(yōu)先級排在比較后面。最后再說一句個人的體會。做這類內(nèi)部工具最重要的不是技術(shù)棧多新、架構(gòu)多復(fù)雜而是能否真正解決使用者的日常問題。DeskcommCRM 我砍了很多計劃中的功能只留最常用的核心鏈路結(jié)果反而使用率很高。如果你也在猶豫要不要自建一套客戶管理系統(tǒng)我建議先從最小的閉環(huán)開始跑通一個季度再逐步豐富你會發(fā)現(xiàn)輕量系統(tǒng)的長期價值遠(yuǎn)超想象。