企业官网建设流程全解析

1. 从CRM系统到DeskcommCRM：这个项目到底在解决什么问题

1.1 先聊一个特别现实的问题：客户资料散落四处

做CRM系统这件事，很多团队都干过，但真正能让自己公司销售团队天天打开去用的产品少之又少。早几年我刚接触这一块的时候，团队内部用的还是Excel加个人通讯录的混装模式，客户的联系方式散落在不同的销售手里，今天A同事跟进过的客户，明天B同事又打了一遍电话，客户被骚扰得不耐烦，销售自己也不知道这个客户之前到底聊到哪一步。真正让我下定决心去折腾DeskcommCRM的，正是这类每天都在发生的业务痛点。

DeskcommCRM这个名字，如果拆开来看，Desk代表桌面工作台场景，comm是communication和commerce的缩写，CRM当然就是客户关系管理。整个项目想做的事情，不是简单做一套“录客户+写跟进”的电子表格，而是把销售日常的沟通动作、客户资料的沉淀、商机阶段的推进，甚至售后的工单流转，全部收拢到一个统一的工作台里。它解决的痛点，说白了就是让团队从“凭记忆做销售”变成“靠系统推进销售”。

1.2 项目定位：给中小团队一套轻量但完整的客户经营底座

市面上现成的CRM工具有很多，有国际大厂的老牌产品，也有国内各类SaaS平台，功能动不动就上百个模块。但真正放到中小团队的实际场景里，问题往往不是功能太少，而是功能太多，用户打开界面都不知道点哪里。DeskcommCRM当初的设计定位就很明确：不搞大而全，只做销售链路里最高频、最影响成交率的几个核心动作。

这套系统服务的对象，是一个销售团队规模在20到50人左右的中小型企业，业务形态偏B2B项目制销售，一个客户从线索录入到最终签约，周期可能是一周到三个月不等。这类团队最大的需求是：客户资料集中管理、跟进记录实时同步、商机阶段清晰可见、团队管理层能随时知道项目卡在哪个环节。DeskcommCRM的所有模块设计，都是围绕这几个核心诉求去展开的。

我个人的体会是，CRM项目失败率高的原因，往往不是技术难度大，而是业务方自己没想清楚要什么。DeskcommCRM在立项初期就定了一条规矩：每个功能模块上线前，必须回答一个问题，这个功能能让销售每天少做哪件重复劳动。答不上来的功能，宁可砍掉也不做，这个原则在后续开发中帮我们省了大量时间。

2. 系统设计思路与核心模块拆解

2.1 整体架构：前台薄、中台厚、底座稳

DeskcommCRM的整体技术架构，我采用的是经典的B/S三层结构加微服务拆分思路。前端用Vue3加Element Plus搭了一套后台管理界面，后端服务按业务域拆分成客户服务、线索服务、商机服务、工单服务、统计服务等几个独立的微服务模块，每个服务独立部署数据库表，通过API网关统一对外暴露接口。

前端做薄的核心原因，是考虑到销售团队里不少人对系统操作并不熟练，页面越简单越好，一个客户详情页上只放最重要的信息和操作按钮，其他次要功能全部折叠进二级菜单里。后端按业务域拆分，则是为了后续团队分工和独立部署方便，客户数据量大了可以单独扩展客户服务的实例数量，而不会影响其他服务的稳定性。

数据存储方面，MySQL是主力数据库，Redis负责会话缓存和热点数据读取，比如客户列表页的统计数字、待办提醒的未读数，这些高频读取且实时性要求不高的数据都会丢进Redis里。文件存储用的是MinIO，客户上传的附件、合同扫描件都统一存放在MinIO里，数据库里只保存文件的访问路径。

2.2 核心模块一：客户360度视图

客户360度视图是DeskcommCRM里使用频率最高的页面，也是整个系统的门面。这个页面把客户的基础资料、联系人列表、跟进记录、商机进展、合同订单、售后工单等信息，按时间线和信息块的形式完整地展示在同一屏内。

