客达天下深度解析：客源分配、线索状态机与本地部署实战

简介：面向需要实战全栈项目的开发学习者，这套「客达天下」软件资源包含Java后端与Vue前端相结合的完整代码工程，可用于理解前后端分离架构、页面交互与数据接口调用逻辑。压缩包共735个文件，以java和vue源码为主，另有js逻辑脚本、xml配置、svg图标、scss样式、sql数据库脚本及bat启动/构建脚本等，整体大小仅4.23MB，目录规划清晰，便于按模块定位代码。已有299人浏览下载，适合作为中小型管理系统项目的参考模板。从中可以获取完整的工程结构、前端图标字体资源、环境配置示例与数据库初始化文件，并借助内置构建与启动脚本快速搭建运行环境，节省手动配置时间，为二次开发或课程设计提供可复用的基础。

1. 客达天下到底是什么：一套把“客源”管起来的软件资源，不是 CRM 也不是外呼系统

第一次听说“软件资源-客达天下”的人，多半以为它是个新式 CRM，或者是个带外呼功能的营销 SaaS。但真把整套资源包拉下来部署过之后，我发现它的定位完全不同：它不替你做客户关系分析，也不帮你自动打电话，它解决的是“客源怎么进来、怎么分给销售、怎么跟进、怎么回收”这条最容易乱掉的链路。客达天下更像一台客户分配机器，核心是把客源池、分配规则、跟进状态和回收节奏串成一个闭环。适合两类人：一类是没有专职开发、又想数据不出内网的小型销售团队，另一类是被 Excel 分客源搞得心力交瘁、想彻底告别撞单和漏跟的负责人。它不花哨，但把客源管住了，成交率自然往上走。

2. 拆解客达天下的核心模块与数据流：客源池、分配引擎、跟进状态机

要驾驭一套软件资源，先得知道它的骨架在哪。客达天下这类系统，跑起来之后本质上只有四块东西：客源池负责存客户，分配引擎负责把客户交给合适的销售，跟进工作台负责让销售干活，回收任务负责处理那些被遗忘的线索。模块不多，但每一块都有约定俗成的设计方式，搞清楚它们之间的数据流向，后面部署、配置、改需求才有方向感。

2.1 三个核心模块的职责边界：为什么它敢叫“天下”

客达天下敢叫“天下”，不是因为它功能全，而是因为它把客源分配这件事做到了极致。我见过很多团队把客户数据塞在一张 Excel 表里，谁想跟就跟，结果就是老销售手里压着几百条不跟的线索，新人手上没客户练手。客达天下的做法是从结构上切断这种混乱。

这四个模块之间是单向依赖的：客源池只提供数据，分配引擎只读客源池、写分配日志，跟进工作台只操作分配给自己的线索，回收任务扫描的是“最近一条跟进时间”。谁都不越权，数据才不会乱。这跟传统 CRM 最大的区别就在这里——CRM 是“客户资料库”，而客达天下是“客户调度系统”。

2.2 线索从哪来：Excel 导入、API 接入、手工建档三路客源入口

客源池再大也得有入口。常见的客达天下部署方案里，线索进池子有三条路，每条的适合场景完全不同。

Excel 导入最常用。线下展会收了一摞名片、老销售手里有一批历史客户，直接用系统自带模板导进去就行。这里有个细节：导入模板里的手机号列必须设成文本格式，否则 Excel 会把 11 位手机号转成科学计数法，导进去全是 138****0000 这种残缺数据。我一般会在导入前写一段清洗脚本，先格式校验再入库。

API 接入适合有网站或小程序的团队。比如官网留资表单、小程序授权手机号，都可以通过后端接口直接写入客源池。常见做法是 POST 一个 JSON 到统一入口：

{ "source": "official_site", "name": "张先生", "phone": "13800138000", "remark": "咨询企业版报价", "extra": { "utm_source": "baidu", "utm_campaign": "summer" } }

