销售总撞单、跟进全靠记忆？中小企业CRM销售管理 5 大痛点的系统化解法

📦 源码1：ruoyi-office-vben |📦 源码2：ruoyi-office |📦 源码3：ruoyi-office

“为什么我们公司两个销售同时在跟同一家客户，客户都打电话来抱怨了我才知道？”“王总，您让我看看本月销售业绩——稍等啊，我让小张拉个 Excel。”“老板，我们家小李上周离职了，他名下那 80 个客户……手机号还在他个人微信里。”“签了 500 万合同的客户三个月没回款了，财务才发现”——这些场景对销售总监来说太熟悉。问题的根本不是"销售不努力"，而是没有系统化的工具去管销售这件事。本文从一位销售总监的真实一天讲起，拆解中小企业销售管理的 5 大痛点和系统化解法，给出可落地的实施清单与开源参考实现。

sales-pain-solution-compare.png

▲ 销售团队管理 5 大痛点 vs 数字化解法对照：客户撞单、跟进黑盒、离职带走、回款失控、报表手工 —— RuoYi Office CRM 全方位对症下药

引言：一位销售总监的真实一天

让我们跟随某中小企业销售总监老李的一天：

8:50 — 进公司，第一件事是打开 Excel “客户分配表 V12_final_最终版.xlsx”。

9:20 — 客户王总打电话：“你们公司怎么有三个人给我打电话？是不是同时三个人在跟我？” 老李脸上一阵热——明显的撞单。

11:00 — 跟小张确认昨天去拜访的客户进展。小张支支吾吾："这个……我记得是聊到方案了，他说下周再谈。"具体什么时间？什么方案？老李问不出细节。

14:30 — HR 通知老李："小李递了辞呈，下周离职。"老李一惊——小李名下还有 80 个客户、12 个商机、3 份未签合同，怎么交接？

17:00 — CFO 在群里 @老李：“上周到期的 50 万应收账款怎么还没收到？” 老李一查，原来计划本周三回款，他根本没盯。

18:00 — 老板让老李"周五下班前把本月销售业绩出一下"。老李加班到 22 点，从 5 个销售那里拉 Excel，对了 4 个小时才汇总完。

总监老李的一天反映出 5 个典型痛点。 每一个都不是个例，是中小企业销售管理的"普遍病"。系统化的解法是什么？我们一个个看。

痛点一：客户撞单——两个销售跟同一家客户

1.1 现象与代价

最常见的场景：A 销售刚加了客户微信，B 销售也接到客户介绍准备开发。两人都不知道对方在跟同一家客户，最后客户问"你们公司怎么好几个人联系我"——专业形象大打折扣。

代价：

  • 撞单导致内耗（销售互相争夺，影响团队氛围）
  • 客户信任受损（“这家公司管理混乱”）
  • 重复开发成本（两个销售的时间都浪费在同一个客户上）

1.2 系统化解法：客户公海 + 唯一负责人

把所有客户放在一个"公海池"里，任何客户必须有且只有一个负责人。其他销售看不到这个客户，自然就不会撞。

关键机制：

机制 作用
公海 未分配客户统一池，谁都看不到细节，但能看到"客户名 + 一句话简介"
唯一负责人 owner_user_id 字段，全表唯一
领取制度 销售从公海"领"客户，领走即负责人锁定
客户名查重 新建客户时按名称查重，存在重名提示
拥有上限 限制单个销售最多领多少客户，防囤积
数据权限 销售只能看自己负责的，从查询源头就隔离

1.3 RuoYi Office 的实现

// 数据权限注解：销售调用 getCustomer 时，AOP 自动校验"是不是这个客户的负责人或被授权"
@CrmPermission(bizType = CrmBizTypeEnum.CRM_CUSTOMER,
        bizId = "#id", level = CrmPermissionLevelEnum.READ)
public CrmCustomerDO getCustomer(Long id) {
    return customerMapper.selectById(id);
}

// 拥有上限校验
private void validateCustomerExceedOwnerLimit(Long userId, int newCount) {
    List<CrmCustomerLimitConfigDO> limitConfigs = ...;
    Long ownerCount = customerMapper.selectCountByDealStatusAndOwnerUserId(null, userId);
    limitConfigs.forEach(config -> {
        if (ownerCount + newCount > config.getMaxCount()) {
            throw exception(CUSTOMER_OWNER_EXCEED_LIMIT);
        }
    });
}