这个模块的难点不在UI布局，而在数据聚合效率。一个客户相关的数据，散布在客户表、联系人表、跟进记录表、商机表、订单表、工单表这六张表里，打开一次客户详情页，后端要同时查六张表然后把结果拼装返回。最开始我写了一套同步串行查询的逻辑，客户数据量小的时候没什么感觉，等客户数量涨到几千条，跟进记录过万之后，接口响应时间直接飙到了三秒多，销售点开一个客户要等三秒，这体验基本就废了。

后来重构的时候，我引入了客户聚合根的概念，给每个客户生成一份JSON格式的聚合数据快照，存到Redis里，客户详情页打开时直接读缓存，只有客户相关的业务动作发生时，才去触发聚合数据的重建。这一改，接口响应时间从三秒多降到了两百毫秒以内，整个体验一下子就顺了。

2.3 核心模块二：线索管理全流程

线索管理是销售链路的起始点，DeskcommCRM的线索模块包含线索导入、线索分配、线索跟进、线索转客户这几个核心动作。线索的来源渠道分了几种情况来记录：市场活动投放来的主动留资、销售自己开发的新客户、老客户转介绍，三种来源在系统里用来源字段做区分，方便月底做渠道转化率分析。

线索分配这个功能，设计上做了比较多的考虑。早期我设计的是系统自动轮询分配，线索进来之后按销售成员的顺序轮流分配，大家的量是平均了，但完全不考虑线索质量和销售个人能力的匹配度。后来改成了自动分配加分配规则并行，系统先把带明确行业属性或地域属性的线索，优先分配给负责对应行业或区域的销售，剩下的再按轮询分配，这样线索的接手效率明显提高了。

线索转客户的设计看起来简单，实际坑不少。线索表里的字段跟客户表并不完全一致，比如线索只有联系人姓名和手机号，而客户表里还包含公司规模、所属行业、地址等信息，转客户的时候这些字段会变成空值。为了减少销售手动补录的工作量，我特意保留了一个消息机制，线索转为客户后，系统会给负责销售的待办里自动生成一条“资料完善任务”，提醒销售在三天内把这些信息补齐，这样既保证了数据完整性，又不会在转客户的操作瞬间给用户增加太多负担。

2.4 核心模块三：工单售后闭环

工单模块是DeskcommCRM里体现“Desk”属性的部分，也是很多纯销售型CRM容易忽略的功能。客户签约之后不是就完事了，项目实施、售后维护、问题反馈这些环节，如果跟销售环节割裂开，客户体验会很差，因为客户同一个问题可能要跟不同的人重复解释好几遍。

DeskcommCRM的工单模块支持客户或销售提交问题工单，工单进入系统后会自动分配给对应的售后工程师，工程师处理完填写处理结果，工单状态流转到待验收，最后由客户确认关闭。整个过程的关键操作节点都会自动写入客户360度视图的时间线里，这样销售再去跟这个客户沟通的时候，扫一眼就知道这个客户最近有没有未解决的售后问题，心里有底。

工单模块里我花心思最多的是工单升级机制，如果一张工单超过48小时还没关闭，系统会自动升级提醒到售后主管，再过24小时还没处理，就直接升级到项目负责人的待办。这套分级升级机制上线后，售后问题的平均处理时长压缩了将近三分之一，效果相当明显。

3. 实操过程与关键实现细节

3.1 客户管理页面的前后端实现全记录

客户列表页面是整个系统开发过程中改动次数最多的页面，不是因为技术难，而是业务方对“列表里要显示哪些列”这件事反复调整了很多次。最终的方案是：列表页默认只显示客户名称、所属行业、客户等级、负责人、最近跟进时间、下次跟进日期这几个列，其他字段全部收进详情页。这个方案的好处是列表页信息密度低，销售扫一眼就能判断这个客户的优先级，不会眼花缭乱。

