1. 项目缘起：为什么会有 DeskcommCRM 这个项目
1.1 先聊聊我对这类系统的真实感受
做销售和客户服务的人应该都有这种感觉：客户资料、跟进记录、通话内容、报价单一堆东西散落在 Excel、聊天软件、邮箱和脑子里，真正需要找一条半年前的沟通线索时，翻半天都翻不出来。市面上大多数 CRM 不是不好，而是太重、太“流程化”，实际用起来要么填表填到怀疑人生，要么只适合坐在办公室里用浏览器慢慢点。
我做 DeskcommCRM 的初衷特别朴素：想让“桌面办公+客户沟通”这两件每天都要做的事，能够在一个窗口里完成，而不是来回切换七八个软件。DeskcommCRM 这个名字拆开来看很直白——Desk 代表桌面端应用场景，comm 代表沟通（Communication），CRM 则是客户关系管理。合起来的定位就是：一款面向桌面办公场景、以沟通记录为主线、轻量但对业务有真实约束力的客户关系管理工具。
1.2 做这个项目之前，我观察到的三个真实痛点
第一个痛点是沟通记录断层。销售或客服每天要打很多电话、回很多消息，但传统的 CRM 往往把“沟通”这件事放在系统之外，系统里只记录“跟进结果”，过程丢了。客户说过什么、承诺过什么、上次谈到哪一步，这些最有价值的信息往往只存在于个人的聊天记录里。
第二个痛点是业务流程和沟通工具两张皮。你在 CRM 里看到一个客户有新的商机，想跟进，必须切到电话软件或者聊天工具里找人，打完电话再回到 CRM 里补记录。这个切换动作看起来只有几秒钟，但一天几十次下来，人的疲劳感和抗拒感是非常明显的。
第三个痛点是数据在云端但人在桌面上。很多人每天大部分时间对着的是 Windows 或 macOS 桌面，浏览器只是其中一个小窗口。如果 CRM 能直接停靠在桌面上，来电时自动弹窗、客户资料自动带出、通话结束自动生成记录，效率提升是立竿见影的。
1.3 这个项目适合谁，能解决什么问题
我写这篇文章，核心是复盘 DeskcommCRM 从思路、设计到开发落地的完整过程。适合正在做 CRM 类产品规划的产品经理、负责企业级桌面应用开发的工程师，以及准备在公司内部搭建一套轻量客户管理体系的业务负责人参考。
DeskcommCRM 解决的问题不是“把客户名单存起来”那么简单，而是把“客户全生命周期沟通”这件事变成一条清晰可查的数据流。它整合了客户信息管理、沟通留痕、任务跟进、合同/回款轻量管理等能力，同时为高频操作提供了桌面端的快捷入口。你可以把它理解成：一个装有客户数据库的桌面助手，每一次沟通都会被自动沉淀成客户档案的一部分。
2. 核心架构与关键技术选型拆解
2.1 桌面端为主，Web 端为辅的总体形态
在技术选型之初，我做过一个比较正式的调研。市面上的 CRM 产品，大致分三类：第一类是纯 Web 型，打开浏览器就能用，部署成本低但因为浏览器本身的沙盒限制，很难做到系统级的来电弹屏和事件监听；第二类是移动端优先型，适合外勤销售，但屏幕小，不适合在办公室做复杂的客户分析和长文本记录；第三类是桌面端优先型，也就是我最终选择的路线。
桌面端优先的好处非常明确：可以调用系统级的通信能力，可以做到来电弹窗、全局快捷键、悬浮窗口这些浏览器不容易实现的交互形态。数据可以本地缓存一部分，即使断网也能查看基础客户信息和历史沟通记录，网络恢复后再自动同步。在客户现场演示时，这种“离线可用”的能力非常加分。
技术选型上，我最终采用的是 Electron + Vue 3 + TypeScript 作为桌面客户端的技术栈。Electron 的生态成熟，跨平台打包方案稳定，对于需要快速迭代验证业务逻辑的项目来说，投入产出比最高。如果你对性能和包体积有极端要求，可以考虑 Tauri，但对这套业务场景来说，Electron 才是更稳妥的选择。
2.2 数据层与后端服务的模块划分
后端服务我采用模块化单体（Modular Monolith）设计，而不是一开始就拆微服务。项目起步阶段，团队和业务规模都有限，微服务的运维成本和分布式事务的复杂度反而是负担。但为了避免后期重构，模块边界从一开始就划清楚了。
后端分成几个核心域：客户主数据域、沟通记录域、商机与流程域、组织权限域、以及通用能力域（文件、通知、审计日志等）。每个域之间通过内部 API 交互，但数据库层面保持 Schema 隔离。这样即便以后某个域流量暴涨，可以单独抽出来做服务，不需要推倒重来。
数据库的选择上，主库用的是 PostgreSQL。选择它的原因很简单：数据一致性和事务能力可靠，JSONB 字段又提供了灵活扩展的空间。客户资料这种数据天然适合“基础字段 + 自定义属性”的结构，如果全部用传统关系表去建模，每一次加字段都要改表结构，非常痛苦。PostgreSQL 的 JSONB 在不牺牲查询能力的前提下很好地解决了这个问题。
2.3 客户端与服务的通信方案
桌面客户端和服务端之间的通信，HTTP 和 WebSocket 各承担不同的职责。常规的增删改查走 HTTP / RESTful 接口，按部门或角色做接口级权限控制；而需要实时感知的数据变化，比如新商机提醒、任务到期提醒、来电弹屏信号，走 WebSocket 长连接推送。
这里有一个很关键的细节：离线断点续传。桌面端在弱网或离线环境下产生的数据变更，会先进入本地队列，网络恢复后按照时间戳顺序推送到服务端。服务端会做冲突检测，如果发现同一字段有两个不同的修改版本，会按照“最近修改优先”的策略自动合并，同时把被覆盖的版本存入历史版本表，保证可追溯。
3. 从零到 MVP：完整实现路径复盘
3.1 四步搭起核心闭环
我大概花了六周时间，完成 DeskcommCRM 的第一版核心闭环。这里的核心闭环是指：一个客户从被录入系统，到建立跟进任务，到通过电话/消息完成沟通，再到沟通记录自动沉淀到时间轴，最后在商机阶段完成转化的完整过程。
第一步做的是客户资料的数据模型和基础 CRUD，这是所有上层功能的地基。第二步接通软电话能力，通过 WebRTC 与 SIP 网关对接，让桌面客户端可以呼出和接听电话。第三步把通话状态与客户页面联动：来电时根据号码反查客户，匹配到客户后自动弹屏。第四步把沟通记录、跟进任务、商机阶段三个模块串成一条业务流，让每次跟进动作都对商机阶段产生相应影响。
3.2 客户数据模型的落地
客户模型我设计成三层结构：企业（Account）、联系人（Contact）、活动（Activity）。这个结构借鉴了 Salesforce 的标准模型，但做了大量精简。企业与联系人分离的好处是，一个企业可能对应多个联系人，而商机和合同挂在企业层面，跟进记录可以挂在企业也可以挂在联系人上，二者之间是清晰的层级关系。
自定义字段这块，我用 JSONB 存扩展属性，同时把高频查询的字段做成了独立的数据库列。这个折中方案的实现方式是这样的：建一张 customer_profile 表，固定字段包括客户名称、行业、规模、来源渠道、负责人、状态等，另加一个 extra_info JSONB 字段存储动态属性。查询时如果需要按某个自定义字段筛选，调用方先注册字段元数据，后台自动维护一张增量索引表。这个方案让我在项目初期没有被字段扩展的需求拖慢开发节奏，同时又保持了查询性能。
3.3 沟通模块的打通
通话模块是整个项目里技术风险最高的一环，所以我把它拆成了三个子功能逐步实现：点击拨号、来电识别、静默录音。
点击拨号实现起来相对容易，客户端把电话号码发给后端，后端通过 SIP 网关发起呼叫，然后回拨到坐席分机，坐席接听后系统自动呼叫客户号码。这种回拨方式的优点是稳定，缺点是接通后才会建立真正的通话通道，中间有短暂延迟。来电识别则需要对接网关的事件推送：网关收到来电后把主叫号码发到业务后端，业务后端以毫秒级速度在客户库里检索。匹配到客户信息后，通过 WebSocket 推送到桌面客户端，桌面端弹出悬浮卡片，显示客户名称、历史跟进记录、最近商机进展。这个体验非常直观，也是团队内部和早期种子用户觉得最惊艳的功能。
静默录音牵扯到合规问题，我在这里单独说明一下。启用在途录音和全程录音之前，一定要确认业务所在地区的个人信息保护相关要求。我们处理的方案是：在系统设置中增加“录音前提示”选项，默认打开坐席话术提示音，同时录音文件加密存储，并按权限分级访问。合规红线不能侥幸踩，这个教训各位务必重视。
3.4 商机流程与任务看板的联动
商机管理这块，我设计了一个极简的状态机：初步接触、需求确认、方案报价、商务谈判、赢单/输单。每个状态之间的流转不是随意点击的，系统会有两道检查：第一，当前客户是否有未关闭的待办任务；第二，当前客户是否缺失必要字段（比如预估金额、决策人信息等）。
这种做法从一开始可能会让人觉得繁琐，但实际用下来非常有效。它强制团队在推进商机之前把该做的功课补上，避免一张“什么信息都缺”的商机单被一路推到成交阶段，最后连赢单理由都写不清楚。
任务看板则是桌面端最常用的界面。按状态分列：待处理、进行中、已完成。每个卡片显示客户名称、任务类型、优先级、截止时间。桌面端通过本地通知在任务到期前 30 分钟提醒一次，超时未处理再提醒一次。团队负责人可以按成员维度查看任务负载，及时发现分配不均的问题。
4. 桌面端体验与效率工具的实现细节
4.1 全局搜索：桌面端的效率担当
Desktop 类应用和 Web 应用在交互上最大的区别，就是用户期望“快速到达”。浏览器里你习惯先打开系统，再慢慢点菜单；但桌面端用户更倾向于按几个快捷键，立刻到达目标位置。 DeskcommCRM 的全局搜索框支持模糊搜索客户名、联系人、手机号、邮箱、合同编号。快捷键是 Alt + K，任何界面下都能唤起。搜索结果按命中类型分组，支持键盘上下键选择，回车直接跳转到对应详情页。
这里我加了一个很有意思的小功能：最近浏览。全局搜索框下方会显示最近打开的 10 条客户记录，带时间戳。这个功能看起来不起眼，但对每天要反复跟进同一批客户的销售来说，省掉了大量重复搜索操作。
4.2 悬浮窗：来电场景下的“不打扰”设计
来电弹屏是 DeskcommCRM 最关键的体验点。但这里有一个产品设计上的取舍：如果不小心正在处理另一条商机，突然弹一个大窗口切走当前视角，非常打断思路。所以我把来电弹屏做成轻量悬浮卡片，默认显示在屏幕右上角，持续 15 秒。卡片上展示客户名、电话归属地、历史沟通次数、上次跟进时间，并提供三个操作按钮：接听并打开客户详情、直接接听仅录音、拒接并发送短信模板。
如果来电号码没有匹配到任何已有客户，悬浮卡片会显示“新客户”标识，并提供“快速建档”按钮。点击后直接弹出极简建档表单，只需要录入客户名称和备注，号码已经自动带出。等通话结束后，详尽的沟通记录再补充完整。这套流程充分考虑了真实业务场景中的行为习惯：先接住这个线索，再慢慢补全信息。
4.3 本地缓存与断网模式
桌面端相比 Web 端还有一个优势：本地存储。 DeskcommCRM 把客户列表、最近 100 条沟通记录、常用联系人缓存在本地数据库中。在断网状态下，用户仍然可以完成客户资料的查看、跟进记录的草稿编辑，以及新客户的本地建档。等网络恢复后，本地队列中的数据会自动同步到服务端，并在界面上给出同步完成的提示。
我在实现本地缓存时踩了一个坑：本地缓存不能只存“当前用户可见的数据”，还需要考虑权限过滤。如果用户之前在桌面端登录时看到的是 A 部门的数据，换了一个低权限账号登录，本地缓存如果直接复用，就有越权查看的风险。我的解决方案是：缓存数据以账号 ID 为隔离维度，切换账号就切换缓存命名空间；同时设置缓存有效期，超过 72 小时未使用的数据自动清除。
5. 上线后最常见的五个问题与排查实录
5.1 通话状态不同步
第一个比较高频的问题是：坐席已经挂断了电话，但桌面端仍然显示“通话中”。刚开始我以为是 WebSocket 推送丢了消息，后来排查发现是电信网关在某些异常挂断场景下没有回传挂机事件，导致 DTMF 信号的释放没有触发。
排查思路是：在服务端增加心跳检测，每 5 秒检查一次通话通道的存活状态；如果连续 3 次心跳无响应，自动强制结束通话状态，并在客户端提示“通话状态已自动复位”。同时把所有通话状态变更为审计日志，方便事后归因。这个优化上线之后，通话状态卡死的工单从每周十多个降到了近乎为零。
5.2 大客户列表的加载慢
客户量超过十万条之后，首次加载列表页明显变慢。我排查后发现瓶颈主要来自关联查询：每次加载列表都要 join 客户表、联系人表、最新活动表，三个表的索引和统计信息不准确，导致查询计划选错索引。
优化措施做了三步：第一步是给常用过滤条件加了组合索引；第二步是把列表查询拆成两个阶段，先查主表数据，再按主键批量回表查关联数据；第三步是在服务端做键集分页（Keyset Pagination），通过游标记录上一页最后一条数据的 ID，避免深度分页时 offset 过大造成的性能下降。优化后的结果很可观：第一屏加载从 3 秒降到了 400 毫秒左右，无限滚动翻页也完全没有卡顿感。
5.3 Windows 桌面端兼容性问题
Electron 在 macOS 上表现比较稳定，但在 Windows 上遇到一些跟系统字体缩放比例相关的界面错乱问题。有些用户把 Windows 显示缩放设置成了 125% 或 150%，桌面端的部分弹窗和输入框会出现文字溢出的情况。
排查后发现是 Electron 的渲染进程没有正确处理设备的 DPI 缩放比例。解决方案是在应用启动时读取系统当前的缩放比例，用 CSS 变量动态调整根字体大小和各组件间距。同时把窗口的最小尺寸限制进行调整，避免用户在过小的窗口下使用导致布局不可用。这里也提醒大家：桌面应用发布前，务必覆盖 Windows 系统常见的几种缩放在不同分辨率下的显示情况，这比功能测试更容易被忽略但影响直观体验。
5.4 团队使用率低，数据不更新
产品上线之后最怕的不是 Bug，而是团队根本不用。我观察了一周发现，部分成员只在被要求的时候打开系统，偶尔录入一条跟进记录就关上。大部分人不愿意在客户电话结束之后再打开系统“补一条记录”。
后来我调整了策略：把记录生成的主动权从“人主动录入”变成“事件自动生成”。电话结束的瞬间，系统自动生成一条跟进记录草稿，记录中自动附上通话时长、通话时间、是否接通、挂断方以及录音链接。坐席只需要补充一两句总结，点击确认即可。如果有需要记录的内容，不再从空白表单开始填写，几十秒就能完成全套操作。事实证明，把默认操作从“新增”改成“确认并补充”之后，使用率显著提升。
5.5 权限配置过于复杂导致管理员困惑
初期我把权限模型设计成 RBAC，角色可以配置菜单权限、数据范围权限、字段级权限和按钮级权限。理论上很完善，实际上小团队的管理员看到几十个复选框完全不知道怎么配。
后来我做了两处调整：第一，提供三套预设角色模板（老板视角、销售主管视角、客服坐席视角），管理员可以直接套用，再按需微调；第二，界面上的权限项按使用频次排序，不常用的高级选项折叠到“高级设置”里。这个调整让实施周期从平均三天降到了半天，效果非常明显。
6. 后续迭代方向与个人思考
6.1 移动端协作与消息联动
DeskcommCRM 目前的定位是桌面优先，但在后续规划中，移动端是绕不开的方向。外勤销售人员不可能随时坐在办公桌前，他们需要在外出时查看客户资料、补充拜访记录、接收商机提醒。
移动端的设计思路是“协作优先于完整”。不需要承载所有桌面端的功能，但必须保障三件事：第一，客户信息的快速检索和查看；第二，跟进记录的快速录入；第三，待办任务和商机提醒的通知触达。移动端和桌面端的实时同步可以借助 WebSocket 或者推送通道来实现。这里有一个建议：移动端的离线缓存要做得比桌面端更激进，因为移动网络质量波动更大。核心客户数据按账号维度缓存最新 100 条可以覆盖绝大多数场景。
6.2 自定义对象与字段级权限
在服务客户的过程中，我不止一次遇到团队想要管理“客户”之外的其他实体：项目、合同、代理商、门店、设备等。通用型 CRM 要支撑这些场景，自定义对象的能力是必须的。
自定义对象不是简单地加一张表，而是要设计一套元数据驱动架构：对象定义、字段定义、布局定义、权限定义全部存入元数据表。运行期由底层引擎动态解析元数据，生成对应的查询和表单。这个工程量比较大，但一旦完成，系统的扩展边界就完全打开了。字段级权限在自定义场景下尤其重要，因为有些自定义字段可能出现在多个对象上，不同角色对其可见性要求不同。
6.3 与主流办公协同软件的双向集成
和企业微信、钉钉、飞书这类办公协同软件的集成，是很多企业选型时的刚需。最常见的集成场景有两个：一是消息通知推送，将商机提醒、任务到期、审批消息推送到企业 IM；二是账号打通，使用企业 IM 的身份认证登录 CRM，免去记忆多套密码的麻烦。
我在设计集成方案时的原则是：集成不绑架业务。消息推送通过 Webhook 适配器模式实现，企业 IM 的类型是可配置的；账号认证支持 OAuth 2.0 标准流程，客户方管理员可以灵活选择是使用默认账号体系还是对接企业目录服务。双向集成如果做得好，相当于把 CRM 从“一个需要专门打开的系统”变成了“办公过程中自然触发的一个场景”，这对提升使用率有非常大的帮助。
7. 写在最后的一些经验之谈
7.1 做这类产品，心态上要接受“没有完美的 CRM”
客户管理系统的难点从来不在技术，而在业务的多变性和使用者的惰性。每一家公司的客户管理流程都不一样，甚至可以精细到同一行业的不同团队。产品可以做的，不是试图满足所有差异化的流程，而是找到几条最通用的主路径，把它们做透，然后把扩展的空间留给自定义能力。
DeskcommCRM 走到今天，我最满意的地方不是某个技术方案有多么复杂，而是“来电自动弹屏”“通话结束自动生成记录”“全局快捷键搜索”这三个细节真正改变了团队成员的使用习惯。工具只有在具体场景下让人感到“省事”，才会被真正用起来。做系统的人应该始终把这一点放在心上：功能数量不是核心，运营效率才是。
7.2 如果让我重来一次，会在一开始就做对的几件事
如果再给我一次机会，我会更早把“自动化规则引擎”纳入规划，而不是等到需求频繁出现后才开始设计；我会更早建立清晰的审计日志与数据导出机制，因为客户越用越久，对数据归属问题的敏感度会越来越高。
另外，我会在早期就抽出更多时间跟真实用户一起工作，观察他们如何使用系统，而不是只看报表和反馈。很多体验问题，从报表上看不到，从用户访谈里也未必问得出来，只有坐在他们旁边看着他们一步步操作，才会意识到哪个按钮容易被忽略、哪个流程让人烦。对于做任何工作的人来说，靠近真实的使用场景，永远是最有效的产品方法。
最后分享一个习惯上的小建议：不管做什么工具，每个迭代版本都要留下一张“技术决策记录”，记下当时为什么这么选、其他方案是什么、放弃它们的原因是什么。三个月后回头看，你会感谢自己写下了这些内容。这套方法在我做 DeskcommCRM 的过程中帮了很大的忙，也推荐给你们。