字段不算多，但注意source和extra这两项。source决定了这条线索进池子之后走哪条分配规则，extra里存渠道参数，后面做成交漏斗分析全靠它。

手工建档是兜底方案。电话里聊出来一个意向客户，销售顺手就能在跟进工作台里建档，不用等导入。它走的是另一套去重逻辑，按手机号判断是否已存在，重复号码会弹提示，避免同一个客户被建两条档案。

三条入口进来之后统一落到客源池的clue_record表，状态都是“新客未分配”。这时候分配引擎才登场。

2.3 关键数据表设计与状态流转：从“新客”到“成交”的九种状态

客达天下资源包里的数据库脚本通常自带核心表结构，但理解它的设计比直接跑脚本更重要。主要三张表：clue_record存客户主数据，allocation_log存每一次分配动作，follow_record存跟进记录。其中clue_record里最关键的一个字段是status，它是一条线索的生命线。

我习惯把状态设计成整数枚举，而不是字符串。字符串看着直观，但在并发场景下容易写花，统计报表也不好做。常见的一套状态值长这样：

# 线索状态机 STATE_NEW = 0 # 新客未分配 STATE_ASSIGNED = 1 # 已分配待跟进 STATE_FOLLOWING = 2 # 跟进中 STATE_BOOKED = 3 # 已预约到访 STATE_WON = 4 # 已成交 STATE_LOST = 5 # 已流失 STATE_RECYCLED = 6 # 已回收待重分 # 合法流转路径 allowed_transitions = { STATE_NEW: [STATE_ASSIGNED], STATE_ASSIGNED: [STATE_FOLLOWING, STATE_RECYCLED], STATE_FOLLOWING: [STATE_BOOKED, STATE_LOST, STATE_RECYCLED], STATE_BOOKED: [STATE_WON, STATE_LOST], STATE_LOST: [STATE_RECYCLED], STATE_RECYCLED: [STATE_ASSIGNED], }

状态机的作用不是限制销售操作，而是让“谁能改、改成什么”这件事变得可审计。比如销售不能把一条“跟进中”的线索直接改成“新客未分配”，那样会把分配记录搞乱。所有状态变更都写进follow_record，后面查“这条客户为什么突然流失了”时，翻状态流转日志就能看到是谁在什么时间把状态改掉的，不用靠猜。

状态设计这步是最值得花时间的。很多团队部署客达天下后翻车，不是系统跑不起来，而是状态定义和自己的业务流程对不上。比如你希望“已预约”之后还能回到“跟进中”，但默认状态机不允许，就得提前改脚本。先把自己的跟进流程画出来，再对着状态机调，比上线后补救省事得多。

3. 本地部署客达天下资源包：Docker Compose 一键起服务的最小配置

拿到软件资源包之后，第一个问题是“怎么跑起来”。客达天下这类项目通常会给一套 Docker Compose 编排文件，把数据库、缓存、后端服务、Nginx 网关一次性拉起。这样设计的好处是环境一致，不用在每台机器上手工装 MySQL、Redis，也方便团队其他人快速复制一套开发环境。下面是我经过多次部署后沉淀下来的最小可运行配置，照着改密码就能用。

3.1 部署前置条件：硬件、系统与端口规划

先说硬件。我踩过的底线是 2 核 4G，低于这个配置，MySQL 和 Redis 同时跑会频繁触发交换分区，系统响应慢到怀疑人生。如果团队超过二十个人同时在线，建议直接上 4 核 8G，成本没差多少，体验完全不同。磁盘至少留 40G，因为客户数据加上跟进附件、导入文件，增长比你想象中快。

操作系统选 Ubuntu 22.04 或 Debian 12 都行，CentOS 7 的 Docker 版本太老，跑新版镜像容易出兼容问题。系统装好后确认两件事：Docker 和 Docker Compose 插件版本。用docker compose version检查，低于 v2.20 的建议升级，旧版本对depends_on的条件支持不完整，服务启动顺序可能乱掉。