image.png

落地效果：撞单从制度上消失。客户进来之前公海里"占个坑"，谁先领走谁负责；其他销售在公海看到这个客户已被领走，自动让位。

痛点二：跟进全靠记忆——老板不知道销售在干啥

2.1 现象与代价

销售今天去拜访了谁、聊到哪一步、下次什么时候联系——这些信息只在销售自己脑子里。如果销售自己忘了，客户就被丢了。老板想问进展，得到的永远是"在跟"、“在聊”、“在推进”，没有任何可量化的状态。

代价：

  • 跟进失败率高（销售自己忘了下次联系）
  • 老板无法管理（看不到团队真实进度）
  • 客户被晾着（销售人少时根本盯不住几十个客户）
  • 销售离职时无法交接

2.2 系统化解法：跟进记录留痕 + 下次联系提醒

每一次客户沟通（电话/拜访/微信/邮件）都必须在系统里留一条记录。系统按"下次联系时间"自动提醒销售去跟进。

关键机制：

机制 作用
跟进记录 每次沟通记一条：类型/内容/下次联系时间/附件
下次联系提醒 contact_next_time 字段 + 列表筛选/角标
跟进状态 follow_up_status 区分"在跟进"和"已停滞"
最后跟进时间 一目了然看到客户最后被联系的时间
关联商机/联系人 跟进可同时关联多个商机和联系人
多态设计 同一张跟进表既能记客户也能记联系人/商机

2.3 RuoYi Office 的实现

跟进记录用 bizType + bizId 多态关联：

@TableName("crm_follow_up_record")
public class CrmFollowUpRecordDO extends BaseDO {
    private Long id;
    private Integer bizType; // 类型：客户/联系人/商机
    private Long bizId;      // 关联的对象 ID
    private Integer type;    // 跟进方式：电话/拜访/微信/邮件...
    private String content;
    private LocalDateTime nextTime; // 下次联系时间
    @TableField(typeHandler = JacksonTypeHandler.class)
    private List<String> picUrls;
    @TableField(typeHandler = JacksonTypeHandler.class)
    private List<String> fileUrls;
    @TableField(typeHandler = JacksonTypeHandler.class)
    private List<Long> businessIds; // 关联多个商机
    @TableField(typeHandler = JacksonTypeHandler.class)
    private List<Long> contactIds;  // 关联多个联系人
}

提交跟进时，自动回写客户主表的最后跟进时间和下次联系时间：

public Long createFollowUpRecord(CrmFollowUpRecordSaveReqVO reqVO) {
    // 1. 保存跟进记录
    CrmFollowUpRecordDO record = ...;
    followUpRecordMapper.insert(record);
    // 2. 回写客户主表（如果是跟进客户）
    if (CrmBizTypeEnum.CRM_CUSTOMER.getType().equals(reqVO.getBizType())) {
        customerService.updateCustomerFollowUp(reqVO.getBizId(),
                LocalDateTime.now(), reqVO.getNextTime());
    }
    return record.getId();
}

image.png

落地效果：每个销售每天打开系统看到"今天该联系的客户"列表，下次联系时间到点自动提示。客户跟进进度对老板透明，团队管理从"靠喊"变成"看数据"。

痛点三：离职带走客户——80 个客户怎么交接

3.1 现象与代价

销售离职是中小企业最大的隐性损失。如果客户信息只在销售个人手机里（微信、电话、Excel）：

代价：

  • 客户资源直接流失（销售可能去竞争对手公司）
  • 跟进历史全部断档（新接手的销售完全不知道之前聊到哪）
  • 商机/合同无人继续推进
  • 应收账款可能因责任人变更被拖延

3.2 系统化解法：负责人一键转移 + 连带迁移

销售离职前/调岗时，由主管一键把客户和其所有关联业务（联系人/商机/合同/回款）转移给新负责人。

关键机制：

机制 作用
一键转移 操作员勾选客户 + 新负责人，一次性完成
连带迁移 可选"是否带走联系人/商机/合同"，避免孤儿数据
拥有上限校验 转移时校验新负责人不超过上限
数据权限自动迁移 旧的 OWNER 权限删除，新的 OWNER 权限创建
操作日志 谁在什么时间把谁的客户转给了谁，全程留痕
批量转移 离职场景一次转 80 个客户，几秒搞定

