客户数据分配系统：从业务规则到可落表模型

公开摘要

这篇文章把一份客户资源分配规范抽象成通用系统设计文章：不保留项目名、组织名、真实人员规模、精确时间表或专有业务口径，只讨论可复用的建模方法。它的重点是把“谁应该接哪个客户”拆成资源池、分级、容量、排班、分配事件、SLA、回收和暂停规则，让业务口径可以落表、回放和审计。

领域模型：分配不是写入一个顾问 ID

客户分配系统的核心对象至少包括客户资源、顾问、规则、排班、分配事件和响应结果。客户当前归属只是结果字段，真正支撑运营复盘的是事件链：资源何时入池、为什么被定为某等级、经过哪些过滤、最终分给谁、顾问是否按时响应、后续是否无效、重复、回收或暂停。

客户资源 → 入池事件 → 客户分级 → 顾问候选集 → 排班/容量过滤 → 分配事件
分配事件 → 响应 SLA → 有效/无效/重复/改派/回收 → 审计与报表

对象	系统职责	关键状态	审计重点
客户资源	承载来源、联系方式摘要、需求、等级、当前归属	待分级、待分配、跟进中、回收池	来源、去重依据、等级变化
顾问	承载等级、资格、容量、暂停状态	可分配、满载、暂停、离线	资格变更、暂停原因、容量消耗
排班时间片	定义某人在某时间是否可承接	可分配、不可分配、请假、临时关闭	排班来源、修改人、修改时间
分配事件	记录一次派发决策	待响应、已接单、超时、改派、关闭	规则版本、候选列表、命中原因

设计时要避免只在客户表上反复覆盖 advisor_id。覆盖字段可以服务查询，但不能替代分配记录。否则，一旦发生归属争议、投诉、超时或重复客户，就无法说明当时系统为什么这么分。

资源类型与客户分级

资源类型决定进入分配流程的入口策略。公开化后可以抽象为三类：新增线索、长期未转化资源、交接或离职转入资源。它们都进入统一资源池，但分级、去重、优先级和回收周期可能不同。客户等级则根据预算、需求强度、产品类型或企业自定义评分生成；没有明确数值时，必须定义估算口径和置信度。

资源类型	定义	入池动作	分配关注点
新增线索	来自投放、自然流量、活动或咨询入口	去重、补充来源、触发分级	响应速度和首次触达质量
存量资源	长期未成交或长期未推进的客户	检查原归属、计算回收资格	避免重复打扰，明确新旧归属
交接资源	人员变动、团队调整、服务关系转移产生	冻结旧归属、建立交接事件	客户连续服务和责任边界
主动申请资源	顾问或运营按规则申请承接	审核资格、记录申请原因	防止绕过自动分配和容量约束

客户分级建议使用配置化规则，而不是写死在派发脚本里。等级可以是 S/A/B/C/D，也可以是高/中/低意向；关键是记录规则版本、输入字段、计算结果和人工修正原因。若某类产品或服务不参与同一等级体系，应在规则层明确排除，不要让页面备注承担规则。

等级维度	示例口径	落表字段	注意事项
预算/价值	明确预算、估算预算、资产区间	`budget_level`、`budget_confidence`	公开文档不暴露真实阈值，可用区间占位
需求类型	产品线、服务类型、咨询主题	`demand_type`、`product_scope`	混合需求要有主需求判定规则
意向强度	咨询频次、主动程度、资料完整度	`intent_score`、`intent_level`	评分要可解释，避免黑箱派发
人工修正	运营复核后调整等级	`manual_override_reason`	必须留痕，纳入审计

分配不是一次写入顾问 ID，而是一条可回放的业务事件链。

顾问等级、容量与排班时间片

顾问侧建模要回答三个问题：有没有资格接、当前能不能接、接了会不会超载。顾问等级可来自近阶段业绩、成交率、服务质量或综合评分；容量则要区分每日新增上限、同时跟进上限、某类高价值资源上限；排班时间片用于避免把客户派给不在线或不承接的人员。

过滤层	判断问题	建议字段	结果
资格	该顾问能接此等级/类型资源吗	`advisor_grade`、`allowed_resource_levels`	不符合则剔除候选集
容量	今日或当前并发是否已满	`daily_quota`、`active_capacity`	满载则跳过或排队
排班	此日期与时间片是否可分配	`schedule_date`、`slot_start`、`slot_status`	不可分配则跳过
暂停	是否因服务质量或规则触发暂停	`pause_until`、`pause_reason`	强过滤，不参与候选

排班模型建议使用日期 + 时间片 + 顾问 + 状态的结构，而不是把一个月的排班写成宽表。时间片粒度按业务运营需要配置；公开文章不需要暴露真实班表规模，只需要强调它应可导入、可修正、可追溯来源。