前端实现上，客户列表页采用了虚拟滚动方案。因为客户数量到了几千条以后，一次性渲染所有行会导致页面卡顿。虚拟滚动只渲染可视区域内的DOM节点，滚动时动态替换，实测五千条数据的情况下页面滚动依然很流畅。

后端接口的设计上，我做了分页参数规范化、排序字段白名单过滤、筛选条件动态拼接三层处理。分页参数统一用page（页码）和pageSize（每页条数），排序字段只允许传白名单内指定的字段名，防止排序字段被恶意篡改为非索引列导致数据库压力过大。筛选条件这块，客户名称用模糊查询，行业和等级用精确匹配，下次跟进日期用范围查询，三种条件组合的时候用MyBatis的动态SQL去拼接查询语句。

// 客户列表查询核心逻辑摘要 public PageResult<CustomerVO> queryCustomerList(CustomerQuery query) { // 1. 构建查询条件 LambdaQueryWrapper<Customer> wrapper = new LambdaQueryWrapper<>(); if (StringUtils.hasText(query.getKeyword())) { wrapper.like(Customer::getName, query.getKeyword()); } if (StringUtils.hasText(query.getIndustry())) { wrapper.eq(Customer::getIndustry, query.getIndustry()); } if (query.getLevel() != null) { wrapper.eq(Customer::getLevel, query.getLevel()); } // 2. 排序字段白名单 String orderBy = SecurityUtils.validateOrderBy(query.getOrderBy()); wrapper.last("ORDER BY " + orderBy + " " + query.getOrderDirection()); // 3. 分页查询 Page<Customer> page = new Page<>(query.getPage(), query.getPageSize()); IPage<Customer> result = customerMapper.selectPage(page, wrapper); return convertToVO(result); }

3.2 跟进记录的设计：从自由文本到结构化沉淀

跟进记录这个模块，我前前后后推翻过三版设计。第一版就是最简单的文本框加保存按钮，销售想写什么写什么，结果一个月下来里面的内容质量参差不齐，有的销售就写“打电话聊了一下”，这一点信息量没有。第二版我加了一个跟进方式的下拉框，是电话沟通还是见面拜访还是微信沟通，但记录内容还是自由文本，依然没有解决信息结构化的问题。

第三版最终方案是：跟进类型分成了电话沟通、线下拜访、微信/邮件沟通、客户来访、其他，每种跟进类型配了一套内容模板。电话沟通的模板是沟通对象、沟通要点、客户意向反馈、下一步计划四个字段，线下拜访的模板是拜访地点、参会人员、核心议题、遗留问题、后续行动项五个字段，每个模板侧重点不一样，操作上都是填空式交互，销售不需要想怎么组织语言，照着填就行。

注意 跟进记录模块千万不要做成纯自由文本的输入框，用户面对一个空白输入框的时候，反而不知道写什么。给一个半结构化的模板，用户的填写意愿和内容质量都会显著提升。

跟进记录的时间线展示是另一块值得说的细节。时间线按日期倒序排列，同一客户的所有跟进记录、系统操作、商机变化、工单动态都混排在同一条时间线里，不同类型的事件用不同的背景色标签区分。这样设计的好处是，任何人打开这个客户的时间线，从头看到尾，这个客户从线索到成交到售后的完整历程就一目了然了。

3.3 权限模型：既要信息共享，又要数据隔离

权限设计是CRM系统里绕不开的硬骨头。DeskcommCRM的权限模型分成了三个层级的功能权限、数据权限和字段权限。功能权限管的是谁能访问哪个菜单、谁能点哪个按钮，这一层用RBAC模型实现，角色绑定菜单权限，用户绑定角色；数据权限管的是用户能看到哪些客户的数据，这一层是按组织架构和负责人双重维度控制的；字段权限管的是敏感字段谁能看，比如客户的成交金额和合同折扣比例，普通销售只能看到自己客户的成交金额，但看不到其他销售负责的客户数据。

