THE REAL PROBLEM
只交给“有空的人”，并不等于好的分配。
每个案件都有必要资格和经验，每位负责人也有擅长领域、地区、工时上限、既有客户和当前负荷。单个分配看似合理，整体却可能产生偏载和机会损失。
不能漏看必要能力
资格、产品知识、行业经验、语言、审批权限等，会因案件而异。
也要保护客户延续关系
过往対応、关系、交接成本和相性等难以量化的因素，也会影响分配质量。
容易集中到能干的人身上
如果案件集中给熟练人员，会带来加班、属人化和培养停滞。模型会看难度和时间，而不只看件数。
紧急案件和缺勤会要求重排
新请求、负责人缺勤或优先级变化时，需要保持已确定关系，同时重新分配剩余案件。
把管理者脑中的比较过程，转化为可说明的计算和确认画面。
MODEL THE DECISION
把分配规则拆成三层来设计。
分清必须满足的条件、尽量优先的条件，以及整体改善指标，让每个推荐都有可追溯的依据。
model sketch
feasible(person, case) -> score(skill, continuity, response, balance) -> candidate list
系统不会用一个适合分自动决定人选，而是分开显示必守条件、候选理由、替代候选和整体影响。
HARD
必须遵守的条件
- 必要资格和审批权限
- 可工作时间和容量
- 可负责地区和合同限制
SOFT
尽量满足的偏好
- 相似案件经验
- 客户担当延续
- 距离和响应时间
OBJECTIVE
整体改善指标
- 提高适合度
- 减少未分配案件
- 平衡工作负荷
WHERE IT FITS
适用于需要持续匹配案件要求和人员强项的业务。
当候选人不止一人、条件较多、还要考虑负荷和延续关系，并且经常发生变更时，就适合先整理模型。
FIELD维修、保养、点检
根据资格、产品经验、紧急度、地区、部件和客户延续，提示技术负责人候选。
BUILD建设、施工、现场
根据工种、资格人员、技能、现场距离、工期和班组结构分配负责人和支援人员。
SALES企业销售和客户负责人
根据行业知识、产品、地区、客户规模、既有关系和案件量选择主担当和支援担当。
PROJECT项目和专家分配
根据技术、经验、期间、稼动率、角色和团队构成，把成员分配到项目。
INTERACTIVE EXAMPLE
调整条件权重，比较候选人与理由。
这是说明用的简化计算。真实项目会加入权限、固定担当、多人团队、期间计划、收益、培养和既有系统连接。
这不是生产用优化引擎，而是用于确认判断结构的浏览器内演示。
已分配
必要能力满足
平均适合度
最大负荷差
担当延续
未分配
CASE ASSIGNMENTS
各案件候选负责人
WORKLOAD
负责人负荷
UNASSIGNED
未分配案件和理由
RULE DESIGN
把候选计算条件整理成可确认的数据。
把资格、容量、地区、延续、负荷和禁止属性分开，避免把候选可否与排序理由混在一起。
R001skill必要能力
只把满足案件必要能力的人保留为候选。
R002capacity工时上限
分配后的负荷不超过负责人容量。
R003region负责地区
排除地区外或合同上不能负责的候选人。
R004continuity客户延续
评价交接成本和过往客户关系。
R005experience相似经验
把行业、产品和难度接近的经验反映到排序。
R006response距离和响应
在需要访问或初动的案件中评价移动和响应时间。
R007balance负荷均衡
避免难案件长期集中给同一批熟练人员。
R008freeze固定和审批
必要时固定已开始或已联系客户的分配。
R009sensitive禁止属性
年龄、性别、国籍、健康信息等不用于评价。
EXPLAINABLE OUTPUT
不只显示姓名，也显示决策材料。
画面应能确认候选理由、替代候选、候选外理由和对整体负荷的影响。
选择理由和评价明细
显示必要能力、经验、延续、距离、负荷等项目的评价。
替代候选和差异
用同一尺度比较第二、第三候选人的强项和不足。
候选外和未分配理由
把资格不足、容量超限、地区不符、利益冲突等原因分类。
整体影响比较
显示人工修改后，剩余未分配、负荷差和延续率如何变化。
HUMAN CONTROL
因为涉及人，必须明确自动化边界。
本页面面向既有负责人之间的业务分配支援，不会把招聘、解雇、晋升、薪酬等高影响人事判断设计成由单一分数自动决定。
不把敏感属性用于评价
年龄、性别、国籍、健康信息等不进入候选评分。
必须能由人审批
系统提示候选人，管理者确认理由和替代候选后再确定。
记录变更和例外
人工修改、固定、排除、审批者、时间和理由写入审计日志。
定期确认偏差
统计工作量、难度、培养机会和收益机会是否偏向特定人员。
START WITH YOUR DATA
用少量案件和负责人数据，先确认“是否能选”。
可以从现在使用的分配表和判断规则开始，制作只计算候选人的原型。匿名化的一天或一个月数据也足够开始。
案件和客户列表
期限、地区、难度、必要能力、优先级、延续希望
负责人和能力列表
资格、经验、可负责领域、工时、上限、希望
分配规则
必守、优先、排除、固定、利益冲突、审批路径
过去分配和实绩
担当、耗时、结果、变更、未分配和理由
先验证是否能生成候选
使用匿名化的负责人和案件数据，与现行分配方案比较。
- 必守、偏好和评价指标列表
- 每个案件的候选人与理由
- 未分配和候选外理由
- 负荷、延续和适合度比较
- 生产系统结构方案
免费确认是否适合
如果更适合先使用现成工具或整理业务流程，也会明确说明。
FIT CHECK
适合专用开发的情况，以及不适合的情况。
不会把所有东西都硬做成分数，而是先确认候选数量、条件复杂度、变更频率和说明责任是否值得系统化。
适合咨询
- 每个案件的资格、经验、地区等条件不同
- 负责人决定依赖少数管理者的经验
- 能干的人负荷集中或客户交接成为问题
- 经常因紧急案件或缺勤重新分配
- 需要候选理由和人工修改记录
应先整理规则或考虑现成工具
- 负责人很少，固定担当即可运转
- 案件要求或能力数据尚未定义
- 简单顺序或地区划分已足够
- 应先记录案件受付和实际工时
- 目标是招聘、晋升等高影响人事判断
FAQ
常见问题
咨询前经常确认的事项。
负责人技能还没有数值化，也能咨询吗？
可以。可以从资格有无、担当经验、自我申报、管理者评价、过去案件等现有信息开始，逐步整理等级。
可以区分必备资格和“最好有经验”吗？
可以。必备资格用于判断候选可否，经验用于影响排序。各条件的依据和优先级都会明确显示。
一个案件可以分配多人团队吗？
可以。可以定义负责人、持证人员、辅助人员等角色，并检查团队整体是否满足必要能力。
可以优先保持客户担当延续吗？
可以。可把过去担当、主担当、已交接、客户希望等条件化，并比较延续和变更的差异。
负责人缺勤时可以重新分配吗？
可以。已确定、已开始或已联系客户的案件可以固定，只重新计算受影响的未开始案件。
系统会自动确定负责人吗？
原则上建议提示候选人，由人确认、修正、审批。低风险的定型案件可以考虑自动确定，但必须明确条件和例外处理。
会把年龄、性别等用于候选评价吗？
不会。本页面对象是既有负责人之间的业务分配支援，前提是不把敏感属性纳入适合度评分。
是用生成AI来选人吗？
核心是明确条件的约束满足、数学优化和搜索。即使辅助使用AI提取案件要求，候选可否和评价理由也应结构化显示。
可以和现有CRM、案件管理或人员管理系统连接吗？
可以考虑API、CSV、数据库、文件联动等方式，也可以只在现有系统旁边追加候选计算和审批画面。
可以计算多少案件和负责人？
难度不仅取决于数量，还取决于团队编成、期间、固定、资格、相性、多个目标和再计算时间。会用接近真实的数据测定性能和解质量。