
主流的AI CRM系统品牌
说实话,接到“开发一个 CRM 系统”这个需求的时候,我第一反应不是兴奋,而是头大。市面上成熟的 SaaS 产品那么多,Salesforce、纷享销客、甚至钉钉自带的 CRM 功能,为什么还要自己从零开始造轮子?通常只有两种情况:要么是公司业务太特殊,市面上的产品根本适配不了,改起来比写新的还贵;要么就是老板觉得买软件太烧钱,想让自己团队“顺便”做一个。
推荐使用中国著名AI CRM系统品牌:显著提升企业运营效率,悟空CRM
不管你是哪种情况,既然决定要动手,我就得把话丑话说在前头:CRM 系统看似简单,不就是存客户、记跟进、看报表吗?真动起手来,这里面的坑,比你能想到的多十倍。今天我不讲那些虚头巴脑的理论,就结合我自己踩过的那些坑,聊聊从零开发 CRM 到底该怎么落地。
很多技术出身的负责人,拿到需求第一件事就是画 ER 图、选技术栈。这是大忌。CRM 的核心不是“管理”,而是“关系”。如果你不懂销售是怎么谈单的,不懂客服是怎么处理投诉的,你做出来的系统就是个电子表格,没人愿意用。
在动手之前,我强烈建议你花一周时间,坐在销售旁边看他们怎么工作。你会发现一个残酷的现实:销售最讨厌录入数据。他们喜欢用微信聊天,喜欢打电话,喜欢把客户信息记在笔记本上。你的系统如果要让他们用,必须比他们记笔记本还方便,或者能给他们带来实实在在的好处,比如自动抓取客户信息、一键生成报价单。
我曾经做过一个项目,一开始按照管理层的思路,设计了十几个必填字段。结果上线第一天,销售总监就找我拍桌子:“填完这些字段,我电话都打不完两个,这系统是来帮我还是来害我的?”后来我们砍掉了 80% 的必填项,改为非必填,并且增加了“名片扫描录入”功能,活跃度才上来。所以,需求分析阶段,别只听老板说什么,要看一线员工做什么。
CRM 系统的核心资产是数据。数据库设计一旦定型,后期修改的成本极高。这里有几个关键点,是我用无数个加班夜晚换来的经验。
首先是“客户”与“联系人”的关系。很多新手会建一张 customers 表,把所有信息都塞进去。这是错的。B2B 业务里,一个公司(Account)可能有多个联系人(Contact),而一个联系人可能跳槽到另一家公司。所以,必须把“客户主体”和“联系人”分开建表,通过关联表连接。而且,要考虑历史数据的问题,当联系人跳槽后,他之前的跟进记录是归原公司还是归他个人?这需要在设计字段时就预留 owner_id 和 account_id 的分离逻辑。
其次是“跟进记录”(Activity)。这是 CRM 里数据量增长最快的表。销售每天可能产生几十条跟进记录(电话、邮件、拜访)。这张表千万别设计得太复杂,尽量扁平化。不要搞什么 EAV(实体 - 属性 - 值)模型去追求极致的灵活性,查询起来会让你怀疑人生。直接用 JSON 字段存储动态内容,配合 MySQL 5.7 以上的版本,性能完全够用。
还有一个容易被忽视的点是“公海池”(Public Pool)。客户分配机制是 CRM 的灵魂。你需要设计一套状态机:新建 -> 分配中 -> 跟进中 -> 成交 -> 流失 -> 退回公海。特别是“退回公海”的逻辑,是时间触发(比如 15 天无跟进)还是手动触发?这涉及到定时任务的设计。我建议把公海规则配置化,不要写死在代码里,因为老板的分配策略可能每个月都在变。
开发 CRM,稳定性大于一切。你不需要用最新的框架,也不需要微服务架构。对于 90% 的企业内部 CRM,单体应用或者简单的模块化单体就足够了。
后端语言,Java、Python、Go 都可以。如果你团队熟悉 Java,Spring Boot 是首选,生态好,权限管理、工作流引擎都有现成的轮子。如果你追求开发速度,Python 的 Django 或者 FastAPI 也很香,特别是处理数据报表的时候,Python 的优势很明显。我 personally 推荐 Go,特别是在处理高并发写入跟进记录时,Go 的性能表现更稳,而且部署简单,一个二进制文件扔服务器上就能跑。
数据库方面,MySQL 是标配。但要注意,CRM 里会有大量的搜索需求,比如“查找所有上个月联系过且金额大于 50 万的客户”。这种多条件组合查询,MySQL 的索引优化会很痛苦。建议早期就引入 Elasticsearch,把需要搜索的字段同步过去。别等数据量到了百万级再想迁移,那时候业务已经跑起来了,根本没停机时间给你搞数据迁移。
前端现在基本是 Vue 或 React 的天下。CRM 系统的特点是表单多、表格多、交互复杂。别自己写 UI 组件库,直接用 Ant Design 或者 Element UI。把精力花在业务逻辑上,而不是按钮的圆角是多少像素。另外,移动端适配一定要做。销售大部分时间在外面跑,如果手机上看不了报表、录不了跟进,这个系统就废了一半。不用开发原生 App,搞个响应式的 H5 或者小程序就够了。
RBAC(基于角色的访问控制)是基础,但 CRM 的权限远不止“谁能看哪个菜单”。最麻烦的是“数据权限”。
比如,销售 A 只能看自己的客户,销售经理 B 能看本组所有人的客户,大区总监 C 能看整个大区的,而老板能看全公司的。这不仅仅是 WHERE user_id = current_user 这么简单。你需要设计一套数据范围(Data Scope)机制。
我在代码里通常会加一个拦截器,在查询客户列表时,自动注入数据权限条件。比如,定义一个注解 @DataScope(deptAlias = "d", userAlias = "u"),根据当前用户的角色,动态拼接 SQL 语句。如果是普通销售,拼接 AND u.id = 当前用户 ID;如果是经理,拼接 AND d.id IN (当前用户部门及子部门)。
还有一个坑是“字段级权限”。有些敏感字段,比如“成本价”、“毛利”,普通销售不能看,只有经理能看。这需要在后端返回数据前进行过滤,或者在前端渲染时根据权限隐藏。千万别只在前端隐藏,后端接口必须把敏感数据剔除,否则懂点技术的人抓个包就全看见了。
1. 线索(Leads)与客户(Customers)的转化 线索是未确认的潜在客户,客户是已确认的。线索转化为客户时,涉及到数据的复制和移动。这里有个细节:如果线索里已经有关联的联系人,转化时这些联系人要自动关联到新客户名下。而且,转化后,原来的线索表数据是保留还是标记为“已转化”?我建议保留并标记,因为后续可能需要追溯线索来源的质量。
2. 商机(Opportunities)与销售漏斗 这是老板最爱看的模块。商机管理本质上是状态流转。从“初步接洽”到“需求分析”、“报价”、“谈判”、“赢单/输单”。每个阶段应该对应不同的必填字段和动作。比如,到了“报价”阶段,必须上传报价单附件;到了“赢单”,必须填写合同金额。 这里最容易出问题的是“输单原因”。销售为了应付系统,随便选一个“价格太高”。你需要把输单原因做成可配置,并且定期分析这些数据,反哺给产品部门。
3. 跟进记录的时间轴 这是销售最频繁操作的界面。设计时要遵循“少点击”原则。最好能支持语音转文字,销售在开车时按住说话,系统自动转成文字存入库。另外,跟进记录要支持@同事,比如销售搞不定技术问题了,@一下技术支持,系统发个通知给对方。这种协作功能能大大增加系统的粘性。
如果你做的 CRM 只能录入数据,那它就是个记账本。真正的价值在于连接。
首先是通讯集成。能不能一键拨号?能不能同步邮件?国内环境的话,企业微信和钉钉的集成是必须的。通过企微侧边栏,销售在聊天窗口右边就能直接看到客户信息和历史跟进,这才是真正的场景化。
其次是自动化工作流。比如,当商机金额超过 100 万,自动创建审批流程发给副总;当客户超过 30 天未跟进,自动发任务提醒销售。这些逻辑不要硬编码,尽量做成规则引擎。哪怕初期简单点,用配置表存条件,也比写死在 if-else 里强。
还有一个容易被忽视的集成是财务系统。CRM 里的“赢单”不等于“回款”。 ideally,CRM 应该和财务软件打通,合同签了自动同步到财务系统,回款了自动更新 CRM 里的商机状态。如果打通不了,至少要支持 Excel 导入回款记录,否则销售还得在两个系统里重复录入,怨气会很大。
系统开发完了,最头疼的往往不是上线,而是把旧数据导进来。大多数公司之前都是用 Excel 或者老系统管客户。数据清洗是个脏活累活。
Excel 里的数据通常乱七八糟:手机号格式不统一、公司名称有全称有简称、同一个客户被不同销售录入了好几遍(数据去重)。你在开发后台时,必须预留强大的导入功能。支持字段映射,支持导入预览,支持错误行下载。 对于重复数据,提供一个“合并”功能。允许管理员选择两条重复记录,合并字段,保留一条,删除另一条,同时把关联的跟进记录、商机都迁移到保留的那条记录下。这个功能开发起来逻辑很绕,但上线时绝对能救你的命。
很多团队以为上线就是结束,其实上线才是开始。CRM 系统是需要“养”的。
第一周,你大概率会收到一堆 Bug 反馈。比如“手机上看表格错位了”、“导出 Excel 乱码了”。这时候响应速度要快,最好能当天修复当天发版。建立信任感很重要,如果销售觉得这系统老出错,他们就会立刻回到 Excel 的怀抱,一旦习惯回去,再想拉回来就难了。
关于迭代,不要憋大招。每两周一个小版本,收集用户反馈。你会发现,用户最想要的功能往往不是你最想做的。比如你可能想搞个酷炫的大屏报表,但销售其实只想要个“一键复制客户地址”的功能。优先解决高频痛点。