数据权限的具体实现上，我采用的是在SQL查询里强制拼接数据权限过滤条件。每个用户登录系统后，会话里会缓存一份该用户的数据权限范围标识，可能的值有“仅本人数据”“本部门数据”“全部数据”。查询客户列表的时候，MyBatis的拦截器会自动解析用户的权限标识，在生成的SQL后面拼接上对应的WHERE条件，从数据源头杜绝越权访问。

-- 数据权限过滤示意 -- 普通销售：只能查自己是负责人的客户 SELECT * FROM customer WHERE owner_id = #{当前用户ID} -- 销售主管：能查本部门所有销售负责的客户 SELECT * FROM customer WHERE owner_id IN ( SELECT user_id FROM sys_user WHERE dept_id = #{当前用户部门ID} )

这套方案的优点是逻辑清晰、实现简单、性能可控，缺点是权限规则的调整需要改代码。如果后续业务方提出更复杂的权限要求，比如按客户分类授权、按金额区间授权，这套方案需要扩展成规则引擎。但以当前团队的使用场景来说，三层权限模型已经足够了。

3.4 数据统计看板：让管理者一眼看清业务进展

统计看板是DeskcommCRM里最受管理层欢迎的模块。看板分成了整体概况、销售漏斗、业绩排行、客户分布四个核心区域。整体概况展示的是本月新增客户数、本月新增商机数、本月成交金额、本月回款金额等几个核心指标，数据以卡片形式展示在页面顶部，刷新周期是五分钟。

销售漏斗是整个看板的核心，后台根据商机阶段字段做分组统计，把每个阶段的项目数量和预估金额算出来，前端用漏斗图展示。从上层到下层的转化率一目了然，哪一层流失严重管理层一眼就能看出来，然后针对性地去推进。

业绩排行按销售维度和团队维度双口径统计，销售维度看个人出单情况，团队维度看各小组的整体完成率，统计指标包括累计签约金额、累计回款金额、商机新增数量、客户新增数量，排名前三和倒数三名的数据高亮显示，管理层每天早上打开看板就能掌握前一天的经营动态。

提示 统计看板的实时性要求其实没有大家想象的那么高。最初我们把所有统计数据都做成实时查询，结果数据库压力特别大，后面改成每五分钟汇总一次写入统计表，页面直接从统计表读取数据，性能问题就解决了。CRM里的经营数据，五分钟的延迟完全不影响决策。

4. 运营落地阶段：从能用到好用的关键一跃

4.1 销售团队推广期的三步走

系统开发完成只能算项目走了一半，真正让团队用起来才是考验的开始。我在推广阶段总结了三个关键步骤，放在这里供大家参考。

第一步是初始数据导入。系统上线前，我把公司原本分散在各处的客户资料统一整理，清洗掉明显重复的条目，按客户重要性分批导入了系统。这个过程一定要做得足够细致，因为用户打开系统后发现自己的老客户资料都在，信任感会一下子建立起来，如果干干净净的，用户会认为这个系统没什么用。

第二步是线上化流程固化。新系统上线后的第一个月，我强制要求所有新增跟进记录只能通过CRM系统填写，线下表格统一停用。这个阶段一定有销售会抱怨，觉得录入麻烦，但坚持一个月之后，系统里积累了足够的跟进数据，销售自己也会发现这个系统带来的便利——客户信息的连贯性让接打电话前的准备工作时间大大缩短了。

第三步是数据反馈闭环。第二个月开始，我恢复了数据说话的传统，每周例会投屏打开CRM的漏斗看板，逐一复盘每个商机的阶段推进情况，讨论为什么某个阶段转化率低，怎么优化话术。当管理层开始用CRM的数据来指导业务动作时，这个系统就算是真正落地了。

4.2 让销售愿意天天用的三个体验细节

