把群聊需求转成业务工单，建议采用“明确触发、整理待确认项、正式受理、按工单状态回群”的流程。群消息保留原话，工单承载对象、负责人、进度与结果。适合报修、数据纠错、资料补充和实施支持等有明确交付内容的工作。
设计时先选一类需求与一个对应工单系统。每个群都自动接收所有消息，会带来范围和重复问题；应明确哪些群、哪些触发方式、哪些业务类型可以进入受理流程。
请求与讨论的区分
“这个报表能不能加一列”可能在讨论可行性，“请给本月报表补上部门列”才进一步明确了动作。Agent 可以提取候选需求，但不应把讨论语气自动升级成已经批准的改动。
推荐入口是指定指令、明确提及助手或由人员选取消息转单。收到后先给出简短的确认摘要：处理对象、期望结果、需要补充的内容，以及拟进入的业务队列。对需求影响大的缺项优先追问，无需把整份表单一次丢给发起人。
| 群内内容 | 受理处理 | 工单记录方式 |
|---|---|---|
| 可行性咨询 | 提供说明或转咨询队列 | 不默认创建执行工单 |
| 明确问题与对象 | 整理需求并补必要字段 | 建立待确认记录 |
| 补充图片或数据 | 关联已有话题和工单 | 作为追加材料 |
| 催问处理进度 | 查询对应工单 | 返回当前状态与下一动作 |
| 提出取消或改范围 | 提交变更请求 | 保留原需求和变更记录 |
工单字段与消息关联
工单至少需要来源群、原消息标识、发起人、业务对象、问题描述、期望结果、受理队列和处理负责人。时间要求应区分“发起人期望”与“受理后承诺”，不能把一句“最好今天完成”自动记成已经承诺的截止日。
原话与整理摘要分开保存。原话用于追溯，摘要便于执行；后续人员修改摘要时留版本，避免争议时只剩 Agent 改写后的意思。图片和文件保留与工单的关联，并检查处理人员是否能访问。
同一需求出现在多个群时，可关联同一工单，但各群仅同步适合该群查看的信息。群里有权提出请求，不代表所有成员都可以看到内部处理备注、账号资料或完整业务记录。
找不到明确负责人时，工单先进入有值班责任的受理队列，并在群里说明尚未分配到具体处理人。只有某位同事被提及，不能据此认定他已经接单。对需要多人配合的事项，指定一个负责推进的主工单，其他工作作为关联子项，群内仍使用主工单编号查询，避免同一需求出现多个互相矛盾的进度。
示例：门店库存显示异常
以下为设计示例：门店在运营群发出“商品示例-A 的可售数不对，请查一下”，并附截图。Agent 先确认门店编号、商品编号、截图时间，以及预期数量的依据，将问题整理为库存核对工单。
受理人员确认后，群里收到工单编号、负责队列和待补信息。另一位店员再次发同一张截图时，先提示已有相关工单，并把新说明追加到原单；若是不同仓库或另一天的问题，再由受理规则判断是否新建。
处理人员发现显示数据尚未更新，完成核对后附上查询时点与处理记录。门店确认页面恢复正常，工单按约定关闭，并回到原话题说明处理结果。若仅发出“已安排检查”，工单仍保持处理中。
状态同步与消息节制
建议只把受理、需补充、承诺变化、待确认结果和关闭等关键状态推回群。内部每次转派、每条技术备注不必逐条广播，员工问进度时再提供适当摘要。
状态以业务工单为准，群消息是展示入口。同步记录保留工单编号、状态版本和发送结果；旧状态晚到时，不应覆盖已经发布的新状态。发送失败只补发消息，不重新创建业务工单。
对已经关闭的工单再次收到问题，需要区分原问题未解决与新增问题。前者按规则复开，后者新建关联工单。不能看到相同关键词就永久合并，也不能每次催问都产生新任务。
受理规则与验收样本
联调时准备明确请求、模糊讨论、重复消息、跨群补充、附件不可访问、需求撤回和关闭后复开等样本。分别检查工单是否创建、是否重复、负责人是否可定位，以及群里显示的状态是否与业务系统一致。
组织共享任务的责任设计可参照公司级专职 Agent 与个人助手的区别；任务进入业务队列后的维护分工可结合企业 Agent 运营责任表。
准备实施这类需求受理流程时，可从企业 AI 落地服务梳理触发条件、工单字段、消息关联和状态同步范围，并用样本验证受理规则。
