客服人员每天打开工单池，看到的是各种入口进来的请求——电话里抱怨服务态度的投诉、在线咨询活动规则的普通问题、APP 上传故障照片的设备报修——全都堆在一个待办列表里，需要人工逐条判断类型、找对应的工单模板、填写字段再分配到处理部门。请求量低时还能应付，一旦促销活动或设备故障高发期集中爆发，积压和错派的连锁反应就会直接拉长解决时长。
不是所有企业都有充足的售后团队来人工处理分类和派单。把分类和路由交给流程自动化处理，前提是系统能理解请求是什么类型，知道不同类型需要哪些信息，并能按预设规则把工单送到正确的人或部门手里。
混在一起的工单为什么难处理
三类请求之所以不能用一个流程处理，是因为它们在信息采集对象、处理角色、时效要求和闭环方式上存在根本差异。
咨询类的问题通常是标准化的：查询订单、了解政策、确认流程。信息采集集中在客户身份和问题范围内，大多数情况下一次回复即可闭环，不需要跨部门流转。
投诉类的问题涉及服务态度、产品质量或承诺未兑现。信息采集需要还原事件经过、涉及人员和影响范围。这类工单对处理时效敏感，通常需要在 SLA 内升级到主管或合规角色，并记录处理结果和预防措施。
报修类的问题依赖设备信息、故障描述、现场材料和客户地址。工单需要派发到维修团队或服务商，涉及上门时间确认、维修进度跟踪、验收和回访。
当这三类请求共用同一个入口却没有分流规则时，坐席需要先人工判断请求类型，再选择对应模板、填写字段、查找分配对象。这个判断过程在高并发时段会成为效率瓶颈。
自动分类与路由的核心机制
实现工单自动分类和路由，需要三个环节协同：意图识别、信息提取和规则派发。合力亿捷的工单系统依托 MPaaS 流程编排和工单规则引擎，将这三个环节串联成可配置的自动化链路。
第一步：识别请求类型。 请求进入时，Agent 根据会话内容判断它属于咨询、投诉还是报修。判断依据可以来自客户选单（如 IVR 按键、APP 问题类型选择），也可以来自 Agent 对自然语言的理解（如"我要投诉""查一下订单""冰箱不制冷了"）。两种方式可组合使用，前者降低识别门槛，后者减少客户操作步骤。
第二步：提取对应字段。 不同类型需要的信息不同。咨询类采集客户身份和问题范围即可；投诉类需要记录时间、涉及人员、事件经过和客户诉求；报修类需要设备型号、故障描述、地址和期望上门时间。Agent 在对话中逐项追问并补全字段，确保工单创建时信息完整。
第三步：按规则选择模板并派发。 工单系统根据识别出的问题类型，自动选择对应的工单模板（咨询模板/投诉模板/报修模板），并将已采集字段填入模板。然后按预设的派发规则，将工单送到对应部门或角色：咨询类进入客服在线队列，投诉类升级到投诉处理组或主管，报修类派发到对应区域的服务商或维修团队。
工单系统支持自定义流程、派发、转派、升级、退回和 SLA 提醒。这意味着不同问题类型不仅可以走不同模板，还可以在流转过程中按状态触发不同的后续动作——投诉超过处理时限自动升级，报修完成后自动触发回访。
一条请求从进入到工单闭环的完整流程
以设备报修场景为例，一条从电话进来的报修请求，在自动分类和路由机制下经历以下流程：
客户来电 → 通话 Agent 识别为"报修"意图 → Agent 追问设备型号、故障现象、购买时间和联系地址 → 字段采集完成后，系统按规则选择报修工单模板 → 填入已采集的客户信息、设备信息和故障描述 → 根据客户所在区域，派发到对应服务商的维修队列 → 服务商接单、联系客户、上门维修 → 维修完成后系统触发回访任务 → 客户确认后工单关闭。
在同样的入口下，如果客户说的是"我要投诉客服"，流程则完全不同：Agent 识别为投诉意图 → 记录投诉对象、时间、事件经过 → 选择投诉工单模板 → 派发到投诉处理组 → 主管审核后在 SLA 时限内处理 → 处理结果输入后触发质检复核。
这两个流程的差异不是在入口处由人工决定，而是由 Agent 的意图识别和工单系统的规则引擎自动完成。对于企业而言，不同入口（电话、在线、APP、公众号）进来的请求，最终都能进入同一套分类和路由体系，而不是每个入口各自定义一套处理方式。
业务规则如何定义分类和路由
自动分类和路由的效果取决于规则的清晰程度。企业在配置时，需要逐个场景明确以下维度：
触发条件：什么信号触发自动分类？是客户选的菜单项，是 Agent 识别的意图关键词，还是客户上传的图片/文件类型？
问题类型与模板映射：每种问题类型对应哪个工单模板？模板中哪些字段是必填的，哪些可以从会话中自动提取？
派发目标：每种问题类型派发到哪个部门、哪个角色或哪个服务商？是按区域派发、按技能组派发，还是按工作量均衡派发？
时效与升级规则：不同类型工单的 SLA 时限是多少？超时后升级到哪一级？什么条件下触发投诉升级？
闭环条件：工单在什么状态下算完成？需要哪些角色确认？是否需要回访和满意度评价？
以合力亿捷的工单系统能力为例，工单模板和业务字段可按业务场景自定义，派发规则支持按部门、角色、区域和服务商灵活配置。售后场景中，售后服务 Agent 可采集客户身份、订单号、设备型号、故障描述、地址、期望时间及图片或视频材料，并按业务规则选择模板、补全字段并派发到对应部门或服务商。SLA 提醒、超时预警、处理记录、移动端处理、签名验收、回访和满意度评价贯穿工单全生命周期。
实施前提与边界
自动分类和路由并非开箱即用，它依赖三个前提条件：
字段和流程配置。问题类型、模板映射、派发规则和 SLA 参数需要业务方与服务商在实施阶段逐一确认并配置。自动建单、派发和系统回写依赖已配置的字段、流程和接口。
知识积累。Agent 对问题类型的识别准确率与业务知识的覆盖度相关。高频且标准化的请求（如查订单、报修）识别稳定，低频或表达模糊的请求需要更多训练数据和规则调整。
系统接口。工单需要与 CRM、ERP、订单、设备等业务系统联动时，字段范围、权限和响应时间取决于客户系统接口，不是所有系统天然可查或可回写。
工单系统在实际项目中的表现已在多个行业得到验证。某头部连锁茶饮企业通过自动工单创建和流程派发，实现问题响应速度提升 42%，工单解决时长降低 30%，秒级自动创建工单节省了坐席 70% 的后处理时间。某全国连锁便利店通过智能工单的多模板、SLA 监控和流程派发能力，工单处理时长降低 25%，工单创建时间从 1 分钟缩短至 10 秒。这两组效果数字均来自对应行业的公开案例，不代表所有项目的普遍结果，实际效果取决于业务场景、配置质量和系统接口条件。
从混合到分流：评估工单自动分类的切入点
对于正在考虑工单自动分类的企业，建议从三个维度评估当前是否适合启动：
请求结构是否清晰。当前客服收到的请求中，能否明确区分出几类核心问题类型？分类边界越清晰，规则配置的准确性越高。
高频场景是否可枚举。是否有 1-2 个请求量最大、问题类型最明确的场景可以先跑通？从高频场景起步，验证分类准确率和派发效率，再逐步扩展到低频场景。
业务流程是否支持配置。处理部门、SLA 时限、闭环条件等业务规则是否已有明确要求？如果业务规则本身在频繁变化，自动分类和路由的收益会被维护成本抵消。
工单自动分类和路由不是一个独立的功能开关，而是意图识别、流程编排和工单规则引擎的组合结果。把三类请求的识别条件、字段要求和派发规则逐一明确后，系统才能真正做到"同类请求走同类流程"。合力亿捷的工单体系和 MPaaS 流程编排支持企业按自身业务场景配置分类规则和派发路径，从高频场景开始，逐步扩展覆盖更多问题类型。