除了功能完整和技术稳定之外，有几个看起来不起眼的产品细节，却直接影响着销售每天愿不愿意打开这个系统。

待办提醒是第一个关键细节。销售每天一登录系统，首页待办区域直接列出今天需要跟进的客户、即将到期未处理的商机、待补全的资料、待关闭的工单，一眼扫过去就知道今天要干什么，不需要自己去翻列表找任务。待办的数据来源于系统的自动计算，跟进日期到达当天的客户自动出现在待办里，商机超过三天未跟进也自动生成提醒，这个机制给销售带来了不小的推动力。

快捷键操作是第二个细节。CRM系统是高频操作工具，销售每天要录入大量客户信息，我给常用的几个操作都配了快捷键，新增客户用Alt加N，保存用Ctrl加S，搜索直接按斜杠键。用得熟练的销售，录一个客户的耗时能从两分钟缩短到五十秒左右，效率提升了，用户黏性自然就上来了。

移动端适配是第三个细节。销售大量时间在外跑客户，如果只能回到电脑前才能录入信息，信息的时效性就大打折扣。DeskcommCRM做了一套移动端H5适配页面，核心功能在手机上都能顺畅操作，客户详情、跟进记录、商机阶段变更、工单处理，这些高频动作在手机上的体验经过反复调优，操作路径都比较短。后来很多销售反馈，在外面谈客户时，当场就能把沟通成果记录下来，这个体验比回到公司再补录要好太多了。

4.3 数据治理：CRM系统持续运转的生命线

CRM系统上线半年后，一个容易被忽视的问题会浮出水面——数据质量。系统里积累了大量的客户资料，但其中相当一部分是重复的、过时的、甚至录入错误的数据。如果不做持续治理，CRM系统最终会变成另一个“垃圾堆”，只不过从线下挪到了线上。

DeskcommCRM在数据治理上做了两个层面的自动化处理。第一层是录入时的去重检测，新建客户时，系统自动根据客户名称、联系人手机号、公司域名三个维度做相似度检测，匹配到已有客户时给出重复提示，让销售确认是否要合并或跳过。第二层是每周定时任务，系统自动扫描全量客户数据，识别出负责人已经离职但客户归属还未转移的孤儿客户，以及超过六个月没有任何跟进记录的沉睡客户，生成数据治理清单推送给管理员处理。

这两层机制上线后，DeskcommCRM里数据的准确度和活跃度都保持在了比较健康的水平。我一直认为，衡量一个CRM项目成败的关键指标，不只是功能的完善程度，更是系统里数据质量的高低。数据是系统的血液，数据脏了，再好的功能也发挥不出价值。

5. 常见运维问题与避坑实战记录

5.1 跟进记录数据量大之后：分表策略怎么选

系统上线初期，跟进记录表的增长是最快的。平均每条跟进记录加上备注信息大概占1KB左右的存储空间，团队四十个销售每天新增跟进记录大约三百条，一年下来就是十一万条数据左右。刚开始这个量级MySQL完全没压力，但系统跑到第三年，跟进记录总量超过了三十万条之后，查询性能开始出现波动。

跟进记录相关的查询，场景特征非常明显——所有的查询都是按客户ID去查某个客户名下的记录，跨客户查询的场景很少。根据这个特征，我采用了按月分表的策略，每月一张跟进记录表，表名格式为follow_up_record_202506这样的形式。查询的时候根据传入的时间范围去定位目标表，客户进入详情页的时间线查询默认只查最近一年的分表，加上索引优化，查询性能恢复到了毫秒级别。

分表方案也有它的代价。跨月的数据统计变得麻烦，比如要统计某个销售整个季度写了多少跟进记录，就要去三张分表里分别查询再汇总。对于这种场景，我又引入了一个按月归档统计的定时任务，每天凌晨把前一日的跟进记录汇总写入月统计表，统计类查询直接走汇总表，两条路都有对应的解决方案。

5.2 销售误删数据的恢复：审计日志的作用