端口方面，默认占用 80（Nginx）、8080（后端）、3306（MySQL）、6379（Redis）。如果你本机已经跑了其他服务，尤其是 MySQL 和 Redis，端口冲突几乎是必然的。我习惯把内网专用的 MySQL 和 Redis 端口映射改成不常见的，比如 13306 和 16379，既能避免冲突，也减少被扫描的风险。这个调整在 Compose 文件里改ports段就行。

3.2 docker-compose.yml 最小可运行配置与参数说明

下面这份 Compose 配置是我实际部署过多次的版本，可以直接作为起点。镜像名以资源包内提供的为准，我这里用占位写法，重点在结构和环境变量：

version: "3.8" services: mysql: image: mysql:8.0 container_name: kdt-mysql restart: always environment: MYSQL_ROOT_PASSWORD: Kdt_root_2026 MYSQL_DATABASE: kdt_core MYSQL_USER: kdt_app MYSQL_PASSWORD: Kdt_app_2026 command: - --character-set-server=utf8mb4 - --collation-server=utf8mb4_unicode_ci volumes: - ./data/mysql:/var/lib/mysql - ./sql/init:/docker-entrypoint-initdb.d ports: - "13306:3306" redis: image: redis:7-alpine container_name: kdt-redis restart: always command: redis-server --requirepass Kdt_redis_2026 --appendonly yes volumes: - ./data/redis:/data ports: - "16379:6379" app: image: kdt-server:latest container_name: kdt-app restart: always depends_on: mysql: condition: service_healthy redis: condition: service_started environment: SPRING_DATASOURCE_URL: jdbc:mysql://mysql:13306/kdt_core?useUnicode=true&characterEncoding=utf8&useSSL=false&serverTimezone=Asia/Shanghai SPRING_DATASOURCE_USERNAME: kdt_app SPRING_DATASOURCE_PASSWORD: Kdt_app_2026 SPRING_REDIS_HOST: redis SPRING_REDIS_PORT: 6379 SPRING_REDIS_PASSWORD: Kdt_redis_2026 volumes: - ./upload:/data/upload ports: - "8080:8080" nginx: image: nginx:1.24-alpine container_name: kdt-nginx restart: always depends_on: - app volumes: - ./nginx/conf.d:/etc/nginx/conf.d - ./web:/usr/share/nginx/html ports: - "80:80"

这段配置有几个关键点必须说明。MySQL 的command里指定了utf8mb4字符集，这是中文姓名的命根子。很多系统部署完显示乱码，都是漏了这一步。./sql/init挂载到容器的/docker-entrypoint-initdb.d，MySQL 首次启动时会自动执行这个目录下的.sql脚本，初始化表结构和基础数据，不用手工去跑 SQL。注意是首次启动，如果./data/mysql目录已经存在，MySQL 不会重复执行初始化脚本，所以部署前要确认数据目录是空的。

后端服务里的环境变量SPRING_DATASOURCE_URL是 Spring Boot 系列的典型写法，如果资源包用的是别的框架，字段名可能不一样，但思路相同——应用通过环境变量拿数据库连接信息，而不是把账号密码写死在配置文件里。Redis 的--appendonly yes开启了持久化，防止 Redis 重启后丢失缓存数据，属于必须开启的选项。

3.3 首次启动后的初始化检查：服务健康、数据库迁移与默认账号

Compose 文件写好后，启动只是第一步。我见过太多人执行完docker compose up -d就以为完事了，结果第二天发现后端日志里全是数据库连接失败的报错。正确流程是三连检查。

# 1. 启动服务 docker compose up -d # 2. 查看所有容器状态 docker compose ps # 3. 跟踪后端日志，确认无异常堆栈 docker compose logs -f app

如果docker compose ps里某个容器处于Restarting状态，说明启动失败了，立刻看对应的容器日志，不要反复重启。docker compose logs mysql能看到 MySQL 的错误信息，比如数据目录权限不对、初始化 SQL 文件语法错误，都会在这里暴露出来。

