接诉即办服务规划

更新时间：2026-06-01

1. 背景理解

12345 政务服务便民热线是群众和企业表达咨询、求助、投诉、举报、建议等诉求的统一入口。各地"接诉即办"通常围绕受理、派单、办理、回复、督办、办结、回访、评价、归档形成闭环，并以响应率、解决率、满意率等指标评价承办单位办理质量。

北京地区接诉即办工作对考核结果非常重视，除常规办理质量外，还存在不计入考核事项、剔除申请等专门规则。对街道和社区而言，能否把诉求办实、把回复写准、把佐证材料留全，以及在符合规则时说明不计入考核理由，都会直接影响工作结果。

对基层社区、街道和科室而言，接诉即办的核心压力不只是"写材料"，而是要在有限时间内完成事实核查、政策匹配、历史类案参考、办理路径判断、证据留存、回复口径组织和考核风险控制。AI 服务的价值应优先落在个人减负、办理提质和降低失分风险上，后续再基于使用数据沉淀做统计分析、主动治理等能力。

2. 当前已知情况

2.1 产品与载体

  • 社小智：ToC 产品，接诉即办能力在界面中体现较完整（含 H5、PC 等多端）。
  • 基层治理 AI：ToB 产品，面向社区书记、社工及街道主任、科室等内部人员；能力正在从少到多补充进现有产品。
  • 小程序现状：不改变既有 chat 交互。用户在 chat 页点击「诉办通」，当前仅有两个服务按钮：诉求分析、法律法规（对应原办件思路、法律法规能力）。
  • 街道 PC：已有档案馆、历史工单上传等能力，部分资料能力后续在小程序侧按需调用；居民台账（包含走访记录）两端都有，可支撑接诉即办产品调用数据。

2.2 规划补齐目标

我司接诉即办完整能力包括：诉求分析（办件思路）、法律法规、办件回复、剔除文书、佐证审核（亦称附件检查）。目标是把适合的能力补充进基层治理 AI 小程序；其中剔除文书一期暂不上，是否纳入后续建设放入待定问题。

2.3 近期数据观察

统计周期为 2026-05-01 至 2026-05-28。

整体基本情况：社小智微信访问人数 4340、微信打开次数 7460；基层治理 AI 微信访问人数 572、微信打开次数 1551。
社小智 PC页面访问深度明显更高：人数 3546，打开次数约 25636。
社小智接诉即办页面次数 2795、接诉即办 pro 1286，接诉即办服务次数（按用户发起约数）约 1393。
基层治理 AI 的接诉即办服务次数约 46，其中办件思路 23、法律法规 4。
数据口径不一致，微信、PC、小程序、页数与咨询次数之间不可直接比较。

3. 产品定位

3.1 近期定位

在不改变现有 chat 交互的前提下，面向社区工作者（一期主用户）补齐诉办通内的接诉即办 AI 能力，先解决个人办件减负和提质：

  • 更快理解诉求、形成办理思路（结合历史工单、居民台账、走访记录及档案馆资料辅助办件）。
  • 匹配法规政策依据。
  • 生成办理回复等文书。
  • 审核图片、录音等佐证材料。
  • 增加多轮交流能力，方便多维度完成咨询辅助。

3.2 中期定位

  • 继续沿用 chat +「诉办通」按钮的方式，由同一个综合调度 Agent 承接入口并按需调用具体能力，不另做独立接诉即办工作台形态（小程序侧）。
  • 形成单位内资料共享与复用：社区内共享；街道与科室按单位边界使用工单与资料（跨社区/街道调用规则见待定问题）。
  • 支持将档案馆整体或指定文件夹作为当前部门知识库，供法律法规、办件思路等 Agent 检索引用。
  • 在有一定使用数据后，对比基层治理 AI（chat + 按钮调 Agent）与社小智（界面功能模块提供服务）在访问人数、调用次数、连续会话、人均使用等方面的差异，为后续是否调整呈现方式提供依据。

3.3 长期定位