CRM系统里误删数据这个故障，只要发生过一次就会让人长记性。某天下午，一个销售在客户详情页里不小心点了删除按钮，一整条客户记录连同下面几十条跟进记录当场就没了。虽然删除动作有二次确认弹窗，但用户手速快，确认弹窗也照样点掉。

这个问题暴露出删除操作缺少保护机制。我在后续的优化中做了两层修正，第一层是增加回收站机制，删除的客户和跟进记录先进入回收站，而不是物理删除，回收站里保留三十天，期间用户和管理员都可以从回收站恢复数据；第二层是增加操作审计日志，所有的删除、修改、导出、导入操作都会记录操作人、操作时间、操作内容摘要，一旦出现问题可以精准定位责任人和影响范围。

注意 CRM系统里不要只做软删除的字段标记，那只能防住逻辑层面，实际上用户根本没有“删错”的概念。物理意义上的保护得靠回收站机制来兜底，至少保留三十天的恢复期，这个周期基本能覆盖所有的误操作场景。

5.3 系统进度的日常巡检清单

DeskcommCRM上线稳定运行之后，我列了一份每周巡检清单，按固定节奏走一遍，能避免大多数潜在问题。

• 检查定时任务执行日志，确认统计数据汇总、沉睡客户扫描、待办提醒推送这些任务都正常跑完。
• 检查Redis内存使用情况，客户详情缓存是否在合理范围内，连接数是否接近上限。
• 检查MySQL慢查询日志，是否有新的慢SQL出现，特别是权限过滤和大范围筛选场景。
• 检查MinIO存储空间，附件文件是否存在大量久未被访问的旧文件，考虑是否要迁移到冷存储。

这份清单花费时间一般不超过二十分钟，但能把很多隐患消灭在爆发之前。运行维护这件事，功夫在平时，在问题还没变成故障之前就处理掉，比事后救火要省事得多。

6. 这套系统后续还能怎么演进

6.1 从记录工具到决策助手：AI与CRM的结合方向

DeskcommCRM跑通到现在，数据积累已经有了一定规模，我一直在思考的下一步演进方向，是让系统从被动记录工具变成主动业务助手。当前阶段，CRM的价值主要靠人的分析能力来体现，管理层要看数据、做判断、定策略，系统本身是冰冷的数据容器。但如果把AI能力引入进来，整个价值链路就会被重新激活。

比如销售跟客户的沟通，如果系统能自动把通话录音转为文字摘要，提取沟通里的关键信息点，自动生成跟进记录草稿，销售只需要做一次确认和微调就行，录入成本会大幅降低。再比如商机的健康度评估，系统可以综合商机阶段停留时间、近期跟进频率、客户意向反馈等维度，自动计算每个商机的健康分，用颜色标记风险等级，管理层点开漏斗图，优先关注哪些商机就有了明确依据。

这类AI能力不一定要自己从零训练模型，现阶段很多大模型开放平台都能提供接口能力，关键是自己的业务数据质量要足够高，模型才有好的输出效果。从技术实现的角度来说，难度可控，价值却很直接。

6.2 集成与开放：让CRM成为业务中台的一部分

DeskcommCRM目前是一个相对独立运行的系统，但实际业务里，CRM的数据不会孤立存在。客户采购之前可能先在官网留过询盘，采购之后可能要进ERP系统走订单流程，售后服务可能还要跟客服系统联动。如果这些系统之间数据不通，信息就得靠人肉搬运，既低效又容易出错。

后续演进方向里，对外开放API接口、完善Webhook事件通知、与第三方应用打通消息渠道，是三件优先级比较高的事。比如当CRM里商机状态变为“已签约”时，系统自动通过Webhook通知ERP系统创建客户档案，省去人工重复录入；官网提交的表单数据自动推送到CRM线索池，实现市场部门与销售部门的线上化移交。这类集成做多了以后，CRM就不再只是销售部门的工具，而是整个企业业务数据流转的中枢节点之一。