后端服务起来之后，还要验证健康检查接口。我习惯用curl直接打网关：

# 健康检查接口，不同系统路径可能不同 curl -I http://localhost/api/health # 期望输出 HTTP/1.1 200 OK

看到 200 之后，接着确认数据库里的初始化数据有没有正确写入。进入 MySQL 容器执行一条简单查询：

docker exec -it kdt-mysql mysql -u kdt_app -pKdt_app_2026 kdt_core -e "SHOW TABLES;"

如果能看到clue_record、allocation_log这些核心表，说明初始化 SQL 跑通了。默认账号通常是一个管理员账号，用户名admin，初始密码在资源包文档里，第一次登录后必须立刻改掉。这里提醒一句：不要用网盘里下载的旧版默认密码，确认不了就问资源提供方拿最新文档，安全上省事不得。

4. 客源分配策略配置：让线索公平流向销售，而不是抢单

客达天下的灵魂在分配。很多团队用起来觉得“系统不好用”，八成不是系统问题，而是分配规则没调对。默认配置通常是最简单的轮流分配，但真实业务有老销售、新销售、销冠、兼职的区别，所有人一视同仁反而是最大的不公平。这一章把分配策略说透，你可以照着配置直接抄作业。

4.1 分配模式对比：手动领取、轮流分配与权重分配

分配模式没有绝对的好坏，只有适合不适合。手动领取适合线索量少、销售自觉性高的团队；轮流分配适合线索量大、不想有人吃饱有人饿死的团队；权重分配适合销售能力有明显差距、希望资源向高转化率的人倾斜的团队。

客达天下的默认配置里，手动领取要求销售自己在工作台点“领取”，系统不会主动推送。这个模式表面自由，实际坑很深——有些销售只挑电话号码好听的领，剩下的没人管，客源池里堆了一堆僵尸线索。轮流分配能治这个毛病，但新问题随之而来：销冠和新人拿到差不多数量的线索，销冠嫌量不够，新人转化率上不去。

我一般的建议是：初期用轮流分配跑两周，让团队形成“收到就跟进”的习惯；观察数据两周后，再切到权重分配，把权重向历史成交率高的人倾斜。一上来就上权重，新人手里没数据，连申诉的依据都没有。

4.2 配置分配规则的关键参数：团队、角色、饱和度与黑名单

分配规则之外，还有一批参数直接决定分配结果。每次调这些参数前都要问自己一句：这个参数是为了解决什么现象？不是为了调参而调参。

• team_id：线索只分配给指定团队，如果团队选错，其他团队永远看不到线索。
• role_weight：角色权重。比如销售主管的权重是 0，不参与分配；老销售权重 2，新人权重 1。
• max_active：单人在手跟进上限。这个参数极其关键，默认值我建议设 30 条。超过上限的销售会被系统跳过，线索自动流转给其他人。
• blacklist：黑名单手机号段。比如自家销售人员的号码、测试号码、已经标记为“投诉”的号码，导入时直接拦截。

配置的最终形态是一组数据库记录，不同的客达天下版本表名略有差异，但字段含义一致。典型的配置写法如下：

-- 配置团队权重与饱和度 INSERT INTO alloc_rule (team_id, role_id, weight, max_active, is_active) VALUES (1, 10, 2, 30, 1), -- 老销售：权重2，上限30 (1, 11, 1, 20, 1), -- 新销售：权重1，上限20 (1, 12, 0, 0, 0); -- 主管：不参与分配

参数里最容易翻车的是max_active。设太大，老销售手里压着几十条线索不跟，客源被锁死；设太小，销售每天光在新线索里打转，没法深挖老客户。30 是一个相对安全的起点，跑两周后按“平均跟进次数”和“成交周期”微调。

4.3 客户回收与防撞单机制：避免两个销售跟进同一个客户