在使用数据触达和稳定后，结合中期使用结果，建设统计分析、失分工单分析、重复诉求识别、区域问题画像和主动治理建议等能力（见未来需求）。

4. 服务流程

  1. 用户进入 chat 页面，点击「诉办通」。
  2. 在诉办通服务区选择能力按钮（当前：诉求分析、法律法规；规划补充：回复、佐证审核、历史工单查询等）。
  3. 几个按钮调用同一个综合调度 Agent，按钮名称/按钮要求随首轮请求一起发送，方便综合调度 Agent 判断用户当前意图并按需调用具体能力。
  4. 用户围绕同一工单（直到用户点击诉办通）在同一对话中继续输入：补充案情、追问、要求生成或修改回复文书、上传或引用材料等；后续对话不再裹挟按钮信息，由综合调度 Agent 按语义主动分流。
  5. 用户重新点击「诉办通」时，按开启新话题处理（与「新对话」等现有能力配合，具体以实现为准），用户如从历史对话里选择进入则继续对话。
  6. 需要材料时，可走本地上传、微信上传、从档案馆选取等已有能力。
flowchart TD
  user["社区工作者"] --> chat["基层治理AI chat页面"]
  chat --> suban["诉办通按钮区"]
  suban --> dispatcherAgent["综合调度Agent"]
  dispatcherAgent --> analysisAgent["诉求分析Agent"]
  dispatcherAgent --> lawAgent["法律法规Agent"]
  dispatcherAgent --> replyAgent["回复文书Agent"]
  dispatcherAgent --> evidenceAgent["佐证/附件审核Agent"]
  dispatcherAgent --> historyAgent["历史工单查询Agent"]
  historyAgent --> oldCases["历史工单"]

5. 必做需求

5.1 连续交流（诉办通内主agent）

综合调度 Agent：诉办通按钮均进入同一个综合调度 Agent。首轮携带按钮要求用于分流，后续按用户语义和上下文主动调用诉求分析、法律法规、回复、附件检查、历史工单查询等能力。
  • 将当前诉求分析、法律法规等一次性问答改为连续会话；同一轮诉办通使用中，很可能基于一个工单依次完成分析、查法规、写回复、检查附件并继续追问。
  • 连续会话能力暂定不少于 10 轮（以产品实现为准）。
  • 用户重新点击诉办通时开启新话题。
  • 诉办通内几个按钮调用同一个综合调度 Agent；首轮请求将按钮名称/按钮要求与用户输入一起发送，便于综合调度 Agent 分流到诉求分析、法律法规、回复、附件检查、历史工单查询等能力。
  • 后续连续对话不再裹挟按钮信息，综合调度 Agent 按用户语义和上下文主动判断是否调用其他 Agent 能力；不分流到其他agent的，则在本agent做兜底分流继续chat，这个分流需包含查询法律数据库节点和助手角色定位。
  • 不做办件箱、不做工单状态。
  • 社工使用为准，看开发时间安排，如给街道科室使用，agent基本一致，在提示词里做定位的强调区别；在界面上给街道科室提供诉办通按钮点击进入chat页面。

5.2 办件思路

诉求分析 Agent：输出投诉点、办理思路、风险点、沟通话术和证据建议；同类型人员特征分析优先使用手机号查到的真实历史数据。
  • 输入工单/诉求内容后，输出投诉点归纳、办理方向、步骤清单、沟通话术及办理风险提示。
  • 结合历史工单、居民台账、走访记录参考。
  • 对"同类型工单诉求案件相关人员特征分析"，如果能通过手机号查询到历史工单、居民台账、走访记录等真实信息，应基于真实数据进行分析；如果没有查询到相关信息，则仍按原办件思路 Agent 的方式输出一般性特征分析。
  • 对多部门、超职责、重复投诉、情绪或舆情风险等情形给出提示。

5.3 法律法规

法律法规 Agent：匹配法规、政策、地方规定，优先引用本地知识库，避免编造依据。
  • 按诉求匹配法规、政策、地方规定。
  • 支持在连续会话中追问依据是否充分、如何通俗解释等。
  • 优先使用本地知识库；Agent 侧限制引用来源，避免编造依据（基本没变）。

