官网友情链接 wechatapi.net
个人微信二次开发做多人工作台时，消息往往会展示：
未读；
已读。
这对于普通聊天软件足够，但对企业客服来说远远不够。
因为一个客服打开客户会话，只能说明：
有人看过。
并不代表：
有人认领；
有人回复；
问题解决。
如果系统把“已读”当成“已处理”，其他客服可能就不会再关注这条消息。
于是客户明明消息已经显示已读，却一直没人真正处理。
所以微信二次开发中的阅读状态和业务处理状态必须彻底分开。
WechatApi 可以作为个人微信API接入层，把客户消息和员工回复带入系统。本地工作台则分别维护未读、查看、认领、处理、回复和关闭状态。
一、消息已读到底是谁读的
不能只有：
is_read = true。
更有价值：
read_by；
read_at。
多人工作台可以知道：
客服A看过。
但当前owner仍然为空。
说明还没人正式接管。
二、一个具体例子
客户10:00发：
“付款以后还是无法使用。”
客服A10:01打开会话。
系统：
read_by=A。
A随后去处理另一个紧急问题，没有认领。
客户消息状态：
已读；
待认领。
客服B在公共队列仍然能看到：
需要处理。
不会因为A看过就消失。
三、WechatApi 在这里的位置
WechatApi负责：
客户新消息；
员工回复。
阅读状态是本地工作台概念。
不要和微信侧消息状态混在一起。
四、阅读状态和责任状态
read_status：
unread/read。
service_status：
pending/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 可以把客户微信消息持续送进业务系统。
本地工作台通过阅读状态、认领状态、处理状态和回复状态分层，让公共队列不会因为某个客服随手打开会话就把客户问题从其他人视野里消失。
真正可靠的客服系统必须知道：谁看过、谁负责、谁回复、问题是否解决。
只有这几个概念分开，客户才不会出现“后台早就显示已读，但实际一直没人处理”的情况。