分配只是把线索交给了人，真正的脏活是处理“被遗忘的线索”和“两个人同时跟进”这两个事故现场。回收策略和防撞单机制，就是用来兜底的。

回收策略的核心是一条时间规则：超过 N 天没有新增跟进记录，系统自动把线索从当前销售手里收回，重新进入客源池待分配。具体实现是后台定时任务扫描follow_record的更新时间，用 SQL 找出超时的线索，批量修改状态并记录回收日志。N 的取值有讲究：我见过设 3 天的，结果节假日回来一团乱；也见过设 30 天的，基本等于没有回收。按行业经验，普通销售跟进节奏以 2-3 天一次为正常，所以第一次上线建议设 7 天，给销售足够的缓冲。

防撞单则是分配引擎的最后一道闸。常见做法是给allocation_log加唯一约束：

-- 防止同一条线索同时分配给两个销售 ALTER TABLE allocation_log ADD UNIQUE KEY uk_clue_active (clue_id);

这个约束保证同一条客户数据在同一时刻只能属于一个销售。原理是数据库层面的唯一索引，而不是靠应用代码判断，因为在并发请求下，应用代码的判断存在时间差，数据库约束才是铁壁。实际执行分配时，如果插入了重复的clue_id，数据库会直接报错，应用捕捉到异常后这条线索本轮跳过。这条约束加上之后，撞单问题基本绝迹，后续可以彻底把“这个客户是不是我的”这类争论挡在系统之外。

5. 客达天下部署与使用中的 5 个常见坑：从安装报错到数据丢失

这个章节是血泪经验合集。把客达天下从安装到用顺，至少会踩五类坑，每一类我都见过真实案例，写出来希望能帮你少走弯路。每条按现象、原因、解决的顺序拆开，你对号入座就行。

5.1 坑一：MySQL 字符集没设 utf8mb4，中文姓名全变成问号

现象：导入客户 Excel 后，后台列表里中文姓名显示成 “?????”。跟进记录里写的备注也全是问号，英文和数字正常。

原因：MySQL 默认字符集是latin1，不支持中文字符。Docker 镜像虽然内部是 utf8，但容器初始化时如果不指定字符集参数，建出来的表和库都会继承默认latin1，中文写入时被截断。

解决：在 Compose 文件的 MySQLcommand里显式加两行参数，第一行--character-set-server=utf8mb4设置服务端字符集，第二行--collation-server=utf8mb4_unicode_ci设置排序规则。同时应用连接串里也要带characterEncoding=utf8。改完配置后必须重新初始化数据目录——只重启容器不行，因为表结构已经建出来了，字符集不会自动变。操作是把./data/mysql目录删掉，再执行docker compose up -d，初始化脚本会重新跑一遍。已经有数据的系统改字符集麻烦一些，需要导出数据、重建库、再导入，建议部署前一次到位。

5.2 坑二：线索自动回收不生效，客户压着没人跟

现象：设置了 7 天回收规则，但到期后线索还是留在原销售的跟进列表里，回收日志一条都没有。

原因：定时任务没跑。客达天下的回收依赖系统内部的调度器，很多资源包默认把定时任务开关设成disabled，需要手动开启。另一个隐蔽原因是服务器时区不对——容器默认是 UTC 时区，回收任务按 UTC 时间计算“今天”，凌晨执行的逻辑就会跟北京时间差 8 小时，看起来像没跑。

解决：进入后台管理界面，找到“定时任务”配置页，确认clue_recycle_job的状态是启用。同时在 Compose 文件里给后端服务加上TZ: Asia/Shanghai环境变量，让容器内部的时间跟业务时间一致。改完后手动触发一次回收任务，如果日志里有scan finished, recycled 0说明跑通了，可以等下一次自动执行确认。

5.3 坑三：Nginx 代理之后消息推送掉线，页面收不到新线索提醒

现象：部署好后，销售登录系统，有人手动建档新客户，但其他在线的销售收不到实时弹窗提醒。浏览器控制台里能看到 WebSocket 连接一直在重连。

