简介这是一份基于Angular 10.1.7与Bootstrap生成的CRM客户管理前端项目面向正在学习TypeScript、组件化开发以及前后端模拟联调的初中级开发者。项目自带模拟服务器用于模拟后端接口前端实现了添加客户、列表展示、编辑与删除等完整的增删改查操作代码目录按Angular标准组织便于读者理解组件、服务、路由与样式之间的协作方式。压缩包共70个文件包含29个TypeScript源文件、11个HTML模板、10个JSON配置与模拟数据、8个CSS样式等整体仅2.35MB轻量且结构完整适合直接运行或二次改造。同时项目包含了环境配置、构建脚本等辅助内容可帮助初学者省去繁琐的搭建流程。目前已有153人学习浏览可作为一个清晰、可上手的CRM项目范例帮助读者快速掌握Angular项目从搭建到联调的关键流程。 这几年帮传统企业落地过不少CRM项目有个感受特别深很多人一开始以为CRM就是装个软件、录点客户、看个报表结果真正推进下去才发现它本质上是在给整个公司的销售体系“做一次手术”。客户怎么分、商机怎么跟、回款怎么盯、销售之间怎么协作全都要在系统里重新理一遍。这篇文章不聊那些标准产品手册上的废话就从我实际做过的一个典型CRM项目出发讲讲从需求拆解、方案选型、数据结构设计到二次开发上线的完整思路以及那些文档里不会写的坑。准备自己搭CRM的团队、做企业数字化选型的同学甚至纯好奇CRM到底是什么的人都可以读一读。1. 先想清楚CRM项目到底在解决什么问题1.1 销售管理里的真需求不是“有个系统就行”很多团队在提需求时只会说“我们要一个客户管理系统”。这句话等于没说。CRM这个词在大大小小的企业里已经被用滥了有人把它当通讯录有人把它当订单本还有人觉得它是一个“永远在线的网站”——点开就能看客户仅此而已。我在项目启动前一般会先做一件事蹲在销售旁边看他们工作一天。目的很简单搞清楚一个销售从早上拿到线索到晚上写日报中间真正痛苦的点在哪里。有的公司痛点是客户都躺在销售个人的微信和Excel里老板看不到全盘有的公司痛点是商机明明跟了好几个月却说不清楚卡在哪个环节还有的公司更基础连客户、联系人、合同这三样东西的关系都没理明白。所以CRM项目的第一步不是买软件而是把业务链路画出来。线索从哪来谁去跟进跟进到什么样的客户要转给谁成单以后谁负责首访、谁负责续费每一个角色在系统里该有什么权限这些才是需求的核心。拿我做的那个项目举例他们卖的是B2B的软件服务销售周期平均3个月一个单子至少涉及销售、售前、实施三拨人如果不先理清这条链路后面所有的配置都是空转。再往细里说还要区分你到底是B2B还是B2C的业务两者在CRM里的设计逻辑差别很大。B2B侧重商机阶段管理和决策链梳理B2C侧重线索池自动分配和会员生命周期运营。一个简单的对比可以看出来维度B2B场景B2C场景决策周期长通常数周到数月短可能当天就下单核心对象客户联系人商机线索会员订单关键流程商机阶段推进、合同审批线索自动分配、营销触达数据量级客户量相对少字段复杂用户量大行为数据多权限复杂度高需要按事业部/区域隔离中通常按运营角色区分1.2 一个不痛不痒的CRM往往死在需求没对齐我接手过不止一个“还没上线就注定被弃用”的CRM项目共性都是业务方和高层根本没对齐。高层想要的是全局看板、业绩预测一线销售想要的是少填点表、别没事就换系统。这两个目标其实不冲突但如果你在需求阶段不做取舍最后做出来的系统就会非常割裂。这个项目的做法是先和高层定了三件必须实现的事销售漏斗实时可见、客户数据归属清晰、回款与合同强关联。这三个目标直接决定了数据模型的复杂度和页面设计的优先级。比如销售漏斗实时可见意味着商机表必须设计阶段字段而且每个阶段的推进要有时间戳客户数据归属清晰意味着从线索进入系统的那一刻开始就要有明确的分配逻辑和转移记录回款与合同强关联意味着合同不是一张图片挂在附件里而是要拆成订单行、计划回款日期、实际回款金额等结构化数据。所以说需求拆解这一步最忌讳的是让研发直接上来画页面。我的习惯是先写一版业务蓝图里面只有角色清单、流程描述、核心字段这三样业务方在这个基础上签字确认后面才不会扯皮。2. 方案选型的底层逻辑免费SaaS、开源系统还是自研2.1 免费CRM和自建系统之间的账不能只看价格热词里有一条“免费crm与私人网站的区别在哪”这其实很多人问过。市面上的免费CRM大多是把付费版的功能砍掉一部分比如限制账号数量、限制自定义字段数、报表模板固定然后通过引导升级的路径来转化付费用户。这类产品的优势是开箱即用、移动端适配好、服务商帮你维护不用操心服务器和安全补丁适合团队规模不大、业务流程标准、不想养技术团队的公司。但它的隐性成本体现在三个地方一是数据在别人平台上导出限制多想离开时要转换数据非常痛苦二是自定义能力有限你只能做平台允许范围内的配置稍微特殊一点的流程就做不了三是免费版通常不带完整的数据看板或API接口等业务跑起来想对接企业微信、钉钉或者自己的财务系统时会发现被卡得很难受。自建或基于开源系统二次开发前期投入确实大需要设计、开发、部署、运维但胜在控制权完全在自己手里。我这次选型时把国内几款常见的开源CRM源码都翻过一遍最终选定了芋道CRM这套基于Java技术栈的体系主要原因是它在权限管理和模块扩展性上做得比较扎实而且社区活跃度不错遇到问题能找到人问。2.2 选型评估表直接照着做就行选型这种事主观判断容易翻车我习惯把维度量化打一个综合分再决定。下面是这个项目实际用过的评估表可以当成模板抄评估维度免费商业SaaS开源系统自部署完全自研初期成本低中服务器人力高上线速度快1~2周中1~3个月慢半年以上流程定制能力弱受平台限制中强源码在手最强数据控制权弱托管在厂商强数据在自己服务器强运维成本低中高需自己处理安全/备份高适合场景初创/标准化流程有开发团队、流程特殊大厂/极致个性化最后定下来的方案是开源CRM打底做二次开发。理由很简单这个项目在客户字段、审批流、报表口径上都有特殊要求SaaS管不住自研又没必要从零开始。还有一个考虑是“永久在线”这一点商业SaaS靠厂商保障在线率自部署就得自己保证服务器稳定。但自部署有一点好网络环境完全可控响应速度、数据备份策略都能自己控制这对数据敏感的行业来说很关键。3. 落地前的四张图纸数据、权限、流程与仪表盘设计3.1 数据模型先画实体关系再讨论页面做CRM最容易出现的问题就是上来就建表客户表、订单表、回访表结果表建完了才发现关联关系一塌糊涂。我习惯在第一周只做数据建模这一件事。拿这个项目来说核心实体包括线索、客户、联系人、商机、合同、回款计划、回款记录、售后工单。它们的逻辑关系是这样串联的——线索经过电话沟通、确认意向后转化为客户客户下面挂多个联系人商机针对某个客户及其关键联系人展开商机推进到一定阶段后创建合同合同关联回款计划和实际回款记录交付后产生的服务问题进入售后工单。这套关系看着标准真正建模型的时候还是有很多细节要注意。比如客户和联系人是一对多但商机和联系人之间的关系不是简单的谁创建谁负责而是要记录“这个商机里哪个联系人起决策作用”所以中间关系表里要有角色字段。再比如回款计划和回款记录要分开因为一笔回款可能对应多个计划如果不拆财务对账时会崩溃。这些细节在页面阶段几乎不可能发现只有在数据模型评审时才会暴露。3.2 权限设计管不好权限的CRM上了线就要出事权限是CRM项目里最容易被低估的模块尤其是数据行级权限。我见过一个项目销售能看到全公司所有客户的手机号结果不到一个季度就出事了。好的权限设计至少要拆成三个层面——菜单权限、按钮权限、数据范围权限。菜单和按钮都好理解数据范围才是重点它决定了某个角色打开客户列表时能看见的是本人名下、本部门名下还是全公司的数据。这个项目的权限模型按“角色部门数据范围”三层来配。销售角色默认数据范围是“仅本人”销售总监是“本部门”老板和财务是“全部”。听上去不复杂但部署二次开发时你会遇到很多真实场景比如销售离职了他名下的客户要批量转给主管比如一个客户同时被两个事业部的销售跟进怎么做数据隔离又不挡协作。这些规则必须在前期就定义好否则后期补非常痛苦。3.3 流程自动化商机阶段和回款提醒先做起来流程自动化的优先级排序也很重要尽量不要一上来就搞很复杂的多级审批流。我把这个项目的自动化拆成了三个等级。第一级是必做项线索重复校验、线索转客户、商机阶段变更、回款日到期提醒。第二级是加分项一次性客户超过30天未跟进自动回收、合同到期前30天提醒续费。第三级是理想项销售日报自动生成、业绩预测模型。这里给一个例子线索转客户的判定规则可以这样定一线索在“已联系”状态下且有效通话时长超过90秒或填写了明确的意向产品则系统自动推荐转客户。这种规则看起来很简单但能让销售少点很多次鼠标。回款提醒则是根据合同的“计划回款日期”字段提前3天、1天分别推送待办给对应的销售和财务角色。所有自动化规则都要有开关因为在系统上线初期业务方往往还没适应节奏规则太激进容易引起反弹。3.4 仪表盘设计指标口径不定看板就是摆设很多CRM系统上线后最热闹的就是首页的销售排行榜但真正对管理有价值的是漏斗转化率和回款健康度。这里要特别注意指标口径的统一。比如商机转化率有人按“成交商机数除以全部商机数”算有人按“成交金额除以商机总金额”算两种算法得出的数字天差地别。再比如销售漏斗从“新建商机”到“赢单”要经过几个阶段每个阶段的进入条件和退出条件必须定义清楚否则报表里的数字是乱的。我在这个项目里对核心指标做了明确约定。商机转化率等于阶段为“成交关闭”的商机数除以阶段为“有效商机”之后的商机总数回款逾期率等于逾期未回款金额除以应回款总额平均回款周期则按每笔回款的实际日期减去合同签署日期来算。这些口径不写清楚后面报表开发出来也没人敢信。4. 从源码到可用的二次开发实战4.1 环境部署与基础配置别在这省时间开源CRM的部署流程大同小异。我以芋道CRM为例它典型的部署环境是Linux服务器加MySQL加Redis加JDK前端是Vue后端是Spring Boot。第一次跑通的过程其实不难但有几个配置不处理好后面会很麻烦。数据库字符集必须设为utf8mb4不然后续存客户备注里的表情符号会直接报错定时任务必须配好因为回款提醒、线索回收这些功能都要靠它驱动Redis的过期策略要盯一下会话超时、短信验证码都依赖它。有一点要特别提醒部署前把默认的管理员密码改掉并把初始化的演示数据清空。很多团队图省事直接在演示数据的基础上改结果上线后客户名单里还有一堆“测试科技有限公司”看着非常业余。4.2 给客户表扩展自定义字段的完整过程业务方提得最多的一类需求是“我要加一个字段”。在开源系统里这通常不是改数据库那么简单而是要遵循框架的规范。我举一个实际做过的例子这个项目需要给客户表加一个“客户行业细分”字段下拉选项包括制造业、互联网、医疗、教育、其他。第一步是数据库加字段用一条ALTER语句就能解决。代码大概是这样的ALTER TABLE customer ADD COLUMN industry_detail VARCHAR(50) NULL COMMENT 客户行业细分;第二步是在后端实体类中增加属性。第三步是在前端新增页面的表单组件里挂一个下拉选择框编辑页和详情页都要同步处理。第四步是配置导出模板因为销售习惯把数据导出来再整理如果导出Excel里没有这个字段他们会觉得系统“没有加成功”。整个过程看着不难但有个坑权限模板里如果做了列表字段的动态显隐新加的字段默认是隐藏的必须去菜单管理的字段配置里面勾选后才能被普通账号看到。这个环节如果漏了就会出现管理员能看到字段销售看不到然后开始互相甩锅的现象。4.3 二次开发加一个“报价单”模块的最小步骤再往深一点如果业务要求加一个全新模块流程就复杂一些。这个项目后来加了一个报价单模块因为销售反馈客户经常要求先出报价方案再走合同流程。我们基于框架的代码生成器先创建了数据库表然后在controller、service、mapper、前端页面各层生成CRUD代码接着把报价单通过“客户ID”和“商机ID”两个字段挂到原有的客户详情页和商机详情页里。这里想强调一个经验新模块上线前一定要在测试环境完整走一遍“创建报价单、关联商机、导出PDF、生成合同”全流程别只看单模块通不通。我们当时就是没做联调导致报价单只能创建和查看点“关联生成合同”直接接口报错原因是合同模块的数据权限校验里没有把报价单的编号列进去找了一下午才发现。所以新增模块一定要顺手检查它和已有模块之间的权限关系。5. 上线后最常踩的5个坑与排查记录5.1 销售说“系统慢”先看数据库索引别急着加服务器上线第一周业务方反馈客户列表越翻越慢尤其按负责人筛选时有时要等五六秒才出结果。第一反应可能是服务器性能不够但实际上排查后发现客户表的数据量还不到二十万条问题是查询条件里的“owner_user_id”和“update_time”字段没有走索引导致每次查询都在做全表扫描。解决办法很简单给高频查询字段加上组合索引。加完索引后同样的接口从5秒多降到了200毫秒以内。这里也可以分享一个经验数据分析类的筛选页面凡是表格列表里可以排序和过滤的字段都应该考虑建索引但不是所有字段都要建不然写入性能会受影响。5.2 客户数据重复导入脏数据比垃圾代码更可怕系统上线前导入了销售手里积累的老客户Excel。当时只做了“客户名称完全一致”的判重导完以后发现有些客户在系统里出现了两条——“某某科技有限公司”和“某某科技股份有限公司”其实是一家。当时没太在意后来销售做统计时发现数据怎么都对不上才意识到约10%的数据是重复的完全打乱了客户归属。后续我补了一个清洗脚本把客户名称里的“有限公司”“股份有限公司”“中国”等常见后缀归一化以后再比较并把匹配阈值调低了一些加上联系人手机号二次确认才算把存量数据洗干净。从那以后所有导入操作都先跑一遍清洗规则并生成重复报告给管理员确认允许人工合并到主数据不准直接落库。5.3 权限越权问题经常出在自定义接口上开源系统自带的菜单权限和数据权限做得挺完善但二次开发的接口很容易漏配权限校验。漏配的结果是一个普通销售通过接口拼接参数可以直接查询到其他部门客户的合同数据。这不是危言耸听业内有不少项目的安全问题就是这么来的。排查方法很简单也很暴力把系统的所有API接口列出来逐个用低权限账号访问一遍看哪些接口没有做数据范围过滤。对二开模块而言最好一开始就在Service层设计好校验逻辑不要在Controller层简单写死一个“当前登录用户ID”而是把查询条件拼进SQL的数据权限组件里让框架统一控制。5.4 流程节点卡住没人处理要设计超时提醒商机审批、合同审批这类多级流程经常会卡在某个节点上原因是审批人出差或者压根没注意待办。上线第一个月有笔合同在“销售总监审批”节点卡了两天导致客户打电话投诉财务合同迟迟不下发。后来我们在工作流配置里加了超时策略超过12小时未审批自动通过企业微信推送提醒给审批人超过24小时仍未处理系统自动在自己的上级待办里生成一条督办记录。同时给每个审批节点配置了代理审批人一旦节点负责人请假可以临时转移审批权限。这种兜底机制不是核心功能但非常影响业务方对系统的满意度。5.5 报表数据对不上大概率是时间范围和状态口径问题业务方拿着系统里的销售漏斗和财务那边的收款总额来对比发现两边总是差几万块钱。排查了很久发现原因是系统报表里“本月成交金额”按的是合同签署日期“财务回款统计”按的是实际到账日期两者天然存在时间差。另外合同有“已签署”、“已作废”、“履约中”、“已完成”等多个状态报表默认只统计“已签署”和“履约中”但财务那边统计时没有排除已作废合同。这就回到了前面说的指标口径问题。出现这种情况不要先去改代码而是先和业务方把每个指标的定义确认一致再把口径写进报表配置里最后才动手改查询逻辑。口径不一致越改越乱。做CRM项目这些年我最大的体会是系统上线不是终点而是销售管理走向透明的起点。技术选型、数据模型、权限配置、流程自动化这些在项目初期做得越扎实后续的业务调整和人员迭代就越顺畅。如果让我给正在筹划CRM项目的团队一个建议那就是别追求一步到位先跑通“线索-客户-商机-合同-回款”这条主线稳定3个月后再谈营销自动化和数据预测。现在省钱省掉的调研和设计时间后面都会以另一种方式补回来而且代价通常更高。本文还有配套的精品资源点击获取