3.3 RuoYi Office 的实现

@Transactional(rollbackFor = Exception.class)
@CrmPermission(bizType = CrmBizTypeEnum.CRM_CUSTOMER, bizId = "#reqVO.id",
        level = CrmPermissionLevelEnum.OWNER)
@LogRecord(type = CRM_CUSTOMER_TYPE, subType = CRM_CUSTOMER_TRANSFER_SUB_TYPE,
        bizNo = "{{#reqVO.id}}", success = CRM_CUSTOMER_TRANSFER_SUCCESS)
public void transferCustomer(CrmCustomerTransferReqVO reqVO, Long userId) {
    CrmCustomerDO customer = validateCustomerExists(reqVO.getId());
    // 1. 校验新负责人是否超过拥有上限
    validateCustomerExceedOwnerLimit(reqVO.getNewOwnerUserId(), 1);
    // 2. 转移客户主体的数据权限 + 重设负责人
    permissionService.transferPermission(...);
    customerMapper.updateById(new CrmCustomerDO().setId(reqVO.getId())
            .setOwnerUserId(reqVO.getNewOwnerUserId())
            .setOwnerTime(LocalDateTime.now()));
    // 3. 按需连带转移联系人/商机/合同
    if (CollUtil.isNotEmpty(reqVO.getToBizTypes())) {
        transferRelatedBizData(reqVO, userId);
    }
}

前端交互：转移弹窗里勾选"同时转移联系人/商机/合同"复选框——一次操作把客户的"全部资产"打包给新人。

落地效果：销售离职那天，主管 30 分钟做完所有客户交接；客户跟进历史全部保留；新销售上手只需读跟进记录就能接得住业务。

痛点四：回款失控——签了合同收不到钱

4.1 现象与代价

很多企业把"签合同"等同于"收到钱"。实际上从签合同到回款的过程经常拖延：客户拖付款、销售忘了催、财务在角落等账期——最后某天 CFO 发现"上个季度应收账款堆了 800 万"。

代价：

  • 现金流紧张（小企业最致命）
  • 坏账风险（拖得越久越难收）
  • 跨部门扯皮（销售说财务不催，财务说销售不沟通）

4.2 系统化解法：回款计划 + 提醒 + 金额闸门

签合同时同步制定回款计划（按期次拆分），系统按期次自动提醒销售跟进，且每笔回款都不能超过合同总额。

关键机制：

机制 作用
回款计划 按期拆分（首付 / 分期 / 尾款），每期有计划金额和计划日
提醒预算 计划日前 N 天自动提醒销售跟进
逾期标红 到期未回款自动变"逾期"状态
金额闸门 所有回款累计（含审批中）≤ 合同总额，超额自动拦截
核销机制 实际回款关联计划，计划状态自动变"已回款"
首页角标 顶部"我的待办"显示"该提醒/已逾期"数量
回款审批 大额回款走 BPM 审批，财务确认到账

4.3 RuoYi Office 的实现

回款计划自带 remindTime 预计算字段：

// 创建计划时预计算提醒日期
if (createReqVO.getReturnTime() != null && createReqVO.getRemindDays() != null) {
    receivablePlan.setRemindTime(createReqVO.getReturnTime().minusDays(createReqVO.getRemindDays()));
}

"该提醒"查询用一条 SQL：

// 待提醒：还没回款，且 remindTime ≤ 今天
query.isNull(CrmReceivablePlanDO::getReceivableId)
     .le(CrmReceivablePlanDO::getRemindTime, beginOfToday);

金额闸门校验：

private void validateReceivablePriceExceedsLimit(CrmReceivableSaveReqVO reqVO) {
    CrmContractDO contract = contractService.validateContract(reqVO.getContractId());
    List<CrmReceivableDO> receivables = receivableMapper.selectListByContractIdAndStatus(
            reqVO.getContractId(),
            Arrays.asList(CrmAuditStatusEnum.APPROVE.getStatus(),
                          CrmAuditStatusEnum.PROCESS.getStatus()));
    BigDecimal notReceivablePrice = contract.getTotalPrice().subtract(
            CollectionUtils.getSumValue(receivables, CrmReceivableDO::getPrice,
                                        BigDecimal::add, BigDecimal.ZERO));
    if (reqVO.getPrice().compareTo(notReceivablePrice) > 0) {
        throw exception(RECEIVABLE_CREATE_FAIL_PRICE_EXCEEDS_LIMIT, notReceivablePrice);
    }
}

