自己搭一个客户管理系统这事听起来不复杂真正做起来全是坑。前几个月我一直在折腾一个叫 DeskcommCRM 的项目从零开始做桌面端客户关系管理系统踩了不少雷也积累了一些实战经验。这篇文章不打算讲那些虚的直接分享我在这个项目里的整体设计思路、几个核心模块的落地实现、关键问题的排查记录以及一些在文档里根本不会写的心得希望能给想做类似系统的朋友一点参考。DeskcommCRM 定位很明确一个面向销售和客服团队、以客户档案为中心、强调跟进留痕和自动化提醒的桌面端 CRM。它解决的问题很具体——在销售人数不多、但客户量接近几千条的场景下用 Excel 维护客户资料和跟进记录已经撑不住了数据分散、跟进靠记忆、销售离职直接带走客户资源。市面上的 SaaS CRM 要么收费贵要么功能太重内部系统对接又麻烦所以决定自己搭一个轻量但完整的桌面客户端。这套系统适合的读者也很清楚后端想练手完整业务闭环的开发者、团队内需要一套内部 CRM 但预算有限的技术负责人、以及对客户管理流程有自定义需求的产品经理。1. 项目定位与功能边界设计1.1 自研 CRM 的底层动因先说一下为什么不用现成的 SaaS 系统。市面上成熟的 CRM 产品确实很多功能从线索到回款全覆盖但真正用起来有两个问题绕不开一是数据不在自己手里客户资料毕竟属于核心资产放在第三方平台上总有点不踏实二是定制能力有限像销售阶段、跟进频率、工单流转规则这类业务流程每家公司都不一样SaaS 的后台配置虽然灵活但在深度适配内部系统时还是吃力。Deskcomm 这个名字拆开看Desk 强调的是桌面端场景Comm 则代表 Communication合起来就是“在办公桌前高效完成客户沟通与跟进”。所以从一开始就把系统定位成“内部业务系统的操作台”核心使命只有一个让一线销售和客服在处理客户问题时少走弯路。很多人做自研系统容易犯一个错误一开始就想要大而全把线索、客户、商机、合同、回款、售后全部塞进去结果开发周期被拖得很长最后哪个模块都没做透。我这次刻意把边界控制得很严MVP 阶段只做客户管理、跟进记录、工单流转、数据看板四个模块。其他功能像合同管理、回款管理即使要做也至少是后话了不然这个项目根本交付不了。1.2 客户全生命周期的主线逻辑规划功能的时候我先把客户在系统里的完整生命周期画成一条线这也是 DeskcommCRM 的核心业务流程线索录入从市场活动或老客户推荐获取的原始线索先进入线索池此时信息往往不完整只有一个名字和联系方式。客户转化销售确认线索有效后转为正式客户补充公司信息、行业、规模、来源渠道等结构化字段。跟进维护销售围绕客户进行电话、见面、邮件等跟进动作每次跟进记录生成一条时间线数据。工单服务当客户遇到售后问题或技术故障时从客户档案直接发起工单流转到对应负责人处理。数据沉淀整个过程中产生的跟进记录、工单历史、联系方式变更全部自动归档形成客户全息档案。这条主线确定之后功能边界就清晰了后续所有模块都是围绕这条主线做支撑。客户管理管的是“客户是谁”跟进记录管的是“我们在客户身上做了什么”工单管理管的是“客户遇到了什么问题”数据看板则是把上面所有动作的价值量化出来。1.3 自研桌面端方案的几个优势选桌面端而不是纯 Web 端倒不是标新立异主要是实际使用场景决定的。如果你们团队的销售和客服主要在电脑前工作对移动办公没有强需求桌面端的价值就很明显了数据本地缓存能力客户列表、常用字典数据可以本地缓存打开应用秒级响应不带网络也能勉强查看历史数据。更顺手的桌面操作习惯销售录客户时经常需要快速切换窗口查资料桌面客户端比浏览器标签页好用得多。便于对接本地资源比如直接调用本地 Excel 导入、导出读取本地通讯录这种能力和 Web 端做起来不是一个难度级别。天然适合局域网部署内网部署时不用折腾域名、HTTPS 证书打包成 exe 或安装包分发给员工即可。这块想清楚了后面的技术选型就好定多了。2. 技术选型与关键架构设计思路2.1 技术栈选型的逻辑技术选型这事我的原则很简单团队熟什么就用什么如果大家都是零基础那就选学习曲线最平滑、社区生态最完善的组合。DeskcommCRM 最终选用的技术栈如下层级技术选型理由桌面端框架Electron Vue 3生态成熟组件库丰富开发效率高打包跨平台方便UI 组件库Element Plus表格、表单、弹窗等后台管理组件齐全几乎不用自己造轮子桌面端通信Electron IPC 本地 SQLite主进程负责与本地数据库交互渲染进程只管界面展示本地数据库SQLite SQLCipher零配置文件、支持 SQL、轻量SQLCipher 对本地数据文件做了加密界面图表ECharts数据看板需要折线图、漏斗图、饼图ECharts 的文档和例子是最全的构建工具electron-builder打包 Windows 和 macOS 安装包配置简单网上踩坑方案多有人会问为什么不用 JavaFX 或 Qt这两个确实更“原生”但考虑到后续可能要扩展 H5 端和移动端Vue 这套前端技术栈可以完全复用而且团队里会 Vue 的人比会 Qt 的人多得多招聘成本也低。Electron 有一个常被吐槽的点是打包体积大但这在内部工具场景下并不致命。真正要注意的是内存占用我在实际调优中通过关闭硬件加速、限制渲染进程数量、对大数据表格做分页渲染把空闲内存从 600MB 压到了 350MB 左右这个优化过程后面会详细讲。2.2 本地数据库的表结构设计客户数据放本地 SQLite这一点一开始就有争论。有人建议客户数据放服务端本地只做缓存但考虑到这个小工具的使用场景就是单机或小规模局域网共享直接 SQLite 反而比部署一套 MySQL 简单太多。当然如果后期需要多人在线协同录入就必须换成 C/S 架构加服务端数据库这点我会在开头和团队说清楚边界。表结构设计是整个项目的核心基础我花了不少时间。客户主表是最重要的核心字段要有客户名称、客户编码、所属行业、客户来源、客户状态潜在/跟进中/已成交/已流失、负责人、联系电话、公司地址、备注信息。客户编码我用了“K 年月日 三位流水号”的规则比如 K20250106001这样光是看编码就能知道客户是什么时候录入的。跟进记录表是业务动作的留痕载体字段有客户 ID、跟进方式电话/微信/上门拜访等、跟进内容、下次跟进时间、记录人、创建时间。客户与跟进是一对多关系每次跟进都要自动更新客户表里的“最后跟进时间”和“下次跟进时间”字段方便做待办提醒。工单表字段包括工单号、客户 ID、工单类型售后/技术支持/投诉、优先级低/中/高/紧急、状态待处理/处理中/已解决/已关闭、指派人、创建时间、解决时间。下面给出简化版的建表 SQLCREATE TABLE customer ( id INTEGER PRIMARY KEY AUTOINCREMENT, customer_code TEXT NOT NULL UNIQUE, customer_name TEXT NOT NULL, industry TEXT DEFAULT , source TEXT DEFAULT , status TEXT DEFAULT potential, owner TEXT DEFAULT , phone TEXT DEFAULT , address TEXT DEFAULT , remark TEXT DEFAULT , last_follow_time TEXT DEFAULT , next_follow_time TEXT DEFAULT , created_at TEXT DEFAULT (datetime(now, localtime)), updated_at TEXT DEFAULT (datetime(now, localtime)) ); CREATE TABLE follow_up ( id INTEGER PRIMARY KEY AUTOINCREMENT, customer_id INTEGER NOT NULL, method TEXT DEFAULT phone, content TEXT NOT NULL, next_follow_time TEXT DEFAULT , recorder TEXT DEFAULT , created_at TEXT DEFAULT (datetime(now, localtime)), FOREIGN KEY (customer_id) REFERENCES customer(id) ); CREATE TABLE ticket ( id INTEGER PRIMARY KEY AUTOINCREMENT, ticket_code TEXT NOT NULL UNIQUE, customer_id INTEGER NOT NULL, type TEXT DEFAULT after_sale, priority TEXT DEFAULT medium, status TEXT DEFAULT pending, assignee TEXT DEFAULT , content TEXT NOT NULL, created_at TEXT DEFAULT (datetime(now, localtime)), resolved_at TEXT DEFAULT , FOREIGN KEY (customer_id) REFERENCES customer(id) );表结构设计这块最重要的心得是要预留必要的冗余字段。比如客户表里的 last_follow_time 和 next_follow_time 其实是冗余字段按规范化设计应该通过查询跟进记录表来获取但实际使用中客户列表页需要频繁按“下次跟进时间”排序和筛选如果每次都要子查询几千条数据就能明显感觉到卡顿。冗余这几个字段后查询速度直接提升一个量级代价仅仅是多写几行更新逻辑。2.3 数据流通的完整链路本地版 CRM 看似简单但数据链路的设计决定了后续扩展的难度。DeskcommCRM 的数据流是这样走的界面操作 - 渲染进程Vue 组件 - Electron IPC 通信 - 主进程数据库操作层 - SQLite 数据库 - 操作完成后返回结果 - 渲染进程更新界面这个链路里最容易出问题的环节是 IPC 通信。Electron 的 IPC 本质上是异步消息机制如果同时发几十个请求渲染进程会乱序收到结果。我解决的方案是所有数据库操作封装成 Promise 形式用 requestId 标识每个请求渲染进程收到响应后根据 requestId 匹配到对应的 Promise 并 resolve。这也是桌面应用开发中常见且稳定的模式不算新东西但确实是容易忽略的细节。// 主进程側的 IPC 处理示例 ipcMain.handle(db:queryCustomerList, async (event, params) { const db getDatabase(); const page params.page || 1; const pageSize params.pageSize || 20; const offset (page - 1) * pageSize; const total await db.get(SELECT COUNT(*) AS count FROM customer); const list await db.all( SELECT * FROM customer ORDER BY updated_at DESC LIMIT ? OFFSET ?, [pageSize, offset] ); return { total: total.count, list }; });到这里整体架构的骨架已经清晰了接下来进入具体功能模块的实现。3. 核心功能模块的实现与实操细节3.1 客户管理从增删改查到查重合并客户管理模块看起来是最基础的真正做好也不简单。我可以负责任地说一个 CRM 的客户管理模块只要把“搜索”和“去重”这两件事做好了用户满意度就能提升百分之六七十。搜索方面我实现了关键字模糊搜索和组合条件筛选支持按客户名称、电话、行业、负责人精确筛选查重方面在客户表中对电话字段建立了唯一索引重复录入时给出提示。但现实场景是销售有时候就是会把同一个客户录两遍可能一个电话是手机号、一个电话是座机号根本没法靠索引拦截。所以我在系统中加了“疑似重复客户”的功能录入或导入客户时后台会把姓名和联系方式做归一化处理后进行相似度匹配。实现方式不复杂电话号码只保留数字和后缀然后再做精确匹配和前缀匹配姓名用编辑距离算法做相似度计算超过阈值就弹提醒。这个功能的背后逻辑值得说一下你把接口设计得再好也拦不住用户录错所以查重这个能力不是一个简单的增删改查而是一个提升数据质量的治理机制。数据质量在一开始就是脏的后面做统计报表全是错的后面再想清洗成本翻倍。客户详情页的设计也很有讲究。很多人做详情页就是一行一行字段罗列用户要看一大堆基本信息才能找到跟进记录。我的设计是把详情页做成一个顶部头部 标签页结构头部放客户名称、状态标签、下次跟进时间下面分“基本信息”“跟进记录”“工单记录”“操作日志”四个标签页。这样客户经理打开一个页面第一屏就能掌握最核心的信息不需要滚动和点击。3.2 跟进记录让每一次沟通都有迹可循跟进记录是客户管理的灵魂一个只有客户档案但没有跟进记录的系统本质上就是个通讯录。DeskcommCRM 的跟进记录模块在设计上做了几件事第一是快录。跟进记录一定要支持快捷录入点击客户列表里的“记录跟进”按钮弹出一个包含跟进方式和跟进内容的对话框默认跟进方式是上次使用的方式默认时间为当前时间录入完回车即保存。整个操作不能超过 5 秒否则销售就不愿意录了。第二是时间线展示。所有跟进记录按时间倒序排列在客户详情页中最新一次跟进显示在最上面并用时间线和状态颜色区隔。每个记录卡片上要直观展示跟进方式、内容摘要、跟进人和下次跟进时间视觉上一眼就能看到客户处于什么阶段。第三是下次跟进驱动。每次录入跟进记录时建议填写下次跟进时间和方式保存后主列表的对应客户行会更新排序权重。我在客户列表页增加了“今日待跟进”的快捷筛选条件在工作台首页还会显示今天需要跟进的客户数量以及具体人员分工的预览。这里分享一个我踩过的坑跟进记录表的权限设计。一个客户如果是团队共有的那么任何成员都能查看和编辑跟进记录但“谁创建的记录谁才能修改”这个约束需要加上否则就会出现 A 修改了 B 写的记录导致对不上话的纠纷。这个问题在多人协作时非常常见不要等到上线了才发现。3.3 工单管理把客户问题管起来工单模块本质上是把“客户遇到问题后内部怎么转、谁来处理、多久处理完”这条链路管理起来。DeskcommCRM 的工单管理做成了和客户档案强关联的模式从客户详情页可以直接看到这个客户开过的所有工单也能一键创建新工单。工单的状态流转我设计成待处理 - 处理中 - 已解决 - 已关闭。其中已解决表示技术侧认为问题已经处理完已关闭表示客户确认无异议后才关闭。这两个状态很重要因为我自己以前做售后时经常遇到技术说解决、客户说没解决的情况拆分后责任更清晰。工单优先级用紧急度和影响度两个维度来判定。比如“客户系统崩溃无法登录”就是紧急 影响大优先级直接拉到紧急“客户咨询某个功能如何使用”属于一般。优先级不同系统会在通知层面做不同的触达方式紧急工单不仅弹窗提醒还会通过桌面通知和声音提示避免问题沉没。工单超时管理也是我很看重的一个点。每条工单创建时会根据优先级自动计算一个“期望解决时间”比如紧急工单 4 小时、普通工单 24 小时。到时间未解决系统会自动在工单列表上标红并在工作台轮询获取超时工单数据。实现上很简单就是根据 created_at 和当前时间差做判断没有引入复杂的流程引擎。3.4 数据看板用数字驱动决策看板模块很多人容易做成摆设因为只是把数据库里的数字翻出来摆到界面上对业务没有任何指导意义。我做看板时定了三个核心指标客户新增量、跟进次数、成交转化率。这三个指标分别回答三个问题市场拓展做得好不好、销售执行到不到位、整体转化效率高不高。看板的视觉呈现用了 ECharts 的漏斗图和柱状图。漏斗图展示从潜在客户到已成交客户的转化过程每一层的数量变化非常直观柱状图展示最近 12 个月每月的客户新增量用于观察趋势。还有一个重要的小细节是“待办数量”的展示把今日待跟进客户数、待处理工单数、超时工单数这几个数字放在看板顶部并用不同颜色标出颜色越深说明越需要立即处理。做统计查询时性能是大问题尤其是筛选了时间范围和负责人之后。优化方案是提前聚合我设计了一个每日统计表在每天凌晨定时把前一天的新增客户数、跟进次数、新开工单数按维度统计好写入独立统计表。界面展示的时候直接查聚合表必要时再加一层 Redis 缓存。这套方案在数据量到几万条时依然能秒开。ECharts 在 Electron 环境里还有一个坑渲染进程的内存泄漏。图表实例如果不主动 dispose在频繁切换页面时会积累大量实例导致内存持续上涨。我封装了一个统一的图表容器组件在组件卸载前的钩子里主动调用 chart.dispose()这个问题就解决了。4. 效率优化与本地数据安全加固4.1 大列表数据渲染的优化手段客户列表是最常用的页面也是最容易卡顿的页面。数量到了几千条记录时如果一次性全部渲染成 DOM 节点Electron 的渲染进程会明显卡顿。这里有两个层面的优化手段我实测下来是有效的。第一层是分页每页 20 条这个就不用多说了。第二层是虚拟滚动。在客户列表这种行高固定、数量较大的场景下虚拟滚动可以把真实渲染的 DOM 节点数量控制在几十个以内无论底层有多少数据界面滚动起来都是流畅的。我用的方案是先对数据按更新时间排序再对可视区域做裁剪只渲染可视区上下的三倍缓冲区域。还有一个隐藏优化点在搜索框。客户列表顶部有一个全局搜索框用户会频繁输入关键词如果每输入一个字就去查一次数据库输入响应会非常卡。我把输入事件做了 300 毫秒防抖并在搜索前加一个最小字符数限制例如输入 1 个字符时不发起查询等输入 2 个以上字符时才自动搜索。这样既保证了体验也减轻了数据库压力。4.2 本地数据的加密与备份机制本地数据库直接存客户资料安全性必须重视。DeskcommCRM 用了 SQLCipher 对 SQLite 文件加密数据库文件打开时需要提供密钥。密钥的存放策略是首次启动时生成一个随机密钥然后用系统级的凭据存储Windows 上是 Credential ManagermacOS 上是 Keychain保存这样既不用用户记密码又不会明文写在配置文件中。有个细节值得提一下如果数据库文件损坏客户数据就全没了。所以我加了自动备份机制每次应用正常退出时会检测当天是否有备份文件如果没有就将数据库文件复制到备份目录并用日期命名。界面里还做了一个“导出全部数据”的功能可以将客户、跟进、工单三张表的数据全部导出为 Excel 文件方便发售之后的数据迁移或人工检查。备份触发时机一般有三种应用启动时、应用退出时、定时任务。我的建议是“退出时备份主数据 每日凌晨备份一次”的组合防止程序崩溃导致备份文件本身就是坏的。4.3 桌面端内存占用的调优记录Electron 应用的内存占用问题是一直被诟病的。我在 DeskcommCRM 里做了以下几项优化最终把空闲内存从 600MB 左右降到了 350MB 左右第一关闭不需要的 Chromium 功能。在创建 BrowserWindow 时把 sandbox、spellcheck、autoplayPolicy 等不用的功能显式关闭能省一小部分内存。第二改用单渲染进程模型不要随意开新窗口所有的页面切换都用路由来完成。第三处理完事件后主动清空数据引用尤其是大对象数组。这个优化过程是逐步做的不是一步到位的。我的建议是不要一开始就优化内存先保证功能正确再用任务管理器观察内存变化逐个排查大内存消耗点。因为过早优化很容易影响开发节奏性价比不高。5. 常见问题与排查技巧实录5.1 启动慢、窗口白屏的排查思路Electron 应用启动时出现白屏是一个很经典的问题。第一次启动时白屏时间特别长主要原因是加载了较大的 bundle.js或者渲染进程在等待主进程的某个初始化任务。排查时可以打开开发者工具看网络请求和 console 输出看看卡在网络加载还是脚本执行。我在实际开发中还遇到过一个诡异的问题在某些 Windows 机器上应用启动后窗口完全空白没有任何报错把应用最小化再恢复又能正常显示。后来定位到原因是 Windows 的 GPU 渲染驱动兼容性有问题解决办法是在创建窗口时加上 disableHardwareAcceleration 选项强制使用软件渲染。这类问题在不同的 Windows 版本和显卡驱动上表现都不一样属于 Electron 典型的跨平台兼容性坑。5.2 数据持久化和表结构变更的兼容方案本地数据库开发过程中必然会遇到表结构变更而 SQLite 不支持直接修改列类型只能建立新表、迁移数据、删旧表、重命名。这个问题在开发早期频繁出现我写了一个简单的迁移脚本每次启动时检查数据库版本号根据版本号执行对应的迁移 SQL 语句。这样团队协作时不会因为表结构不一致导致程序崩溃。下面是一个迁移脚本的示例逻辑async function migrate(db) { const versionRow await db.get(PRAGMA user_version); const currentVersion versionRow ? versionRow.user_version : 0; if (currentVersion 1) { await db.exec( CREATE TABLE IF NOT EXISTS customer (...); CREATE TABLE IF NOT EXISTS follow_up (...); CREATE TABLE IF NOT EXISTS ticket (...); ); await db.exec(PRAGMA user_version 1); } if (currentVersion 2) { await db.exec(ALTER TABLE customer ADD COLUMN wechat TEXT DEFAULT ); await db.exec(PRAGMA user_version 2); } }PRAGMA user_version 是 SQLite 自带的轻量版本号机制特别适合这种嵌入式数据库的迁移场景。建议所有做本地数据库应用的朋友都养成这个习惯不然版本一多自己都会忘记哪个表加了哪些字段。5.3 常见问题速查表现象可能原因解决思路应用启动后白屏GPU 兼容性或 JS 加载慢关闭硬件加速检查 bundle 加载路径数据库文件打不开加密密钥丢失或文件损坏检查系统凭据存储恢复自动备份文件客户列表搜索卡顿查询未做防抖或缺少索引给 name、phone 字段建索引增加防抖跟进记录保存失败外键约束或必填字段为空查看主进程日志补齐必填字段打包后安装包被杀软报毒Electron 应用被误判更换签名证书或用 NSIS 配置减少误报图表数据不刷新缓存了旧数据检查缓存策略加版本号或缓存失效时间5.4 日志级别的选择与实战意义本地桌面应用最容易被忽略的就是日志系统。没有日志出了问题只能蒙。我在 DeskcommCRM 里用了 electron-log 这个库日志分四种级别error、warn、info、debug。日常运行时只输出 error 和 warn 级别避免日志文件膨胀调试时切换成 debug 级别输出所有操作细节。日志文件按日期滚动保留 30 天位置放在用户数据目录下排查问题时直接打开看即可。有一个经验特别想分享数据库操作一定要打印 SQL 和耗时。有时界面卡顿半天查日志发现某条 SQL 跑了 2 秒就能顺着这条线索找到缺少索引或其他性能问题。没有日志的报错排查就像在黑屋子里找一根针效率极低。我在主进程的数据库操作封装里统一加了耗时统计超过 500ms 的操作单独标出来这对定位性能问题帮助巨大。6. 个人维护与迭代经验项目上线只是开始后续的维护和迭代才是真正考验人的地方。每次改完代码我都会做一轮完整的回归测试重点检查客户新增、跟进录入、工单流转、数据统计这四个核心流程有没有被破坏。因为桌面端应用不像 Web 端那样可以快速热修复打一次包、分发、安装的成本不低所以宁可本地多测几遍也不要让用户频繁重新安装。迭代方面我给自己的原则是小步快跑每个版本只加一个核心功能避免大爆炸式更新带来的回归风险。比如当前版本我只加了客户标签和自定义字段这两个能力标签用于做客户分层自定义字段用于兼容不同行业的特殊信息。等这个版本稳定了再考虑加合同管理和回款台账。另外代码里的配置项我尽量做成外部配置文件而不是硬编码。像数据库文件路径、日志保留天数、备份目录、统计任务的执行时间这些将来都大概率要改写进配置文件能让后期运维省很多事。再多说一点关于团队协作的经验。桌面端项目是前后端一体的Vue 代码和 Electron 主进程代码最好分开管理用 monorepo 结构组织主进程代码用 JavaScript 保持简单渲染进程用 Vue TypeScript 保证类型安全。这个分工一开始没做好后面重构了两次才理顺建议后来者一步到位。DeskcommCRM 做到现在我的体会是做内部工具型应用不需要追求技术多酷炫更需要关注业务逻辑的完整性和细节体验的打磨。客户管理系统的本质不是技术问题而是流程问题——把销售、客服、技术支持之间的协作流程理顺再把这些流程固化到系统里这个系统就会越用越顺手。后续我会继续补充自动化工单分配、销售目标拆解这类进阶功能也会把这套实践持续沉淀成一个更可复用的模板。
