简介：一份基于 Angular 10.1.7 与 Bootstrap 的 CRM 客户管理项目源码，面向正在学习 TypeScript 和前端工程化开发的读者。项目围绕客户信息管理场景，实现了添加客户、列表展示、编辑与删除等基础功能，并借助 mock 服务模拟后端接口，使前端无需真实服务端即可独立运行调试，便于理解数据交互链路。压缩包共收录 70 个文件，整体大小 2.35MB；核心代码以 29 个 TypeScript 文件为主，配合 11 个 HTML 页面模板、8 个 CSS 样式文件以及 10 个 JSON 配置文件，覆盖组件逻辑、页面结构、视觉样式与 mock 数据等多个层面，同时附带 Angular 工程常见的说明文档、编辑器配置和版本控制设置，目录结构清晰。目前已有 153 人学习浏览，适合用于课程设计、项目实训或 Angular 入门进阶参考。通过该资源，使用者可以获取完整的客户管理前端代码、Bootstrap 表单与栅格布局写法、模块组件划分方式，以及模拟后端环境搭建流程，从而掌握从页面交互、数据请求到界面更新的整套实现思路。
1. 先搞清楚：CRM到底是干什么的，不是个花架子
做了这么多年企业级系统，我见过太多把CRM项目做砸的案例。最典型的一种，就是公司花了几十万上了套CRM，结果销售该用Excel还是用Excel，管理层想看数据还是得让助理手动汇总。问题出在哪？往往不是软件不行，而是从立项那一刻起，就没想清楚CRM解决的核心问题到底是什么。
CRM（Customer Relationship Management，客户关系管理）本质上是一套围绕“客户生命周期”的信息化工具。从线索获取、跟进触达、商机推进、合同签订，到回款管理、售后服务和二次复购，它要把销售过程中所有关键节点都数字化，让“客户”不再只存在于销售个人的微信和Excel里，而是沉淀为公司资产。换句话说，CRM的核心价值不是“记录”，而是“流程管控+数据沉淀+协作提效”。
当前做CRM项目的人大致分两类。一类是企业的运营或管理者，想选型或落地一套客户管理系统；另一类是开发者，想自研或基于开源项目二次开发。这两类人的关注点完全不一样：前者关心功能是否够用、员工愿不愿意用；后者关心架构怎么设计、表怎么建、权限怎么做。这篇文章我尽量把两边都讲到，既会说清楚CRM的模块设计逻辑，也会给出技术落地层面的实操经验，包括开源方案选型、表结构设计思路、以及“免费CRM”和“自建私人网站”之间到底差在哪。
2. CRM的核心模块：哪些功能必须有，哪些可以后面再加
CRM系统看起来功能很多，但拆到底，无非是围绕“客户数据”和“销售流程”两条线展开。搞清楚这条逻辑，无论你是选型还是自研，都不会被厂商的功能清单带偏。
2.1 客户与线索管理：CRM的地基，但别把地基搞成毛坯房
客户管理是CRM最基础也最核心的模块。这里涉及两个概念要分清：线索（Lead）和客户（Customer/Account）。线索是指还没经过验证的潜在销售对象，可能来自官网留资、市场活动、业务员自行拓展；客户则是指已经确认有合作意向或已完成初步沟通的主体。很多系统把两者混在一起，结果数据一团乱麻。
在设计上，我建议的表结构要把“线索”和“客户”分开存，再通过“转换”操作把合格的线索转入客户列表。为什么要这么设计？因为它对应实际业务动作：销售接到一条线索，先判断是否有效，电话沟通确认需求后，再把它转为正式客户进入跟进阶段。这样的流程拆解，让管理层能清晰看到“线索转化率”这个关键指标。
字段设计上，除了公司名称、联系人、电话、地址这些基础信息，我强烈建议加上“客户来源”和“客户状态”。客户来源标记它是自然搜索、转介绍还是投放带过来的，这直接关系到市场部的ROI分析；客户状态则记录当前处在哪个阶段，比如初步接洽、方案确认、商务谈判、已成交、已流失。这两个字段是后续做数据透视的基础，没有它们，客户列表就只是一本通讯录，谈不上管理。
2.2 商机、合同与回款：把销售流程真正管起来，而不是记流水账
只有客户档案的CRM只能叫“电子通讯录”，真正让CRM发挥价值的是对销售流程的管理。流程管理的核心是商机（Opportunity）模块。商机代表一个具体的销售机会，它关联到某个客户，包含预计成交金额、预计成交时间、当前所处阶段、赢单率等信息，并最终推进到合同和回款。
这里最常见的做法是引入“销售漏斗”（Pipeline）的概念。漏斗的每一层对应商机的一个阶段，比如：初次沟通→需求确认→方案报价→商务谈判→赢单。系统通过商机在各个阶段的分布数量，直观反映销售预测和整体健康度。比如你看到某个月的目标是100万，而漏斗里所有商机的预计金额加一起只有30万，那这个月目标大概率完不成，管理者需要提前干预。
商机后面紧接着合同和回款。合同模块要能关联商机、生成合同编号、记录金额和签署状态；回款模块则记录每一笔应收款是否到账。我见过很多小团队做CRM时把回款省略掉，理由是“财务那边有ERP管”。但实际运营中，回款是销售最关心的指标之一，销售提成直接跟回款挂钩。如果CRM里看不到回款数据，销售就要跑财务部查Excel，协同效率一下就下来了。所以哪怕功能做得简单一点，回款模块也应该在首期就纳入范围。
2.3 数据看板和权限设计：管理层真正想要的是“一眼看清”
CRM发展到后期，数据看板是使用频率最高的页面。管理者的诉求很朴素：打开系统，就能看到今天新增了多少客户、哪些商机临近成交但迟迟没动静、哪个销售的跟进量明显偏低。这些统计不需要太复杂，但必须实时、准确、可下钻。
权限设计则是CRM项目里最容易引发矛盾的点。常见方案有三种：按公海池隔离（所有公开客户放入公共池，销售领取后进入私有池）、按数据归属隔离（每个销售只能看自己和下属的客户）、按角色分级隔离（普通销售、销售主管、销售总监各看各的层级）。我的建议是第一版先做“私有+公海+上级可见”的组合权限模型。这个模型的好处是既保护了销售的个人跟进空间，也让管理者能看到团队全貌，而且实现起来并不复杂，RBAC（基于角色的访问控制）加数据范围过滤就能搞定。
3. 免费CRM和自建“私人网站”到底怎么选：账要算全
热词里有个很有意思的问题：“免费CRM与私人网站的区别在哪”。这其实是很多小团队老板内心纠结的真实写照——一方面不想花钱，另一方面又担心免费SaaS数据不安全、功能受限制，于是考虑自己找人做个“私人网站”。这个问题我得好好拆一拆，因为两边都有不少人踩坑。
3.1 免费SaaS CRM的“免费”到底有多贵
市面上确实有不少免费CRM，比如部分厂商提供的免费版本。这些产品的逻辑很清楚：用免费版吸引你上手，等数据积累到一定程度、团队离不开它了，你再想用高级功能、扩容人数、开API接口，就得付费升级。这本身没有问题，SaaS商业模式就是这样。我要提醒的是免费版通常有几个隐含成本：
- 功能裁剪严重：很多免费版砍掉了工作流自动化、批量导入导出、自定义字段等关键功能，而这些恰恰是CRM落地中最常用的能力。
- 数据所有权风险：免费版的条款里可能包含服务方对数据的某些使用权，虽然主流厂商不会拿你的客户数据乱来，但条款细节一定要看清。
- 定制化能力为零：SaaS版的页面布局、流程设置、字段逻辑都是固定的，你只能适应它，不能让它适配你。
3.2 自建“私人网站”的真实代价，远不止服务器费用
再说自建。看到“永久在线的crm网站”“私人网站”这类描述，我判断提问者潜意识里想要的是“数据完全掌握在自己手里”的安心感。这个需求本身完全合理，但很多人低估了自建的成本结构。
自建CRM，专业说法叫“自托管”（Self-hosted），分两个路径：一是直接用开源CRM系统（比如芋道、青动这类）部署到自己的服务器上；二是不用任何现成产品，从零搭一个定制系统。前者省去了从零开发的工作量，后者开发成本极高，一般不建议小团队踩这个坑。自托管的真实代价包括：服务器费用、域名和HTTPS证书费用、数据库运维成本、备份与安全防护成本，以及后续功能迭代时开发人力成本。这些加起来，钱不一定比SaaS年费低，但换来的是数据完全自主可控，以及按自己业务逻辑定制功能的自由。
3.3 我的建议：按企业阶段和能力来选
如果你只是10人以下的销售团队，业务模式也比较标准，直接选一款成熟的免费SaaS CRM快速跑起来，性价比最高。等你跑通了流程、验证了模型，再考虑迁移到付费版本或自建，都不迟。
如果你们已经有技术团队，或者对客户数据的私密性有硬性要求，那我建议自建，但前提是务必使用开源CRM产品做底座，而不是从零写。基于开源项目二次开发的重要性在于：成熟产品已经解决了权限模型、审批流、基础报表这些通用问题，你只需要做配置和定制化，而不是连用户登录都要从零实现。热词里提到的“芋道”“青动”等开源项目我都研究过，下面单独聊一聊。
4. 开源CRM实战：基于芋道/青动这类项目落地的完整路径
这项我也直说了：热词里的“芋道CRM”“青动CRM源码”之所以被不少人搜索，核心原因是“直接拿来改”这件事，对绝大多数中小企业来说是性价比最高的技术路线。用开源CRM做底座的逻辑，跟装修用毛坯房而不是从打地基开始盖房子一样：结构性问题人家已经解决了，你要做的是挑瓷砖和定风格。
4.1 选型阶段：先看技术栈，再看业务匹配度
选型开源CRM，我建议按这个优先级考察：技术栈是否熟悉、社区是否活跃、代码结构是否清晰、是否包含你要的核心模块。
以芋道为例，它采用主流的Java技术栈（Spring Boot + Vue），模块划分清晰，权限系统做得比较完善，适合有Java开发团队的公司进行二次开发。青动这类项目则往往面向特定行业场景，代码量更小、更轻量，适合快速部署和小范围使用。选择的关键不是“谁名气大”，而是“谁的代码你们团队能hold住”。不要轻视这一点，我见过不止一个团队选了个看似功能很全但代码结构混乱的项目，最后二次开发的成本比从零写还高。
4.2 部署和初始化：环境准备、数据库导入、系统配置三步走
以芋道CRM的部署为例，实操路径大致如下。前提是你有一台Linux服务器，装了Docker和Docker Compose，这是目前最省事的部署方式。
# 1. 创建项目目录并在其中下载/克隆代码 mkdir -p /data/crm && cd /data/crm git clone https://github.com/yudao-xxx/yudao-crm.git # 2. 查看是否有docker-compose文件，编排依赖中间件 cd yudao-crm docker-compose up -d mysql redis # 3. 等待数据库启动后，初始化业务表 # 通常源码中会提供SQL脚本，先执行初始化脚本再启动后端服务 mysql -h127.0.0.1 -uroot -p < sql/ruoyi_crm_init.sql # 4. 修改后端配置文件中的数据库连接、Redis地址，然后启动后端 docker-compose up -d server # 5. 前端构建，配置Nginx反向代理，把域名指向前端静态目录 cd front npm install npm run build这里有两个特别容易踩坑的地方。第一，初始化的SQL脚本有执行顺序问题，必须先执行基础框架脚本，再执行业务模块脚本，很多新手一上来就报错，其实就是顺序搞反了。第二，Nginx的反向代理必须同时配置后端API路径（一般是/api），否则页面能打开但登录接口全部404。建议部署完成后第一时间改默认账号密码，并开启验证码登录，防止系统被扫描爆破。
4.3 二次开发的核心：定制字段和业务流程，别一上来就动核心表
系统部署好之后，最考验功力的就是二次开发了。很多开发者的第一反应是：新产品肯定要改几张核心表，加几个业务字段。我的建议完全相反：第一版业务改造，能通过系统后台配置实现的，就绝对不要改代码。
主流开源CRM都内置了自定义字段和流程设计器。比如你要给客户表加一个“客户等级”字段，优先用后台配置完成；你要调整商机阶段的名称和顺序，也应该先看系统设置里有没有参数可以改。只有当配置能力确实覆盖不了时，才考虑动代码。改代码的时候也要注意：保持基础表结构不变，用“扩展表”或“扩展字段”的方式增量加东西。这样以后系统要升级版本时，你的改动不会跟官方的新代码产生严重的合并冲突。
5. 把CRM、SRM、SCM、WMS一次讲清楚：它们根本不是一回事
热词里还有一个很有意思的现象：“sap srm。crm。scm。osat。wms。osat。wrms。。。是什么”。看得出提问者被一堆缩写搞晕了。这些系统名称确实容易混淆，我结合CRM的定位，用一个完整的业务链条把它们串起来讲。
5.1 从一份客户订单的生命周期，看每个系统各自管什么
假设你是一家制造企业的销售，刚通过CRM谈下一笔大订单。这笔订单后续怎么履行，就要看其他系统的了：
- CRM管的是“从线索到回款”的前半段：客户是谁、商机怎么推进、合同签没签、钱到没到账。
- SRM（Supplier Relationship Management，供应商关系管理）管的是供应链端：你要采购原材料，谁来供、价格多少、交期多久、质量如何，都是这里管。
- SCM（Supply Chain Management，供应链管理）管的是全链条协同：从原材料到生产到成品到交付，计划是否拉通、库存是否合理、订单履行是否顺畅。
- WMS（Warehouse Management System，仓储管理系统）管的是仓库内部动作：入库、出库、盘点、库位、批次，精确到每一件货放在哪个货架。
- MES（Manufacturing Execution System，制造执行系统）管的是车间现场：工单派给哪个产线、生产进度如何、设备状态是否正常。
把这几套系统串起来看，就是一家制造企业数字化运营的主干网络。CRM是市场与销售的入口，WMS和MES是交付的出口，SCM和SRM则是供应侧的支持。理解了这条链路，你再去跟IT部门或软件厂商沟通，就不会被缩写名词带到沟里了。
5.2 中小企业上系统的顺序建议
很多企业主问我：这些系统是不是要一次性都上了？我的回答通常是：不要。按业务痛点的优先级来排。首先上CRM，因为客户和商机是公司的命脉，这部分信息化回报最快。其次上WMS或库存管理，因为库存不准导致的损失是实实在在的。等业务规模再上一个台阶，再考虑SRM和SCM。系统的价值不在于大而全，而在于解决了当前最痛的那个问题。一次只上一个系统、把这个系统用透，比同时上五个系统最后全部搁置要明智得多。
6. 我在CRM项目里踩过的几个坑，提前说给你听
最后再分享一些项目实战中容易忽略的细节，这些在官方文档里基本不会写。
第一，CRM项目成败的关键不在技术上，而在“数据初始化”这一步。很多系统上线第一天就因为老客户数据导入问题导致销售反感。务必在上线前把所有历史客户数据清洗一遍：合并重复数据、补全关键字段、删掉明显无效的记录。导入时先在小范围试导，确认格式正确后再全量导入，这个流程不要省。
第二，登录体验直接影响使用意愿。销售团队没那么多耐心学习复杂系统，首次登录的引导页、常用功能的快捷键、移动端的适配程度，这些看起来不起眼的细节，决定了销售是天天用还是三天后弃用。我见过一个团队，仅仅是把登录页改成企业logo、把常用的“新增客户”按钮放到首页顶部显著位置，第二周的使用率就明显提升。
第三，警惕权限模型在设计时“既要又要”。有的企业想让销售看到团队所有客户，又怕销售互相抢单，于是设置复杂的字段级权限，结果销售每次打开客户详情页都要一个个看按钮是否可点。权限设计的原则应该是最小够用：先保证销售能高效干活，再考虑风控要求，不要一开始就做成“全功能但没人用”的系统。
第四，关于“永久在线”这个诉求，我的理解是大家希望系统稳定可靠、别老宕机。落到技术层面，选一个有口碑的云厂商、数据库定时备份、加个简单的监控告警，这三件事做到位，系统跑上几年不出大问题是很正常的。
CRM项目说难不难，说简单也不简单。难的地方在于它跨越了业务和技术两个领域，需要同时理解并做权衡；简单在于只要抓住了客户生命周期这条主线，所有功能模块都可以像套零件一样逐步往上加。希望这篇文章能帮打算做CRM项目的你，少走几步弯路。
本文还有配套的精品资源，点击获取