落地效果：销售每天打开系统就看到"今天该收哪几笔款"，到期前自动提醒；财务从"事后追账"变成"提前盯账"；金额闸门防止操作失误超额回款。

痛点五：报表手工汇总——月底加班拉数据

5.1 现象与代价

销售总监最痛苦的事——每月汇报。从 5 个销售那里收 Excel，口径不一、数字对不上、销售为了好看而美化数据。报表滞后失真，老板拍板的依据都是"半个月前的数字"。

代价：

  • 决策滞后（数据是月底的，机会是日常的）
  • 数字失真（手工汇总难免错漏）
  • 团队疲惫（销售总监+助理花一周做报表）
  • 不能即时干预（销售掉进度，等月底报表才发现）

5.2 系统化解法：数据权限 + 实时看板 + 漏斗预测

老板/销售总监按"管理范围"实时看到团队数据：销售漏斗、本月签约、本月回款、客户分布、跟进活跃度——全部实时计算，且按数据权限自动隔离（销售只看自己的，总监看团队的）。

关键机制：

机制 作用
数据权限 销售/主管/老板各看各的，自动隔离
销售漏斗 按阶段统计商机数量与金额，预测下季度
赢单率加权 每个阶段配 percent，加权预测预期收入
看板大屏 本月签约金额 / 回款 / 商机 Top 排行
逾期角标 逾期回款数量在顶部 Badge 实时显示
导出留档 任意维度一键导出 Excel 存档
数据自助查询 不用销售总监收 Excel，老板自己点开就看到

5.3 RuoYi Office 的实现

数据权限框架（@DataPermission + 5 种数据范围）自动让老板和销售看到不同范围的数据，本质就是 SQL 自动改写：

-- 销售（SELF）：只看自己的
SELECT * FROM crm_business
  WHERE deleted = 0
    AND owner_user_id = 100

-- 销售总监（DEPT_AND_CHILD）：看本部门及以下
SELECT * FROM crm_business
  WHERE deleted = 0
    AND dept_id IN (10, 11, 12)

-- 老板（ALL）：看全部
SELECT * FROM crm_business
  WHERE deleted = 0

加权销售预测（按阶段赢单率算）：

SELECT
  SUM(b.total_price * s.percent / 100) AS predicted_revenue
FROM crm_business b
LEFT JOIN crm_business_status s ON s.id = b.status_id
WHERE b.end_status IS NULL -- 未结束的商机
  AND b.deleted = 0

落地效果：销售总监月底报表从 2 天压缩到 5 分钟（直接截图看板）；老板随时看到团队真实进度；销售掉进度当天就被识别。

实施清单：如何把这套体系落地

如果你是销售总监或技术负责人，建议按以下顺序实施：

阶段 周期 关键动作
阶段一：客户主数据归集 1-2 周 Excel 客户表导入系统、建客户公海、设置查重规则
阶段二：跟进记录养成 1 个月 强制销售每次沟通记跟进、设置下次联系时间提醒
阶段三：商机漏斗 1 个月 定义销售阶段（如 5 段漏斗）、配每个阶段赢单率
阶段四：合同/回款管理 1-2 个月 把合同台账迁入系统、配置回款计划与提醒
阶段五：数据权限 + 看板 1 周 配置 5 种数据范围、上线销售看板
阶段六：持续优化 长期 季度复盘流失率、跟进活跃度、漏斗转化率

实施关键：

  • 不要等"完美方案"——边用边调，先把客户主数据归集到系统，后续再丰富
  • 强制执行优于自愿——跟进记录、下次联系时间设为必填，否则一定会走样
  • 管理层先用起来——销售总监每天在系统里看数据，团队才会跟着用
  • 不追求一次性大改造——分阶段实施，每个阶段都能拿出来给老板看价值

RuoYi Office CRM：参考实现

如果你想要一套开源、可二开、Java/Vue 技术栈的销售管理系统，可以直接参考 RuoYi Office CRM——上述 5 个痛点的解法在源码里都有完整实现：

痛点 RuoYi Office 实现位置
客户撞单 yudao-module-crm/.../customer/ 公海 + 拥有上限 + 数据权限
跟进黑盒 yudao-module-crm/.../followup/ 多态跟进记录 + 下次联系提醒
离职带走 transferCustomer 一键转移 + 连带迁移
回款失控 yudao-module-crm/.../receivable/ 计划 + 提醒 + 金额闸门
报表手工 @DataPermission 框架 + 内置销售统计接口

