简介面向网页前端开发者与毕业设计学生的客户关系管理系统原形包定位为CRM界面与交互设计的参考范本能帮助快速理解销售、市场营销、服务等业务域如何通过页面组织起来并避免从零搭建原形的高成本。原形围绕JavaScript验证、jQuery高效DOM操作与Ajax异步数据交换展开详细覆盖邮箱格式校验、手机号码合法性检查、密码强度判断等前端逻辑也演示了无刷新更新客户信息、查询订单状态、同步销售数据等典型场景能够直观呈现这些技术组合在真实CRM业务中的价值。压缩包大小约10MB内部整理有原形页面草图、交互流程图、前端代码示例与必要注释便于按图索骥地搭建页面骨架、核对交互细节也适合在课程设计或公司内部分享中直接复用。目前已有299人学习浏览整体非常适合作为课程设计、毕设前端部分或企业CRM预研的起步资料能有效缩短开发周期并帮助提升界面的易用性、可维护性与数据规范意识。 做CRM项目这些年我见过最多的一个场景是产品经理抱着一份原型文件进来说“CRM客户关系管理系统原型做完了你们看看”。文件打开页面画得确实漂亮客户列表、商机看板、合同台账样样齐全。可你追问一句客户和联系人的关系是一对多还是多对多线索转客户是自动还是手动商机输单之后还要不要保留跟进记录他往往就愣住了。“原型”这个词偶尔被人写成“原形”这个笔误其实挺有意思——很多CRM原型恰恰是只画出了“形”没画出“原”。我做这套CRM系统原型时第一步不是打开Figma或者Axure而是先回答一个问题这个系统到底要管哪些对象对象之间是什么关系每一步动作会带来什么结果。这篇文章就把这套思考过程完整摊开来讲从业务对象、字段权限到数据模型、开源参考再落到最后的自建还是采购决策按真实做原型的顺序一路走到底。适合正在做CRM规划的产品经理、打算自研一套客户管理系统的独立开发者以及想搞清楚“免费CRM和自建到底差在哪”的团队负责人。1. 先别画界面CRM原型的第一步是理清业务对象1.1 六个核心业务对象CRM叫“客户关系管理系统”关键词是客户和关系。它要管理的不是一堆页面而是客户从陌生到成交、再到复购的完整链路。这条链路上有几个绕不开的业务对象我按出现顺序给你列一下线索Lead还没验证过身份的潜在客户信息可能来自表单、地推、转介绍质量参差不齐。客户Customer正式建档的企业或个人是整套系统的数据中枢。联系人Contact客户组织里具体对接的人一个客户底下可能有多个联系人。商机Opportunity一个有望成交的生意机会包含阶段、金额、预计成交时间。合同Contract成交之后签订的正式契约是回款的依据。回款记录Payment每一笔钱到账的情况包括计划回款和实际回款。经常会有人问要不要把工单、售后、营销活动都塞进来。我的建议很明确原型第一版宁缺毋滥。先把“线索到回款”这条主线跑通工单、售后、营销这些延展模块做成可插拔的扩展区等主线稳定了再逐个接进来。一上来就铺十几个对象后面每个模块都要跟着改字段还会交叉打架最后原型会变成一团乱麻评审会上被怼得没法看。1.2 对象链条从线索到回款一句话串起来这些对象之间的关系可以用一句话串起来线索成熟后转化建档成客户客户下面挂联系人和商机商机赢单生成合同合同关联回款计划与实际回款。这套关系链不只是画给开发看的数据模型它直接决定产品形态。比如线索转客户转完之后线索还要不要留我的经验是保留但标记为“已转化”。因为线索的来源渠道、首次接触时间都是后续分析获客成本的关键数据转完就删等于把报表的根给挖了。再比如联系人和客户的关系一个联系人如果跳槽去了另一家公司是要改客户还是新建联系人原型阶段如果不把这类关系定义清楚开发上线之后业务部门每天都会来投诉。1.3 状态机给业务对象装上生命周期对象定义清楚之后紧接着要给每个对象画状态机。这是CRM原型里最容易偷懒、也最要命的部分很多人拿着“未处理/处理中/已关闭”三个状态糊弄过去结果上线后统计报表出不来。商机的状态我强烈建议做五阶段初步接触、需求确认、方案报价、商务谈判终态是赢单或输单。为什么要单独分出赢单和输单而不是统一叫“关闭”因为管理者需要知道赢单率和丢单原因后面统计平均成交周期、各阶段转化率全靠这套状态数据。合同的状态则要走草稿、审批中、生效、执行中、已完成、已终止。其中“审批中”这个状态特别容易被新手漏掉但实际业务里合同不经过审批直接生效财务部门第一个不答应。2. 原型的关键不在页面而在字段和权限2.1 字段设计给每个对象定“身份证”页面画得再像样字段设计不合理原型落地的时候还是得返工。以客户表为例我整理了一套基础字段清单。基础标识客户名称、客户编号、客户类型企业/个人。分类字段所属行业、客户规模、来源渠道、客户级别。归属字段负责人、创建人、创建时间、更新时间。联系字段联系电话、邮箱、地址注意这类字段要做加密展示。这里必须留一手自定义字段机制。不同团队的销售管理方式差异很大有的按行业管客户有的按区域管有的按客户规模定权限。原型阶段就在界面上预留“新增自定义字段”的入口哪怕第一版后台不真正开放也要把交互设计出来。我的习惯是让自定义字段支持文本、单选、多选、日期、数值五种类型覆盖九成以上的扩展需求。2.2 数据权限从“谁能看”到“能看谁的”权限是CRM原型里最容易被忽略、也最致命的部分。我见过一个原型阶段很完美的项目上线第一周销售就开始私下用Excel备份自己的客户因为系统里同事能看到所有客户手机号。权限在原型里就要画清楚不能等开发阶段再说到那时业务部门早就跑了。CRM权限至少分三层功能权限管菜单和按钮数据权限管“能看谁的客户”字段权限管“敏感字段谁能看见”。数据权限最常见的模型是本人、本部门、全部再加一个自定义范围。字段权限则单独针对手机号、成交底价这类敏感信息。设计原则是默认收紧按需放开。原型阶段的权限页面画不了太深但至少要把“负责人”“数据范围”这两个概念在原型注释里写明白让评审的人看一眼就知道你这套系统是有规矩的。3. 数据模型是原型的骨架核心表如何设计3.1 八张核心表先定下来原型画到一定深度数据库层面的设计就该介入了。不需要把所有表都建出来但核心表的结构要定稳否则后面开发要改表结构成本远高于改页面。表名职责关键字段线索表lead存放未验证的潜在客户名称、来源、状态、负责人、联系方式客户表customer已建档客户的主数据名称、类型、行业、规模、等级、负责人联系人表contact客户下的对接人姓名、职位、电话、邮箱、客户ID商机表opportunity跟踪在谈项目名称、金额、阶段、预计成交时间、客户ID合同表contract成交契约合同编号、金额、状态、客户ID、生效日期回款表payment计划与实际回款计划金额、实际金额、回款日期、合同ID跟进记录表follow_record每次沟通的留痕类型、内容、下次跟进时间、关联对象操作日志表sys_log记录关键操作操作人、操作类型、操作内容、时间表与表之间的关系用ID关联而不是存冗余文本。比如跟进记录表里存的是客户ID和商机ID而不是客户名称和商机名称。为什么因为客户改了名字所有引用它的跟进记录会一起变存文本就会出现“客户张三已经被改名为李四但老记录里还写着张三”的脏数据。只有一种情况允许存冗余下单那一刻的商品名称和价格快照因为历史订单不能跟着商品改价而变动。3.2 容易被忽视的四个通用字段除了业务字段每张核心表我建议都带上这四个通用字段。租户ID哪怕目前只给一家公司用也要预留SaaS化是早晚的事。软删除标记业务数据用软删除删了还能捞回来领导误删客户才不至于永久性完蛋。创建人、创建时间、更新人、更新时间这是排查问题的基础。乐观锁版本号避免两个人同时编辑一条客户记录时互相覆盖。这四个字段看着不起眼没有它们后面每一次排查扯皮都要花十倍时间。原型阶段跟开发对齐数据模型时把这些写进统一约定里省得每个人建表风格不同后期维护头疼。4. 画原型时最容易翻车的五个细节4.1 客户去重与合并原型阶段就要定的规则客户记录重复是CRM运营最头疼的问题。销售A录入了一个客户销售B又录了一遍两个人都觉得客户是自己的。原型阶段就要设计去重策略要么在录入时模糊匹配名称并提示要么提供手动合并功能。我踩过的坑是没有设计合并规则开发自己做了个“覆盖式合并”把老客户的负责人改成新客户导致老客户的合同回款报表全对不上了。正确的合并逻辑应该是保留主客户ID被合并客户的数据全部迁移到主客户历史引用统一改ID合并记录写进日志。这个逻辑在原型阶段用注释和流程说明写清楚开发照着做就不会出大错。4.2 跟进记录要做时间轴不是聊天版跟进记录是销售每天用最多的功能但很多原型把它做成了“写一条存一条”的列表时间一长根本看不出客户关系推进的脉络。我在实际项目里见到的优秀交互是时间轴视图。按时间倒序展示所有跟进动作包括电话、拜访、微信沟通、邮件每条记录除了内容还要有类型标签和下次跟进提醒。这样销售打开客户详情页一眼就知道上一次沟通到哪了下一步该干什么。原型里哪怕不做交互动画也要把时间轴的骨架画出来这是销售每天真正会用的界面。4.3 操作留痕出了事能查权限做不好客户被抢了操作不留痕客户被误改了连谁干的都找不到。CRM里的字段修改、数据导入导出、合并删除记录都要进入操作日志。这里我强调一个容易被忽略的细节不是所有操作都要记录只记录高风险动作。比如修改手机号、转让客户、删除合同、导出数据。普通查看不记录否则日志表会变成数据垃圾场查日志比查业务还慢。原型里专门画一页操作日志查询界面把筛选条件设计出来既是给管理层看的也是给后期开发做参考。4.4 列表页的筛选与列定义列表页看着简单其实是原型里最容易做得敷衍的地方。很多原型就放一个搜索框加一张表这是不够的。真实业务里销售筛选客户至少需要按负责人筛选、按状态筛选、按行业筛选、按最近跟进时间筛选。列表的列还应该支持自定义显示因为销售关注手机号老板关注订单额总监关注客户阶段同一张列表不同角色看着就不一样。原型阶段把筛选区和自定义列入口画出来比开发完再补要省事得多。4.5 详情页的操作按钮别乱藏客户详情页除了信息展示更重要的是操作组织。原型里最容易出现的问题是把“新增跟进”放在二级菜单里把“转让客户”做成仅图标结果销售在用的时候疯狂点错。我的建议是高频操作放显眼位置低频高风险操作放更多菜单并二次确认。“新增跟进”永远是客户详情页最核心的动作必须一眼能看到很多团队干脆把“跟进记录”和“新增跟进”并排放。“编辑客户”可以放右上角“合并客户”“删除客户”必须放二级菜单并弹二次确认。这个排列逻辑同样适用于商机和合同详情页。5. 从原型到可运行开源CRM源码能借鉴什么5.1 开源项目里最值钱的是业务闭环不是代码热词里提到芋道CRM、青动CRM源码这类开源项目国内其实不少大多是后台管理框架的二开作品或独立产品精简版。如果你问我的建议可以直接下载源码看看但不建议无脑拿来做生产系统。开源CRM源码最值钱的地方是帮你验证业务闭环。比如线索、客户、商机、合同、回款这几个模块的关系是不是顺的跟进记录挂在客户还是商机下面更合适统计看板应该展示哪些指标。这些问题看代码比看文档快因为代码是经过真实业务验证的最终结果。我见过不止一个团队从零画原型画到最后商机合同的关系都搞反了而开源项目里早就有一套成熟答案。另一个值得参考的是权限设计。成熟开源CRM项目一般都有完整的用户角色体系、菜单权限、数据权限实现。把这些设计抄到原型里比自己闭门造车靠谱得多。至于里面的代码写得怎么样反而没那么重要——那是开发阶段要考虑的问题。5.2 落地MVP时我推荐的技术组合原型确认后如果决定自研技术选型别追求复杂稳定最要紧。我个人的推荐组合是前端Vue 3或React选一个团队最熟的配一套现成的后台管理模板别从零搭组件库。后端Spring Boot或者Node.js优先选团队有经验的语言。数据库MySQL选InnoDB引擎业务量大了再考虑分库分表前期不用一步到位。缓存Redis用于登录态、验证码、热门数据缓存。文件存储本地磁盘或对象存储上传头像、导入Excel用得上。用这套组合小团队大概三到六周就能跑通一个带权限的MVP。关键是先把线索到回款的主链路跑通没必要第一版就把看板、工单、营销都做完。做CRM最忌讳的不是慢而是想一口吃成胖子。6. 原型做完了自建还是用SaaS6.1 免费CRM和自建系统的三个核心差异原型做完有人会问既然市面上有免费CRM为什么还要自己搭这个问题问得很实在我把它摊开说。免费CRM和自建系统的差异核心有三个数据归属免费CRM的数据在服务商手里哪天平台停止服务、调整收费策略你连导出数据都可能受限制。自建系统数据在自己服务器上想怎么备份怎么迁移都行。定制能力免费CRM提供的是通用配置项字段类型、审批流、报表逻辑都按标准来。自建系统想怎么改就怎么改和内部系统的接口打通也完全自主。维护成本免费CRM即开即用不用操心服务器和备份这就是“永久在线”。自建系统从服务器、数据库、备份到安全加固全要自己管人力成本是隐性的。6.2 四个问题帮你做决定怎么选我的经验是拿四个问题来判断。团队有多少人用十人以下、业务标准直接上免费CRM或轻量SaaS别折腾自建。客户数据敏感吗如果客户名单、合同价格是公司核心资产不想让第三方保管就得自建。有没有强定制需求行业特殊比如医疗、教育、工程项目审批流程和字段跟标准产品差异很大自建更合适。团队有没有人长期维护自建系统最怕做出来没人管服务器宕机、漏洞修复、功能迭代全要有人跟没人维护的系统三个月就废。免费CRM和自建的本质其实是用数据自主权换时间和成本还是用维护成本换数据自主权。没有绝对的对错只有合不合适。原型方案如果只是给几十人的销售团队做日常管理先租后自建也是一条可行路子用免费CRM试跑半年攒够真实需求再拿我前面这套原型去自研效率会高很多。最后分享一个我做原型阶段摸索出来的小技巧所有原型页面上的字段名从第一天就用拟定的数据库字段名对齐。比如客户名称到底叫“客户名称”还是“客户全称”联系人电话是“手机号”还是“电话”这些细节在原型阶段统一好后面开发少掉一层翻译成本评审会上也不会因为叫法不一致来回扯皮。做CRM原型的整个过程最怕的不是不会画图而是把原型当成画图。先把业务对象、状态流转、字段权限想透你画出来的每一页才真正站得住。本文还有配套的精品资源点击获取