原因：Nginx 默认对 HTTP 代理做了升级处理，但 WebSocket 需要显式声明Upgrade和Connection头。Nginx 配置里如果没有这段声明，WebSocket 握手阶段就会被拦下来，消息推送自然失效。

解决：在 Nginx 的站点配置里，给 WebSocket 对应的location块加上三行：

location /ws { proxy_pass http://app:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_read_timeout 3600s; }

proxy_http_version 1.1是必须的，HTTP/1.0 不支持 WebSocket 升级。proxy_read_timeout 3600s是把长连接的空闲超时拉长，防止后端隔几分钟就断一次。改完配置执行docker compose exec nginx nginx -s reload生效。

5.4 坑四：Excel 导入后，手机号全变成科学计数法，客户根本联系不上

现象：导入 Excel 后，客源池里的手机号显示成1.38001E+10，点开编辑才看到残缺的号码，后面几位全变成 0。

原因：Excel 的“常规格式”会把超过 11 位的数字自动转成科学计数法。如果客户收集表里的手机号不是文本格式，导出或者导入时就会被这个机制污染。污染发生在源头，导进客达天下时已经是坏数据，系统层面救不回来。

解决：导入模板的手机号列必须预先设成“文本”格式。同时在导入程序里加一道清洗逻辑，用正则把可能的格式差异拉齐。如果已经导入了坏数据，只能写一个临时脚本来尽量修复，能修的修，修不了的删掉重新导入。这里附一个我常用的清洗函数：

import re def clean_phone(raw: str) -> str: # 去掉空格、横线、括号等分隔符 digits = re.sub(r"[\s\-()]", "", str(raw)) # 去掉科学计数法残余 if "E" in digits.upper(): digits = str(int(float(digits))) # 保留纯数字，检查长度 digits = re.sub(r"\D", "", digits) if len(digits) == 11 and digits.startswith("1"): return digits return "" # 返回空串，标记为失效

这函数不复杂，但能拦截 90% 的号码格式问题。另一个经验是导入前先用 Python 读一遍整个文件，统计有效手机号比例，低于 95% 就直接退回去让收集方重新整理，别硬导。

5.5 坑五：数据库没备份，误操作之后客源池一夜归零

现象：某同事清理“无效数据”时，条件写错了，把整张clue_record表 DELETE 了。发现时已经过了两天，客源池空了，所有人的跟进记录都没了，业务直接瘫痪。

原因：没配数据库自动备份，或者配了备份但没验证过备份文件可恢复。Docker 部署时数据挂在 volume 里，容器删了重建数据还在，但 SQL 删了就是删了，没有任何后悔药。这不是客达天下本身的问题，是部署环节的疏漏。

解决：MySQL 容器每天定时执行mysqldump，备份文件保留 30 天。一种可靠做法是宿主机上放一个 cron 脚本：

#!/bin/bash # 每日凌晨2点备份客达天下数据库，保留30天 # 备份目录 /data/backup/kdt BACKUP_DIR="/data/backup/kdt" DATE=$(date +\%Y\%m\%d_\%H\%M\%S) docker exec kdt-mysql mysqldump -u root -p"$MYSQL_ROOT_PASSWORD" --single-transaction kdt_core \ > "$BACKUP_DIR/kdt_core_$DATE.sql" find "$BACKUP_DIR" -name "kdt_core_*.sql" -mtime +30 -delete

--single-transaction参数保证备份期间不影响业务读写，适合 InnoDB 表。备份不是配了就完事，每个月至少做一次恢复演练，把备份文件导入到一个临时容器，确认能查询出数据。没验证过的备份等于没有备份，这句是数据管理的第一原则。

6. 把客达天下用出效果：数据看板、冷号唤醒与分配均匀性验证

系统稳定运行之后，真正拉开差距的就不是部署，而是运营方法了。这一章不聊怎么做界面，只聊三件我用下来觉得最能提效的事：用数据看板验证分配策略、用脚本把冷号唤醒再分配、用模拟数据检验分配是否均匀。

6.1 用成交漏斗验证分配策略是否公平

分配策略合不合理，不要凭感觉，要看数据。我的做法是每周跑一次渠道成交漏斗，把客源入口、分配模式、成交率三条数据放在一起看。

SELECT source, COUNT(*) AS total_clues, SUM(CASE WHEN status >= 4 THEN 1 ELSE 0 END) AS won_clues, ROUND(SUM(CASE WHEN status >= 4 THEN 1 ELSE 0 END) / COUNT(*), 4) AS win_rate FROM clue_record WHERE created_at >= DATE_SUB(NOW(), INTERVAL 30 DAY) GROUP BY source ORDER BY win_rate DESC;

这个查询解决两个问题：一是哪个渠道来的客户质量高，预算该往哪倾斜；二是分配规则有没有导致优质线索集中到个别人手里。如果某个渠道的线索量大且转化率高，而对应销售的成交率没有同步上升，说明线索可能卡在“已分配待跟进”状态没被及时激活，这时候该看下一招。

6.2 冷号唤醒：把沉睡 30 天的流失客户重新拉回客源池

很多团队只盯着新客分配，忽略了流失客户里还有一批只是没跟透的。我的习惯是每月跑一次冷号唤醒脚本，把状态为“已流失”且超过 30 天没有新跟进记录的客户重新放进客源池。

import requests import datetime # 假设系统提供了重新激活的接口 ACTIVE_API = "http://localhost/api/clue/reactive" # 今天的日期减 30 天 deadline = (datetime.datetime.now() - datetime.timedelta(days=30)).strftime("%Y-%m-%d") payload = { "where": { "status": 5, # 已流失 "last_follow_lte": deadline # 最后跟进时间早于 deadline }, "action": "to_pool" # 回到客源池待分配 } resp = requests.post(ACTIVE_API, json=payload, timeout=10) print(f"recycle request sent, code={resp.status_code}, body={resp.text}")

唤醒不是把所有流失的都拉回来，那样客源池很快会被低质量数据灌满。建议只唤醒那些“跟进次数大于等于 3 次但最终未成交”的客户，说明有真实接触，可能只是没在合适时机成交。重新分配后，销售看到的历史跟进记录还在，不需要重新摸情况。

6.3 用模拟数据检验分配是否均匀：别让权重分配变成黑匣子

权重分配有个潜在问题：配置了权重 3:2:1，但实际分配结果不一定严格按 3:2:1 走，因为随机性会让短时间内的分配比例偏移。我曾见过团队因此觉得系统有内幕，其实只是样本量不够。解决办法是上线前用模拟数据做一次大样本检验：

import random # 配置：三个销售的权重 weights = [3, 2, 1] sales_ids = [101, 102, 103] # 模拟 1000 条线索的分配结果 N = 1000 counts = {sid: 0 for sid in sales_ids} for _ in range(N): pick = random.choices(sales_ids, weights=weights, k=1)[0] counts[pick] += 1 total = sum(counts.values()) for sid in sales_ids: print(f"sales {sid}: {counts[sid]} ({counts[sid] / total:.1%})")

如果 1000 条模拟分配后，三个人的占比在 50%、33%、17% 附近波动，说明配置没问题。偏差超过 5 个百分点，要检查权重值是否真的写进了数据库，或者是否有max_active把某个人提前移除了分配池。这个检验用真实数据跑一遍会直接影响销售对系统的信任度，别跳过。

这套系统我用下来最深的教训是：别把客达天下当成一个数据库用，它本质上是一台分配机器，配置规则比录入数据重要得多。数据录得再全，分配不公平、回收不执行，客源池就是死水一潭。先跑通分配和回收的闭环，再谈精细化运营，这个顺序不能反。希望帮到你。

本文还有配套的精品资源，点击获取