匹配管线：从候选集到分配事件

匹配过程应分层执行，先做强约束过滤，再做排序或轮询。强约束包括资源类型、客户等级、顾问资格、排班、容量、暂停状态、黑名单或冲突关系。排序策略可以是轮询、权重、转化率、服务质量、最近分配时间或运营手动优先级，但必须记录命中的规则版本。

资源进入待分配队列，完成去重和分级。
按资源类型和客户等级筛选具备资格的顾问集合。
按当前日期、时间片、排班状态过滤可承接顾问。
按容量、暂停、特殊冲突规则再次过滤。
使用轮询、权重或评分策略选出目标顾问。
写入分配事件，冻结当次规则版本、候选摘要和命中原因。
触发通知与 SLA 计时，等待顾问响应或系统超时处理。

分配事件日志是系统的事实表。即使客户后来改派，也应该新增事件或状态流转，而不是覆盖旧事件。这样才能在报表中计算首次响应时长、超时率、有效率、回收率、顾问承接质量和规则命中效果。

事件字段	含义	为什么重要
`assignment_id`	分配事件唯一标识	作为 SLA、反馈、改派、审计的挂载点
`rule_version`	当次使用的规则版本	规则变化后仍可复盘历史决策
`candidate_snapshot`	候选集摘要	解释为什么某些顾问未被选中
`decision_reason`	命中原因	支撑运营申诉和规则优化
`assigned_at`	分配时间	计算响应时长和时间片归属

SLA、无效、重复、回收与暂停

SLA 模型要区分“已通知”“已接单”“已首次触达”“已反馈有效性”“超时”“自动兜底”等状态。不同企业的响应时限可以配置，但状态机必须明确：什么时间开始计时，什么动作算响应，超时后是提醒、暂停、改派还是进入人工处理。

规则类型	系统判断	处理动作	留痕要求
无效	不符合服务对象、无法建立联系、明显异常或诈骗	关闭分配或退回资源池	无效原因、证据摘要、操作人
重复	联系方式、咨询间隔、业务线或历史归属命中	归原顾问、并行跟进或重新分配	重复规则、历史资源引用
回收	超过跟进周期仍未转化或无推进	进入回收池，允许再分配	首次分配时间、回收原因
暂停	超时、服务投诉、容量异常或长期无产出	暂停派发一段时间或人工复核	触发条件、暂停周期、恢复条件

暂停派发应作为强过滤字段进入匹配管线，而不是顾问备注。重复客户也不要只靠人工记忆，至少要建立联系方式摘要、历史咨询时间、原归属、业务线和重复判断结果。回收规则则要考虑客户体验，避免短期内被频繁更换服务人员。

建议表结构与报表审计

落表时可以按“规则配置、资源池、顾问能力、排班、分配事件、SLA 反馈、暂停与回收”拆分。客户表保存当前快照，事件表保存历史事实，配置表保存可版本化规则。报表不要直接从页面状态拼凑，应基于事件表聚合。

表	建议字段	用途
`distribution_rules`	规则类型、版本、条件 JSON、启停状态、生效时间	配置客户分级、匹配、回收、暂停规则
`customer_pool`	来源、资源类型、联系方式摘要、等级、需求、当前状态	统一承载待分配与跟进资源
`advisor_profiles`	顾问等级、资格范围、容量、组织、状态	判断候选资格与承接能力
`advisor_schedules`	日期、时间片、顾问、状态、来源、修改人	提供排班过滤依据
`assignment_events`	客户、顾问、规则版本、候选摘要、状态、分配时间	记录每次分配事实
`assignment_responses`	事件、响应时间、触达结果、有效性、原因	计算 SLA 与有效率
`advisor_pauses`	顾问、触发原因、开始/结束时间、恢复条件	控制暂停派发
`recycle_records`	客户、原顾问、回收原因、回收时间、再分配事件	追踪存量资源再运营

审计与报表建议覆盖：各来源入池量、等级分布、首次响应时长、超时率、有效率、重复率、回收再分配转化、顾问容量使用率、暂停触发次数、规则命中分布。涉及个人信息和联系方式时，报表层尽量使用脱敏摘要与统计指标，避免把敏感字段扩散到运营导出文件。

资源类型、客户等级、顾问等级、容量、排班、暂停均已模型化。
分配事件不被覆盖，所有响应、改派、回收都挂在事件链上。
规则配置有版本，历史分配可按当时规则复盘。
SLA 状态机定义了开始计时、有效响应、超时处理和兜底动作。
重复、无效、回收、暂停都有字段、原因和审计记录。
报表基于事件聚合，并对客户隐私字段做最小化和脱敏处理。