先讲一个客服主管每天都会头疼的场景。下午两点客服小张收到一条用户消息“我的系统登录不上一直提示密码错误急”小张复制用户ID打开工单系统新建一张工单手动填写问题类型“登录问题”优先级“高”然后切换到另一个后台查用户信息再复制粘贴到工单描述里。提交后工单进入待分配池。运维主管老李每隔半小时刷新一次待分配池看到新工单根据问题类型和当前各工程师的负载手动指派给小王。小王收到通知开始处理。处理完后小王在工单里写解决方案提交小张再通知用户“已解决”。这一套流程走下来从用户提问到工程师接手平均耗时47分钟。其中真正干活的时间不到10分钟剩下的全花在“传话”和“等待分配”上。后来我们给客服团队配了一个智能工单Agent。现在用户发来“登录不上”Agent自动创建工单、自动分类、自动派单给最合适的工程师全程无人干预。用户提问到工程师收到通知从47分钟压缩到了90秒。这篇文章我把这个端到端自动化工单系统拆给你看怎么自动创建、怎么智能分类、怎么自动派单、以及怎么保证派单不乱套。一、传统工单系统的三个“堵点”在动手改造之前我们先分析一下传统流程为什么慢环节操作耗时谁在做创建工单复制用户信息、手动填表单3-5分钟客服分类打标判断问题类型、选优先级1-2分钟客服分配工单查看工程师负载、手动指派10-30分钟轮询周期主管通知工程师发消息、等确认1-2分钟系统核心问题每个环节都在等人——等客服有空、等主管刷新、等工程师看到通知。而Agent可以做到“不等”。二、Agent的端到端流程5步90秒我们的Agent把工单流程拆成了5个自动执行的步骤不需要任何人中途点击或刷新。用户消息 → Agent接收 → 自动创建工单 → 自动分类 → 自动派单 → 通知工程师下面逐条拆解。2.1 自动创建从“人工填表”到“信息提取”用户发来消息时往往是不规范的“上不去系统了”“密码错误”“APP闪退”。客服以前需要把这些口语翻译成工单字段。Agent用LLM做信息提取直接从用户消息中抽取出结构化数据用户消息Agent提取“我的系统登录不上一直提示密码错误”问题类型登录问题现象密码错误“订单#12345一直显示处理中两个小时了”问题类型订单异常关联订单号12345“APP一打开就闪退手机是iPhone15”问题类型客户端崩溃设备iOS提取完成后Agent调用工单系统的创建API自动填好所有字段。客服全程不参与。关键设计如果LLM提取的信息置信度低比如用户只说“出错了”没有具体描述Agent不会瞎猜而是主动反问“请问具体是什么问题登录问题还是功能异常”收集到足够信息后再创建工单。2.2 智能分类规则模型双保险工单分类决定了“谁来处理”。分错了派单就错了问题会来回转手。我们用了双层分类第一层规则匹配。关键词命中如“密码”“登录” → 登录问题“退款”“金额” → 财务问题。速度快准确率高覆盖约60%的工单。第二层LLM分类。规则匹配不上的交给LLM判断。LLM输出分类和置信度。置信度低于80%的不自动派单标记为“待人工分类”进入兜底队列。同时我们设了一个优先级自动计算规则“紧急”“马上”“不能用了” → 高优先级“建议”“后续”“问问” → 低优先级其他 → 普通优先级客服主管可以自定义这些关键词和阈值。2.3 自动派单不是“轮询”而是“最合适的人”派单是传统流程里最耗时的环节。主管要查看每个工程师的当前工单数、技能匹配度、是否在休假然后手动选人。Agent的派单逻辑基于实时可用性技能匹配def assign_engineer(ticket): candidates [] for eng in all_engineers: if ticket.category not in eng.skills: continue # 技能不匹配跳过 if eng.is_on_vacation or eng.is_offline: continue # 不在线跳过 # 计算综合得分技能匹配度 当前负载(工单数) 历史解决速度 score ( skill_match_score * 0.5 (1 - eng.active_tickets / max_load) * 0.3 eng.avg_resolution_time_score * 0.2 ) candidates.append((eng, score)) if candidates: return max(candidates, keylambda x: x[1])[0] else: return None # 无人可派通知主管实际运行中这个算法能把工单派给“会做不忙做得快”的人而不是简单轮询或随机。派单后的确认Agent派单后不是直接“锁死”而是先发给工程师一条确认消息“新工单#12345登录问题已分配给你是否接单”工程师可以点“接单”或“拒绝”。拒绝后Agent重新派给下一个人。这样既自动化又保留了人的选择权。2.4 通知与跟踪不让工单“沉下去”工程师接单后Agent做三件事在工单系统里更新状态为“处理中”在工程师的IM上推送一条卡片包含用户信息、问题描述、历史记录设置一个SLA计时器如普通工单4小时内解决高优先级2小时内如果工单接近SLA时限仍未解决Agent自动工程师提醒“工单#12345剩余30分钟超时请尽快处理。”如果超时仍未解决Agent升级通知给主管。2.5 闭环反馈解决后自动通知用户工程师在工单里填写解决方案后Agent做最后一步从工单系统读取解决方案生成一条用户友好的回复“您的问题已解决。解决方案密码已重置请使用临时密码登录后修改。”通过原渠道IM、邮件、短信发送给用户关闭工单用户不需要再追问“解决了吗”客服也不需要再转发消息。整个流程从用户提问到用户收到解决方案全程由Agent驱动。三、一个完整的端到端案例让我们用一个真实工单走一遍流程。14:00:00- 用户发消息“登录不了系统了一直提示密码错误我急着提交报告”14:00:05- Agent接收消息提取信息{ category: login_issue, priority: high, description: 密码错误提示无法登录, urgency_keywords: [急着] }14:00:08- Agent创建工单#67890自动分类“登录问题”优先级“高”。14:00:10- Agent查询工程师列表小王擅长登录问题当前2个工单→ 得分92小李擅长登录问题当前5个工单→ 得分78小张不擅长登录问题→ 跳过14:00:12- Agent派单给小王推送消息“新工单#67890高优先级已分配请接单。”14:00:15- 小王点“接单”Agent更新工单状态为“处理中”。14:05:00- 小王重置用户密码在工单里填写“密码已重置临时密码发送至用户邮箱。”14:05:10- Agent读取解决方案生成回复“您的问题已解决。密码已重置临时密码已发送至您的注册邮箱zhang***company.com请登录后修改。”发送给用户。14:05:15- Agent关闭工单记录SLA达标从创建到解决耗时5分15秒远低于2小时阈值。用户视角发了一条消息5分钟后收到“已解决”的通知。中间没有任何等待和追问。传统流程用户发消息 → 客服等有空才处理假设10分钟→ 客服创建工单5分钟→ 主管等轮询假设30分钟→ 主管派单2分钟→ 工程师处理10分钟→ 客服通知用户2分钟。总计约59分钟。Agent提升从59分钟压缩到5分钟效率提升12倍。四、三个必须避开的坑坑1自动派单派给了“最闲但不合适”的人早期算法只看了“当前工单数”结果把复杂的数据库问题派给了最闲的前端工程师。他接单后发现不会修只能拒单工单重新排队。解决派单算法加入技能匹配权重占50%以上。工程师的技能标签由主管维护每周更新一次。同时记录历史派单数据如果某个工程师连续拒单同一类问题算法自动降低该类问题的匹配分数。坑2用户一句话创建了多个重复工单用户连续发了三条消息“登录不上”“还是不行”“有人吗”。Agent每条都创建了工单结果同一个问题产生了3个工单。解决会话去重机制。同一用户、同一会话5分钟内如果已有“处理中”的同类工单新消息不再创建新工单而是追加到原工单的描述里。坑3LLM分类把“投诉”误判为“功能咨询”用户说“你们的APP太难用了”本意是投诉但LLM分类成了“功能咨询”派给了产品组而不是客服主管。解决引入情感分析作为分类的辅助特征。负面情感强烈的消息如包含“差评”“垃圾”“投诉”强制归入“投诉”类别派给专人处理。五、你也可以从两个能力开始如果你现在就想做智能工单不需要一步到位。从最痛的两个能力开始自动创建自动分类只做“从用户消息到工单系统”不做自动派单。工单创建后仍由主管手动指派。这一步能省掉客服的手工填单时间3-5分钟/单。自动派单等分类准确率稳定在90%以上后再加自动派单。一开始只派低优先级工单高优先级的仍走人工审核逐步建立信任。每加一个能力先观察一周的准确率。如果派错率超过5%就别全自动先做半自动Agent建议派给谁人点确认。写在最后工单的终点不是“已解决”是“用户满意”智能工单Agent上线三个月后客服主管告诉我一组数据平均响应时间用户发消息到工程师接单从47分钟降到2分30秒用户满意度评分从4.2分提升到4.8分满分5分客服团队每天用于“填单、跟单”的时间从4小时降到30分钟最让我意外的是工程师的反馈。他们说“以前每天要刷好几次工单池看看有没有分给我的。现在不用刷了Agent会直接告诉我。我只需要专心解决问题。”智能工单的本质不是让客服失业而是让所有人回到自己最擅长的位置上客服去理解用户的情绪工程师去解决技术难题主管去优化流程和团队能力。而填单、分类、派单、通知这些“跑腿活”统统交给Agent。下次你的客服团队又在手动复制粘贴用户信息时不妨问问他们想不想让一个Agent替你们跑腿答案大概率是想。
用办公Agent实现智能工单：从客服请求到指派工程师的端到端自动化
发布时间：2026/5/30 2:01:07
先讲一个客服主管每天都会头疼的场景。下午两点客服小张收到一条用户消息“我的系统登录不上一直提示密码错误急”小张复制用户ID打开工单系统新建一张工单手动填写问题类型“登录问题”优先级“高”然后切换到另一个后台查用户信息再复制粘贴到工单描述里。提交后工单进入待分配池。运维主管老李每隔半小时刷新一次待分配池看到新工单根据问题类型和当前各工程师的负载手动指派给小王。小王收到通知开始处理。处理完后小王在工单里写解决方案提交小张再通知用户“已解决”。这一套流程走下来从用户提问到工程师接手平均耗时47分钟。其中真正干活的时间不到10分钟剩下的全花在“传话”和“等待分配”上。后来我们给客服团队配了一个智能工单Agent。现在用户发来“登录不上”Agent自动创建工单、自动分类、自动派单给最合适的工程师全程无人干预。用户提问到工程师收到通知从47分钟压缩到了90秒。这篇文章我把这个端到端自动化工单系统拆给你看怎么自动创建、怎么智能分类、怎么自动派单、以及怎么保证派单不乱套。一、传统工单系统的三个“堵点”在动手改造之前我们先分析一下传统流程为什么慢环节操作耗时谁在做创建工单复制用户信息、手动填表单3-5分钟客服分类打标判断问题类型、选优先级1-2分钟客服分配工单查看工程师负载、手动指派10-30分钟轮询周期主管通知工程师发消息、等确认1-2分钟系统核心问题每个环节都在等人——等客服有空、等主管刷新、等工程师看到通知。而Agent可以做到“不等”。二、Agent的端到端流程5步90秒我们的Agent把工单流程拆成了5个自动执行的步骤不需要任何人中途点击或刷新。用户消息 → Agent接收 → 自动创建工单 → 自动分类 → 自动派单 → 通知工程师下面逐条拆解。2.1 自动创建从“人工填表”到“信息提取”用户发来消息时往往是不规范的“上不去系统了”“密码错误”“APP闪退”。客服以前需要把这些口语翻译成工单字段。Agent用LLM做信息提取直接从用户消息中抽取出结构化数据用户消息Agent提取“我的系统登录不上一直提示密码错误”问题类型登录问题现象密码错误“订单#12345一直显示处理中两个小时了”问题类型订单异常关联订单号12345“APP一打开就闪退手机是iPhone15”问题类型客户端崩溃设备iOS提取完成后Agent调用工单系统的创建API自动填好所有字段。客服全程不参与。关键设计如果LLM提取的信息置信度低比如用户只说“出错了”没有具体描述Agent不会瞎猜而是主动反问“请问具体是什么问题登录问题还是功能异常”收集到足够信息后再创建工单。2.2 智能分类规则模型双保险工单分类决定了“谁来处理”。分错了派单就错了问题会来回转手。我们用了双层分类第一层规则匹配。关键词命中如“密码”“登录” → 登录问题“退款”“金额” → 财务问题。速度快准确率高覆盖约60%的工单。第二层LLM分类。规则匹配不上的交给LLM判断。LLM输出分类和置信度。置信度低于80%的不自动派单标记为“待人工分类”进入兜底队列。同时我们设了一个优先级自动计算规则“紧急”“马上”“不能用了” → 高优先级“建议”“后续”“问问” → 低优先级其他 → 普通优先级客服主管可以自定义这些关键词和阈值。2.3 自动派单不是“轮询”而是“最合适的人”派单是传统流程里最耗时的环节。主管要查看每个工程师的当前工单数、技能匹配度、是否在休假然后手动选人。Agent的派单逻辑基于实时可用性技能匹配def assign_engineer(ticket): candidates [] for eng in all_engineers: if ticket.category not in eng.skills: continue # 技能不匹配跳过 if eng.is_on_vacation or eng.is_offline: continue # 不在线跳过 # 计算综合得分技能匹配度 当前负载(工单数) 历史解决速度 score ( skill_match_score * 0.5 (1 - eng.active_tickets / max_load) * 0.3 eng.avg_resolution_time_score * 0.2 ) candidates.append((eng, score)) if candidates: return max(candidates, keylambda x: x[1])[0] else: return None # 无人可派通知主管实际运行中这个算法能把工单派给“会做不忙做得快”的人而不是简单轮询或随机。派单后的确认Agent派单后不是直接“锁死”而是先发给工程师一条确认消息“新工单#12345登录问题已分配给你是否接单”工程师可以点“接单”或“拒绝”。拒绝后Agent重新派给下一个人。这样既自动化又保留了人的选择权。2.4 通知与跟踪不让工单“沉下去”工程师接单后Agent做三件事在工单系统里更新状态为“处理中”在工程师的IM上推送一条卡片包含用户信息、问题描述、历史记录设置一个SLA计时器如普通工单4小时内解决高优先级2小时内如果工单接近SLA时限仍未解决Agent自动工程师提醒“工单#12345剩余30分钟超时请尽快处理。”如果超时仍未解决Agent升级通知给主管。2.5 闭环反馈解决后自动通知用户工程师在工单里填写解决方案后Agent做最后一步从工单系统读取解决方案生成一条用户友好的回复“您的问题已解决。解决方案密码已重置请使用临时密码登录后修改。”通过原渠道IM、邮件、短信发送给用户关闭工单用户不需要再追问“解决了吗”客服也不需要再转发消息。整个流程从用户提问到用户收到解决方案全程由Agent驱动。三、一个完整的端到端案例让我们用一个真实工单走一遍流程。14:00:00- 用户发消息“登录不了系统了一直提示密码错误我急着提交报告”14:00:05- Agent接收消息提取信息{ category: login_issue, priority: high, description: 密码错误提示无法登录, urgency_keywords: [急着] }14:00:08- Agent创建工单#67890自动分类“登录问题”优先级“高”。14:00:10- Agent查询工程师列表小王擅长登录问题当前2个工单→ 得分92小李擅长登录问题当前5个工单→ 得分78小张不擅长登录问题→ 跳过14:00:12- Agent派单给小王推送消息“新工单#67890高优先级已分配请接单。”14:00:15- 小王点“接单”Agent更新工单状态为“处理中”。14:05:00- 小王重置用户密码在工单里填写“密码已重置临时密码发送至用户邮箱。”14:05:10- Agent读取解决方案生成回复“您的问题已解决。密码已重置临时密码已发送至您的注册邮箱zhang***company.com请登录后修改。”发送给用户。14:05:15- Agent关闭工单记录SLA达标从创建到解决耗时5分15秒远低于2小时阈值。用户视角发了一条消息5分钟后收到“已解决”的通知。中间没有任何等待和追问。传统流程用户发消息 → 客服等有空才处理假设10分钟→ 客服创建工单5分钟→ 主管等轮询假设30分钟→ 主管派单2分钟→ 工程师处理10分钟→ 客服通知用户2分钟。总计约59分钟。Agent提升从59分钟压缩到5分钟效率提升12倍。四、三个必须避开的坑坑1自动派单派给了“最闲但不合适”的人早期算法只看了“当前工单数”结果把复杂的数据库问题派给了最闲的前端工程师。他接单后发现不会修只能拒单工单重新排队。解决派单算法加入技能匹配权重占50%以上。工程师的技能标签由主管维护每周更新一次。同时记录历史派单数据如果某个工程师连续拒单同一类问题算法自动降低该类问题的匹配分数。坑2用户一句话创建了多个重复工单用户连续发了三条消息“登录不上”“还是不行”“有人吗”。Agent每条都创建了工单结果同一个问题产生了3个工单。解决会话去重机制。同一用户、同一会话5分钟内如果已有“处理中”的同类工单新消息不再创建新工单而是追加到原工单的描述里。坑3LLM分类把“投诉”误判为“功能咨询”用户说“你们的APP太难用了”本意是投诉但LLM分类成了“功能咨询”派给了产品组而不是客服主管。解决引入情感分析作为分类的辅助特征。负面情感强烈的消息如包含“差评”“垃圾”“投诉”强制归入“投诉”类别派给专人处理。五、你也可以从两个能力开始如果你现在就想做智能工单不需要一步到位。从最痛的两个能力开始自动创建自动分类只做“从用户消息到工单系统”不做自动派单。工单创建后仍由主管手动指派。这一步能省掉客服的手工填单时间3-5分钟/单。自动派单等分类准确率稳定在90%以上后再加自动派单。一开始只派低优先级工单高优先级的仍走人工审核逐步建立信任。每加一个能力先观察一周的准确率。如果派错率超过5%就别全自动先做半自动Agent建议派给谁人点确认。写在最后工单的终点不是“已解决”是“用户满意”智能工单Agent上线三个月后客服主管告诉我一组数据平均响应时间用户发消息到工程师接单从47分钟降到2分30秒用户满意度评分从4.2分提升到4.8分满分5分客服团队每天用于“填单、跟单”的时间从4小时降到30分钟最让我意外的是工程师的反馈。他们说“以前每天要刷好几次工单池看看有没有分给我的。现在不用刷了Agent会直接告诉我。我只需要专心解决问题。”智能工单的本质不是让客服失业而是让所有人回到自己最擅长的位置上客服去理解用户的情绪工程师去解决技术难题主管去优化流程和团队能力。而填单、分类、派单、通知这些“跑腿活”统统交给Agent。下次你的客服团队又在手动复制粘贴用户信息时不妨问问他们想不想让一个Agent替你们跑腿答案大概率是想。