6.3 移动端与云端化的持续打磨

目前DeskcommCRM的移动端主要覆盖了核心操作，但在实际的深度使用场景里还有不少提升空间。比如离线模式下的记录能力，销售在外面信号不好的地方也能先写下跟进要点，恢复联网后自动同步；再比如移动端客户访问轨迹的记录，销售在外拜访时顺手记录客户现场情况，回办公室后这些信息自动沉淀到客户时间线上。这些功能不会改变系统的整体架构，但能把使用体验打磨得更加顺手。

从部署形态来看，DeskcommCRM目前还是私有化部署，后续如果有产品化的计划，云端化多租户架构是必须跨过的一道门槛。多租户意味着数据库层面的数据隔离策略要重新设计，租户级的个性化配置也要有更灵活的机制，涉及的工作量不小，但这是从一套内部系统走向一个可交付产品的必经之路。

7. 项目复盘：我踩过的坑和觉得值得的坚持

7.1 几个真实踩过的坑

整个DeskcommCRM从立项到稳定运行将近两年的时间，中间踩过的坑不算少，挑几个比较典型的说说。

第一坑是需求梳理阶段没有跟销售一线做足够深度的访谈。最初设计跟进记录模块的时候，我参考的是市面主流CRM产品的模式，觉得字段越全越专业，结果做出来的结构销售根本不愿意填。后来跟几个老销售深聊才发现，他们在意的根本不是什么专业字段，而是“方便、快、别让我填太多东西”。需求来源端的偏差，后面用了几轮迭代才纠回来。

第二坑是权限设计初版的过度自信。最开始我设计的权限配置界面特别灵活，每个角色可以自定义任意字段的读写权限，结果系统管理员根本配置不明白，最后大家都是配了一个最宽松的权限就再也不动了。后来我精简了权限配置界面，只保留了系统预设的几种方案，管理员只需要选择一个角色的数据范围，用起来反而好很多。

第三坑是统计模块的过度设计。最初经费花了很多精力去做各种维度的图表展示，饼图、柱状图、折线图一大堆，效果看起来很炫，但管理层真正在用的就是那四五个核心指标。后来我砍掉了一半以上的图表，把剩下的几个指标做深做透，使用频率反而上来了。“少即是多”这句话在CRM系统里是真理。

7.2 回头看：哪些坚持是对的

要说让我觉得值得的坚持，第一是坚持“一切以数据沉淀为中心”的设计理念。DeskcommCRM里几乎所有功能设计，都是以让业务数据自然沉淀为前提的。跟进记录模板化、商机阶段标准化、工单流程规范化，这些设计在初期会增加用户的录入成本，但只要坚持下去，数据积累形成规模之后，无论是业务分析还是AI应用，都有了扎实的底座。

第二是坚持迭代节奏的克制。DeskcommCRM没有做过推翻式的大版本重构，每一次迭代都是小步快跑，功能增量控制在用户能自然接纳的范围内。系统运行两年来，用户的操作习惯相对稳定，没有因为频繁的大改产生抵触情绪，这一点很重要。

第三是坚持把“性能”当成功能来做。CRM系统的用户对响应速度其实相当敏感，一个页面超过三秒钟打不开，用户就会觉得系统卡顿，然后就会减少使用。DeskcommCRM从设计之初就把接口性能作为验收标准来卡，详情页、列表页、看板页这些核心页面的响应时间都有硬性指标，这个坚持换来的是销售团队对系统整体稳定的信任。

到目前为止，DeskcommCRM依旧在持续迭代中，新的需求不断出现，数据量也在不断增长。维护一套自己从零设计的系统，跟维护一套外部采购的系统感觉是完全不同的，前者就像带自己的孩子，每个细节都了如指掌，哪里有问题第一时间就能定位。如果你也正在做或者正准备做一套CRM系统，希望这份分享能让你少走一些弯路。