官网友情链接 wechatapi.net个人微信二次开发做多人工作台时消息往往会展示未读已读。这对于普通聊天软件足够但对企业客服来说远远不够。因为一个客服打开客户会话只能说明有人看过。并不代表有人认领有人回复问题解决。如果系统把“已读”当成“已处理”其他客服可能就不会再关注这条消息。于是客户明明消息已经显示已读却一直没人真正处理。所以微信二次开发中的阅读状态和业务处理状态必须彻底分开。WechatApi 可以作为个人微信API接入层把客户消息和员工回复带入系统。本地工作台则分别维护未读、查看、认领、处理、回复和关闭状态。一、消息已读到底是谁读的不能只有is_read true。更有价值read_byread_at。多人工作台可以知道客服A看过。但当前owner仍然为空。说明还没人正式接管。二、一个具体例子客户10:00发“付款以后还是无法使用。”客服A10:01打开会话。系统read_byA。A随后去处理另一个紧急问题没有认领。客户消息状态已读待认领。客服B在公共队列仍然能看到需要处理。不会因为A看过就消失。三、WechatApi 在这里的位置WechatApi负责客户新消息员工回复。阅读状态是本地工作台概念。不要和微信侧消息状态混在一起。四、阅读状态和责任状态read_statusunread/read。service_statuspending/processing/resolved。两套状态完全独立。五、多人阅读主管、客服都可能打开。可以记录read_receipts。但工作台默认只展示当前负责人是否已查看。不要过度复杂。六、自动标记已读的风险页面预加载会话内容。用户实际没看。系统却标已读。更合理真正进入会话区域后标记。或者停留一定时间。这属于前端交互细节但影响业务准确性。七、未读计数客服A的未读和客服B的未读不一样。如果是个人工作台可以按user维护。公共队列则更关注客户消息是否已被正式处理。八、机器人回复以后机器人自动解决FAQ。客户消息可以service_status resolved_by_bot。即使没有任何人工阅读。不要要求人工点开才算处理。九、人工接管客服认领以后。如果没读最新消息。工作台仍然提示owner unread 3。这样责任人知道还有新内容。十、群聊场景一个群里消息很多。不可能每条维护全员阅读。业务只对生成服务任务的重要消息维护处理状态。普通闲聊不进入客服阅读体系。十一、SLA首次查看不能停止SLA。只有有效响应或正式接管才影响相关时限。否则员工点开一下就能“完成响应”指标失真。十二、客户连续补充任务正在处理。客户又发新消息。负责人有new_unread_message。状态仍processing。不要创建全新待办。十三、通知负责人长时间没有查看最新高风险消息。可以提醒。但普通消息不要频繁通知。十四、数据看板平均首次查看首次认领首次回复已读未处理数量。“已读未处理”本身就是非常有价值的风险指标。十五、异常某客服大量会话已读但长期未处理。主管可以分析是否工作负载过高。不要简单用作惩罚指标要结合任务量。十六、权限主管可以查看团队已读/未处理。普通客服只看自己的工作台。十七、日志阅读行为不需要和操作审计一样永久高等级保存。但关键任务可以保存first_read_at。用于服务分析。十八、总结个人微信二次开发做多人客服时“有人看过消息”与“问题已经有人负责”绝不是一回事。WechatApi 可以把客户微信消息持续送进业务系统。本地工作台通过阅读状态、认领状态、处理状态和回复状态分层让公共队列不会因为某个客服随手打开会话就把客户问题从其他人视野里消失。真正可靠的客服系统必须知道谁看过、谁负责、谁回复、问题是否解决。只有这几个概念分开客户才不会出现“后台早就显示已读但实际一直没人处理”的情况。