技术栈：Spring Boot 3.5 + Vue3 + Vben Admin 5 + Flowable + MyBatis-Plus，国产化全适配（达梦/人大金仓/企微/钉钉），多租户 SaaS 支持。

快速体验

  • 在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）
  • 操作路径：登录后台 → 顶部菜单 CRM
  • 推荐体验流程：
    1. 客户管理 体验公海机制 → 领取 → 转移 → 拥有上限拦截
    2. 客户详情 写一条跟进记录，设下次联系时间，看角标
    3. 商机管理 推进商机阶段，看漏斗
    4. 合同管理 新建合同走 BPM 审批
    5. 回款计划 拆 3 期，制造一个超额回款看金额闸门拦截
    6. 用不同角色账号登录（销售/主管/管理员），看数据权限自动隔离效果

源码仓库：

仓库 地址
后端（GitCode） https://gitcode.com/zhouzhongyan/ruoyi-office.git
前端（GitCode） https://gitcode.com/zhouzhongyan/ruoyi-office-vben.git
后端（GitHub） https://github.com/yuqing2026/ruoyi-office.git

结语

销售管理的本质，是把"凭感觉、靠记忆、拼人情"的传统模式升级为数据驱动、流程闭环、信息透明的现代化模式。撞单、跟进黑盒、离职带走、回款失控、报表手工——这 5 大痛点不是销售团队的问题，是缺乏系统化工具的问题。

一套合格的销售管理系统应该回答这几个问题：

  • 客户是谁的？ → 公海 + 唯一负责人 + 数据权限
  • 进展到哪了？ → 跟进记录 + 销售漏斗 + 实时看板
  • 离职怎么办？ → 一键转移 + 连带迁移 + 操作日志
  • 钱什么时候到？ → 回款计划 + 提醒 + 金额闸门
  • 业绩怎么样？ → 数据权限 + 实时看板 + 加权预测

你们公司在销售管理上踩过哪些坑？用什么工具/方法解决的？欢迎评论区分享。

常见问题（FAQ）

中小企业有必要上 CRM 系统吗？

有。临界点不是公司规模，而是销售人数：当销售 ≥ 3 人，必然会出现"我跟你的客户撞了""老板看不到团队进度"这类问题——Excel 解决不了。3-10 人销售团队是上 CRM 的最佳时机，越早建立规范越好。

销售抵触用系统怎么办？

两个关键：①管理层先用起来——销售总监每天在系统看数据，团队才会跟着用；②把"必填"和"激励"挂钩——跟进记录、下次联系时间必填，跟进活跃度计入月度评分。强制执行 1-2 个月就能养成习惯。

自建开源 CRM vs 买 SaaS 怎么选？

看三个因素：①数据私有化要求——自建占优；②定制深度——自建占优；③初期投入——SaaS 低。建议中小企业初期用 SaaS 验证业务流程，业务稳定且需深度定制后再迁移到开源 CRM（如 RuoYi Office）做自建。

客户公海机制销售会不会反对？

开始可能有，但只要规则透明（“长期不跟进自动收回”)，销售反而会更专注——逼着自己在能力范围内深耕几十个客户，而不是"占着但不跟进"。配合"拥有上限"防囤积，公海最终是双赢机制。

一套销售管理系统通常需要多少功能？

核心 7 个：客户、联系人、线索、商机、合同、回款、跟进记录。加上 3 个支撑：数据权限、操作日志、销售看板。再加上 2 个增强：客户公海、回款计划。共 12 个模块。本文提到的 RuoYi Office CRM 这 12 个全部完整实现，开箱即用。

💡 想要体验 RuoYi Office 的强大功能？

🌐 在线演示：http://ruoyioffice.com/web/（账号 admin / admin123）

📦 源码仓库：GitCode | GitHub

💬 技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果觉得不错，请给个 Star 支持一下！
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

海外动态代理行业彻底换代，AI 数据时代新标准已到来

avatar AtomGit开源社区
cover

2026年论文写作AI哪个好用？7款工具实测对比，轻松拿捏

avatar AtomGit开源社区
cover

2026年SEO+GEO优化指南：搜索排名机制解析与实用工具推荐

avatar AtomGit开源社区