5.4 办件回复

回复 Agent：生成热线平台办理回复，结合朝阳区简要回复要求和原回复文书 Agent 能力。

5.5 办件附件检查

附件检查 Agent：用多模态能力检查图片、录音、文档等材料，输出审查结果和风险提示。
  • 支持本地、微信上传及从档案馆选择图片、录音、文档，一个不超过20M一次不超过30个，可再向下限制。
  • 输出审查结果及风险提示；与回复等能力在同一 chat 上下文中使用。
  • 需要用多模态大模型，图片vision读图能力，审查点可提供初级版本。

5.6 历史工单查询

历史工单查询 Agent：支持自然语言查询历史工单，按电话、类型、内容、点位等字段归纳相似案例和历史办理过程。
  • 直接用自然语言查询历史工单。结果为空则输出要求导入工单的安慰话语，并给出路线指引。
  • 可包括：诉求人电话、工单类型、工单内容、点位等已有字段。
  • AI 可归纳历史办理过程、相似案例与重复诉求可能。
  • 权限按单位控制（非简单行政区划向下穿透；例如街道科室不能直接看社区数据，具体见待定需求）。

5.7 工单历史上传与单位内管理

  • 单位维度上传、查看、管理、删除及被 Agent 调用查询。
  • 社区内资料共享；街道与科室工单在单位内共享（街道上传资料社区是否可调用，待定）。
  • 删除进回收站，可恢复与彻底删除（如原先没有，看情况安排，也可第二期处理）。

5.8 数据与记录

  • 沿用历史工单已有库表、老数据及既有维护功能。
  • 记录 AI 服务使用次数、人次及每次输入、输出、反馈，便于评估效果，以及和社小智对比。

6. 待定问题

以下事项需在实施前或试点中继续拍板：

议题 说明
剔除需求是否做 一期暂不上剔除文书；后续是否做、做到什么深度、是否接入北京/朝阳不计入考核规则，需要单独确认。
库表是否统一 历史工单是否共用一套维护/存储机制，还是各用各表、仅在检索或 Agent 调用层打通。
跨单位调用 社区能否使用街道上传的工单/资料；街道能否使用社区资料；科室与社区、街道边界如何划。
统计与盒子 统计分析、个性化大屏、本地盒子等是否作为增值包或单独采购。

7. 未来需求

  • 统计分析与管理驾驶舱：高频/重复诉求、热点、三率相关分析、多层级看板等。
  • 失分工单分析：归因、复盘、相似工单预警；数据来源可为历史工单库、上传文件、档案馆等组合。
  • 主动治理建议：从诉求数据中识别共性问题并输出治理建议。
  • PC 端接诉即办：是否在 PC 沿用 chat + 按钮，或另做界面；PC 侧重档案与批量管理，小程序侧重移动办件与采集。
  • 二期类 Agent：质检复核、失分分析、统计报告等（在数据与规则成熟后）。

8. 一期验收指标建议

  • 使用指标：诉办通入口访问人数、各按钮服务调用次数、人均使用次数、连续会话轮次分布。
  • 能力指标：综合调度是否能按首轮按钮要求和后续语义正确分流；诉求分析、法规、回复、附件检查、历史工单查询是否能完成基本任务。
  • 试点目标：使用次数、使用人数达到预期即视为一期触达有效；后续再扩展质量与业务类指标。

附录：诉办通新按钮示意图

以下为诉办通规划新增按钮示意。上方两枚为现有按钮（诉求分析、法律法规），虚线框三枚为一期规划补充（办件回复、办件附件检查、历史工单查询）。所有按钮均进入同一综合调度 Agent，由 chat 页「诉办通」入口调起。

19:55●●● ▮ WiFi 🔋
☰ + 新对话
诉办通 🕐 咨询记录
👤诉求分析
📄法律法规
✍️办件回复
📎办件附件检查
🔍历史工单查询
＋输入问题或需求…