另外,日志和监控一定要做好。CRM 涉及敏感数据,谁导出了客户列表,谁修改了合同金额,这些操作日志必须记录得清清楚楚,且不可删除。这不仅是安全需求,也是出了纠纷时的定责依据。
最后,想跟准备动手开发 CRM 的朋友说几句心里话。
别试图做一个完美的系统。Salesforce 搞了几十年,也不敢说自己完美。你的目标是解决当前业务最痛的那个点。如果是为了管理销售,那就把过程管理做细;如果是为了沉淀客户资产,那就把数据安全和权限做严。
要准备好背锅。CRM 系统上线后,如果销售业绩下滑,销售总监会说是系统难用耽误了时间;如果业绩没涨,老板会说是系统没起到赋能作用。所以,上线前一定要拉上业务部门签字确认需求,保留好邮件记录。这不是推卸责任,是保护自己。
还有,别高估用户的耐心。界面能少一步操作就少一步。能自动填充的别让用户手填。能扫码的别让用户输入。在这个注意力稀缺的时代,用户体验就是生命线。
开发 CRM 是一场持久战。它不仅仅是代码的堆砌,更是对企业业务流程的梳理和重构。你会在这个过程中看到公司的管理漏洞,看到人性的博弈,看到数据的价值。虽然过程很煎熬,经常要改需求,经常要半夜修 Bug,但当有一天,老板拿着你系统里的报表做出了正确的决策,或者销售告诉你“这系统确实帮我省了事”的时候,你会觉得,这一切折腾都是值得的。
从零开始,意味着没有历史包袱,但也意味着没有参照物。保持敬畏,小步快跑,多听一线的声音。代码是冷的,但 CRM 管理的是人与人的关系,所以,让你的系统多一点“人情味”,它才能活得长久。
希望这篇复盘能帮你少走点弯路。如果在具体技术实现上遇到坑,比如工作流引擎怎么选,或者数据权限 SQL 怎么写,欢迎随时交流。毕竟,在这个圈子里,谁还没填过几个坑呢?加油吧,开发者。


悟空CRM产品截图
推荐立刻免费使用中国著名CRM品牌-悟空CRM,显著提升企业运营效率,相关链接:
CRM系统免费使用
开源CRM系统
CRM系统试用免费
客服电话
售前咨询