企微客户群标准化运营与督导——产品开发文档

文档状态：方案初稿
版本：v0.1
日期：2026-07-18
适用项目：claude-code/claude-code-qiwe-assistant

1. 背景与问题

企业客户群目前缺少公司级运营标准，群运营依赖门店员工个人经验，导致：

没有统一的群运营 SOP、服务话术和内容节奏；
总部无法知道门店是否执行、执行质量如何；
没有专门运营团队，店员需要从零策划和撰写内容；
客户问题、购买信号和投诉可能无人响应；
不同门店服务质量差异大，无法复制优秀经验；
群数量增长后，管理者无法逐群查看和督导。

现有系统已具备群发现、群确认、群消息同步、单聊 Agent、人工审核、任务、预警和审计能力，但尚未形成以下业务闭环：

flowchart LR
  A["总部制定标准"] --> B["按群生成运营计划"]
  B --> C["门店审核并执行"]
  C --> D["同步群消息与执行结果"]
  D --> E["自动质检与风险识别"]
  E --> F["生成整改任务与管理看板"]
  F --> A

2. 产品目标

建设“企微社群运营中心”，把总部运营标准转化为门店每天可执行的任务和话术，并通过群消息证据自动监督执行质量。

首期目标：

总部可以统一定义、发布和更新群运营 SOP、话术模板与运营节奏。
门店可以通过 Agent 对话快速获得“今天该做什么、该怎么说”。
所有外发内容默认经过人工确认，发送结果全程留痕。
系统按群自动检查执行、响应、风险和活跃度，生成有原消息依据的预警。
管理者可以在 Dashboard 查看跨门店、跨群的执行率、健康度、风险和待办。

2.1 成功指标

MVP 试点建议使用 3 家门店、20 个客户群、连续运行 14 天：

指标	目标
每日计划生成成功率	≥ 95%
到期运营任务执行率	≥ 85%
话术人工一次采纳率	≥ 70%
高风险消息召回率	≥ 85%
高风险误报率	≤ 10%
未回应问题识别准确率	≥ 90%
质检结论可追溯到原消息比例	100%
门店日均群运营准备时间下降	≥ 50%
未经人工确认的外发消息	0 条

2.2 非目标

MVP 暂不包含：

完全无人监管的自动群聊机器人；
自动决定促销价格、退款、赔偿或对客户作出业务承诺；
替代企业微信官方权限、合规审批和员工管理制度；
以 AI 主观判断销售业绩或员工绩效；
未经授权采集或长期保存客户敏感信息；
一开始建设复杂的营销自动化平台或多渠道 CRM。

3. 产品形态与功能拆分

建议对用户呈现一个统一产品模块“社群运营”，内部由四项能力组成。MVP 先建设一个 qiwei-group-operations skill，避免多个 skill 重复加载群上下文和产生路由冲突；规模扩大后再按职责拆分。

3.1 功能一：SOP 与话术标准中心

解决“公司无统一指导和标准”。

总部可维护：

群类型：新客群、成交服务群、售后群、会员群、活动群等；
生命周期：建群欢迎、需求了解、持续服务、活动转化、售后维护、沉默唤醒；
运营节奏：星期、时间段、频次、任务类型；
话术模板：欢迎、提醒、知识内容、活动、答疑、回访、投诉安抚；
必做项、禁止项、升级人工条件和响应 SLA；
适用门店、适用群标签、版本、生效日期和发布状态。

核心规则：

草稿版本不影响已执行计划；
发布新版本必须记录发布人、变更说明和生效时间；
每个计划项必须保存所依据的 SOP 版本，便于审计；
话术模板支持变量，但变量缺失时禁止发送，不允许把 {{customer_name}} 原样发出；
禁止词、敏感承诺和高风险场景采用确定性规则兜底，不仅依赖模型。

3.2 功能二：群运营 Copilot

解决“没有运营团队、店员不会策划和写话术”。

Agent 根据群类型、生命周期、最近消息、历史执行情况和当前 SOP，生成：

今日/本周运营计划；
每个计划项的建议时间、目标、话术草稿和执行说明；
针对当前群上下文改写后的个性化话术；
发送前风险检查和需要人工补充的变量；
门店员工的待办清单。

执行状态：

draft → pending_review → approved → sending → sent/failed → verified

另有 skipped 和 cancelled，必须记录原因。

发送策略：

MVP 默认“Agent 生成草稿 → 人工编辑/确认 → 执行发送”；
批量发送必须逐项展示目标群、最终内容、发送时间和风险检查；
同一计划项使用幂等键，避免重试导致重复发送；
高风险话术、投诉、退款、法律、隐私和价格承诺只能生成建议，不提供自动发送；
若真实发送接口未完成 live smoke，可退化为“复制话术 + 标记已执行”，不虚报已发送。

3.3 功能三：群质检与智能督导

解决“没有监督、服务质量参差不齐”。

系统基于同步的群消息和计划执行记录检查：

节奏执行：当天必做运营动作是否按时完成。
客户响应：客户的明确提问是否在 SLA 内得到有效回应。
服务风险：投诉、负面情绪、退款、敏感词、错误承诺和冲突升级。
运营质量：连续机械刷屏、重复内容、模板变量未替换、内容与群阶段不匹配。
群活跃信号：发言人数、互动率、连续沉默和异常退群；数据不完整时明确标记“暂不可评估”。

每条质检发现必须包含：

规则/模型判定类型；
严重程度；
原消息 ID、时间、发送者和证据片段；
采用的规则或 SOP 版本；
建议动作、负责人和截止时间；
处理状态与处理结果。

系统不直接用一个不可解释的总分评价员工。Dashboard 可以展示“群健康分”，但必须同时展示分项得分、数据覆盖率和证据。

建议初始评分：

分项	权重	计算原则
SOP 执行	30%	到期必做项按时完成比例
客户响应	30%	明确问题在 SLA 内获得有效回应比例
服务风险	25%	未处理高风险事件扣分，已闭环事件减轻扣分
群互动	15%	活跃成员和有效互动趋势，不鼓励单纯刷消息量

若某分项缺少可靠数据，应从有效权重中排除并显示覆盖率，不按 0 分处理。

3.4 功能四：总部运营 Dashboard

解决“无法规模化管理客户关系”。

新增一级导航“社群运营”，包含五个页签：

A. 运营总览

今日应执行、已完成、逾期、待审核数量；
运营任务执行率、响应 SLA 达标率、高风险未闭环数；
门店/账号/群类型对比；
群健康分布和数据覆盖率；
本周趋势与异常群 Top N；
只展示能够下钻到群、计划或原消息的数据。

B. 今日工作台

按紧急程度排列待审核话术、到期任务、失败发送和风险处理；
支持编辑、批准、拒绝、重新生成、复制和发送；
批量操作前展示影响范围和风险；
门店员工默认只看自己负责的群。

C. 群运营详情

群基本信息、负责人、门店、群类型、生命周期和标签；
当前 SOP 版本和未来 7 天运营日历；
消息时间线、执行记录、未回应问题和风险事件；
分项健康指标、数据覆盖率和原消息证据；
“让 Agent 生成计划”“生成下一条话术”“立即质检”入口。

D. SOP 与话术库

SOP 列表、版本、适用范围、启停和发布；
可视化节奏编辑器；
话术模板、变量、禁用词和风险规则；
发布前预览“哪些群会受到影响”；
版本 diff 和回滚。

E. 质检与预警

按严重程度、门店、群、负责人、类型、状态筛选；
查看证据、确认误报、分配负责人、创建待办、处理和关闭；
误报反馈进入评测集，不能直接无审计地修改历史结论。

4. Agent 对话能力设计

4.1 Skill 定位

建议新增：

skills/qiwei-group-operations/
├── SKILL.md
├── agents/openai.yaml
└── references/
    ├── data-model.md
    ├── quality-rules.md
    └── output-contracts.md

SKILL.md 只保留核心工作流、权限边界和工具选择；详细字段、质检规则和输出结构放入 references/，避免主 skill 过长。

建议触发场景：

“给新建的客户群做一个 7 天运营计划”；
“根据公司 SOP 写今天下午的群话术”；
“检查这 20 个群昨天有没有按要求运营”；
“找出超过两小时没人回复的客户问题”；
“汇总三家门店本周群运营情况”；
“把这条优秀话术保存为公司模板草稿”。

4.2 MCP 工具

首期建议提供 7 个面向业务的工具：

工具	作用	是否产生外部写操作
`qiwei_group_ops_get_context`	获取群、SOP、近期消息、计划和风险上下文	否
`qiwei_group_ops_generate_plan`	生成单群或批量群运营计划草稿	否
`qiwei_group_ops_generate_copy`	为指定计划项生成或改写话术	否
`qiwei_group_ops_review_messages`	对指定群和时间范围执行质检	否
`qiwei_group_ops_daily_brief`	汇总今日任务、逾期和风险	否
`qiwei_group_ops_manage_playbook`	创建草稿、更新、提交发布或回滚 SOP	发布/回滚需确认
`qiwei_group_ops_execute_item`	批准、拒绝、发送、重试、跳过计划项	发送需明确确认

工具返回继续沿用项目的标准结果信封，并增加稳定的业务字段：operationId、accountKey、roomId、evidence、requiresConfirmation、idempotencyKey 和 auditId。

4.3 对话工作流示例

用户：“给所有新客群安排明天的运营内容。”

Agent 应执行：

确认当前企微账号和用户可管理的群范围。
筛选 groupType=new_customer 且已绑定已发布 SOP 的群。
读取最近消息和未完成计划，防止内容重复或与群状态冲突。
生成计划草稿和每群话术，标出变量缺失与风险。
返回摘要：目标群数、跳过群数、待补信息、预计发送项数。
用户明确批准后才创建可执行计划；再次确认发送目标和最终内容后才外发。
写入发送结果和审计日志；失败可安全重试，不重复发送成功项。

5. 技术方案

5.1 可复用现有能力

现有能力	复用方式
`qiwei-group-management`	发现群、确认客户群、读取群详情、同步群消息
`qiwei-customer-ops`	客户档案、自动建群和欢迎语能力
Agent Workbench SQLite	复用任务、预警、审计和人工审核设计模式
Dashboard	复用账号切换、异步 job、Toast、筛选、分页和审计交互
Fmode 网关与 endpoint catalog	复用登录设备、鉴权、错误信封和群消息接口
Webhook / polling	复用增量消息入口，作为质检事实来源

5.2 必须先修正的底层问题

账号隔离：当前 outputs/groups/rooms-latest.json 等路径没有显式账号命名空间，多账号切换存在覆盖风险。新模块所有数据必须包含 account_key，文件缓存也应按账号分目录。
增量同步：当前按每个 room 从消息流起点扫描会重复消耗请求。应改为“每账号只增量拉取一次 → 按 fromRoomId 分流入库 → 保存游标”。
群会话模型：现有 conversations.contact_id 面向单聊。群运营应有独立群实体和群消息关系，不能把群 ID 伪装成客户 ID。
发送接口实测：catalog 中 /msg/sendGroupMsg 的摘要存在明显错配，不能仅凭 catalog 宣称可用。必须先对 /msg/sendText 和 /msg/sendGroupMsg 分别完成 sample/live smoke，并确认频控、回执和失败语义。
权限模型：Dashboard 当前主要是本地账号切换，新模块需要最小角色模型：总部管理员、区域/门店经理、执行员工、只读审计者。

5.3 逻辑架构

flowchart TB
  UI["Dashboard / Agent 对话"] --> API["Group Operations Service"]
  API --> PB["SOP 与话术版本服务"]
  API --> PLAN["计划与执行服务"]
  API --> QA["质检规则与 LLM 分类器"]
  API --> SEND["发送审批与幂等执行器"]
  SYNC["Webhook / 增量消息同步"] --> STORE[("Group Operations SQLite")]
  PB --> STORE
  PLAN --> STORE
  QA --> STORE
  SEND --> GATEWAY["Fmode WeCom Gateway"]
  GATEWAY --> SYNC
  STORE --> API
  API --> AUDIT["统一审计日志"]

MVP 可继续使用 Node 内置 SQLite，保持本地可部署；但数据访问必须封装为 service/store，不允许 Dashboard 路由直接拼 SQL，以便以后迁移 PostgreSQL 或多租户服务。

5.4 建议数据模型

表	关键字段	说明
`group_ops_groups`	`id, account_key, room_id, store_id, owner_id, group_type, lifecycle_stage, playbook_id, status`	群运营主档，`account_key + room_id` 唯一
`group_ops_playbooks`	`id, name, group_type, status, current_version_id, scope_json`	SOP 主记录
`group_ops_playbook_versions`	`id, playbook_id, version, content_json, change_note, created_by, published_at`	不可变版本快照
`group_ops_templates`	`id, version_id, scene, title, content, variables_json, risk_level`	话术模板
`group_ops_plans`	`id, account_key, room_id, plan_date, playbook_version_id, status, generated_by`	每群每日/每周计划
`group_ops_plan_items`	`id, plan_id, scheduled_at, type, objective, draft_content, final_content, status, idempotency_key`	可审核、可执行任务
`group_ops_messages`	`id, account_key, room_id, external_message_id, sender_id, sender_role, content, message_type, sent_at, raw_json`	标准化群消息，外部消息 ID 唯一
`group_ops_findings`	`id, account_key, room_id, type, severity, evidence_json, rule_version, status, assignee, due_at`	质检发现与处理闭环
`group_ops_daily_scores`	`account_key, room_id, score_date, component_json, coverage, total_score`	可解释的日健康指标
`group_ops_send_attempts`	`id, plan_item_id, target_room_id, request_hash, status, external_message_id, error, created_at`	发送幂等、重试与回执
`group_ops_audit_logs`	`id, actor, action, entity_type, entity_id, before_json, after_json, created_at`	发布、审批、发送和关闭记录

索引至少覆盖：

(account_key, room_id)；
(account_key, plan_date, status)；
(account_key, severity, status, created_at)；
(account_key, room_id, sent_at)；
idempotency_key 和 external_message_id 唯一索引。

5.5 Dashboard API

建议新增：

GET    /api/group-ops/overview
GET    /api/group-ops/workbench
GET    /api/group-ops/groups
GET    /api/group-ops/groups/:roomId
POST   /api/group-ops/groups/:roomId/generate-plan
POST   /api/group-ops/groups/:roomId/review

GET    /api/group-ops/playbooks
POST   /api/group-ops/playbooks
POST   /api/group-ops/playbooks/:id/versions
POST   /api/group-ops/playbooks/:id/publish
POST   /api/group-ops/playbooks/:id/rollback

POST   /api/group-ops/plan-items/:id/approve
POST   /api/group-ops/plan-items/:id/reject
POST   /api/group-ops/plan-items/:id/send
POST   /api/group-ops/plan-items/:id/skip

GET    /api/group-ops/findings
POST   /api/group-ops/findings/:id/assign
POST   /api/group-ops/findings/:id/resolve
POST   /api/group-ops/findings/:id/false-positive

通用约束：

所有请求从当前登录账号解析 accountKey，不接受浏览器任意伪造；
写接口要求操作者身份、角色校验和审计；
发布、回滚、批量批准和发送返回变更摘要；
长任务复用现有 /api/jobs/:id 异步进度机制；
所有列表支持分页，禁止一次把全部群消息返回前端；
原始 raw_json 默认不返回 Dashboard，仅在受控调试中使用。

6. 质检规则与模型边界

6.1 规则优先

确定性规则处理：

计划是否逾期、是否已执行；
SLA 时间差；
模板变量未替换；
明确禁用词和必备免责声明；
重复发送和频次上限；
发送失败、账号离线和消息同步中断。

模型处理：

客户消息是否构成真实问题；
回复是否有效回答，而非仅有员工发言；
投诉、购买意向、负面情绪和潜在升级风险；
话术是否符合指定语气和当前群阶段。

模型结果必须带 confidence、分类理由和证据消息；低置信结果进入“待确认”，不能直接形成员工违规结论。

6.2 证据与隐私

Dashboard 默认只展示必要证据片段，手机号等敏感字段脱敏；
数据保留期限可配置，默认建议消息正文 90 天、聚合指标 1 年；
员工只能查看职责范围内的群；
模型输入按最小上下文原则截取，不发送无关群历史；
导出、查看完整原文和修改规则均写审计日志。

7. 关键异常与降级策略

异常	产品行为
账号离线或 token 失效	停止发送，保留草稿，提示恢复登录
消息同步中断	看板标记数据延迟，暂停生成确定性健康结论
SOP 未绑定	允许创建绑定任务，不生成“合规率”
模板变量缺失	阻止发送并列出缺失变量
模型不可用	继续执行确定性规则，模型类质检标记“未评估”
发送超时	先查询或同步回执，再决定是否重试，不能直接重复发送
批量任务部分失败	成功项保持成功，仅重试失败项
规则版本更新	历史结论保留原版本，新消息使用新版本
群被解散或无权限	停止计划并生成管理员处理项

8. 开发阶段与优先级

Phase 0：验证底座（3～5 个开发日）

修复群数据的账号隔离；
将消息同步改为账号级增量分流；
实测单群发送、群发助手、回执、频控和错误语义；
确认客户群数据授权、保留期限和角色范围；
准备 1,000 条脱敏群消息和 20 个群的试点样本。

退出条件：增量消息无重复入库，跨账号数据不可见，发送接口边界得到真实回执验证。

Phase 1：MVP 闭环（8～12 个开发日）

新建 qiwei-group-operations skill 和 MCP 工具；
建设 SOP/话术版本、计划、计划项、发送尝试和审计表；
完成“运营总览、今日工作台、群详情、SOP 话术库”基础页面；
支持单群 7 天计划、话术生成、人工审批、复制/发送和失败重试；
支持节奏执行、未回应问题、投诉风险三类质检；
建立 sample 模式和 smoke test。

退出条件：一个总部管理员可发布 SOP，一个门店员工可完成每日执行，一个管理者可从预警下钻到原消息并闭环。

Phase 2：规模化督导（5～8 个开发日）

批量计划、跨门店对比和每日管理简报；
分配负责人、整改待办和官方企微待办同步；
误报反馈集、质检评测脚本和阈值配置；
活跃趋势、生命周期建议和优秀话术沉淀；
发布影响预览、版本 diff 和回滚。

退出条件：20 群连续运行 14 天达到第 2.1 节验收指标。

Phase 3：受控自动化（试点指标达标后再立项）

仅对白名单群、低风险模板、固定时间窗开放自动执行；
配置每日/每周频控、熔断、灰度范围和一键停用；
自动化仍保留审批策略版本、执行回执和全量审计。

9. 测试与验收

9.1 必测场景

同一群同一天重复生成计划，不产生重复可执行项。
SOP 发布后旧计划仍引用旧版本，新计划引用新版本。
变量缺失、禁用词、高风险意图会阻止发送。
发送成功后网络超时，重试不会产生第二条消息。
客户提问后员工只发送无关内容，仍判定为未有效回应。
投诉在一分钟内产生可追溯预警，人工可确认误报或关闭。
消息同步延迟时健康分显示数据不足，不错误扣分。
两个企微账号的群、SOP、消息和报表完全隔离。
门店员工不能发布总部 SOP，也不能查看其他门店完整消息。
所有批准、编辑、发送、跳过、误报和关闭动作都能审计。

9.2 Demo 闭环

建议销售 Demo 控制在 30 秒：

展示总部已发布“新客群 7 天 SOP”。
对一个新客群说：“按公司 SOP 生成明天计划和话术。”
Agent 返回计划和风险检查，员工在工作台确认一条话术。
切换管理视角，看到执行已完成；另一个群因客户问题超时未答产生预警。
点击预警查看原消息、负责人和建议动作。

10. 工作量拆分建议

工作包	主要交付	估算
群消息与账号底座	账号隔离、增量分流、游标、回执 smoke	3～5 人日
数据层与服务层	表结构、迁移、store/service、审计、幂等	3～4 人日
Skill 与 MCP	skill、7 个工具、上下文装配、输出契约	3～4 人日
SOP/计划 Dashboard	总览、工作台、群详情、SOP 页面	5～7 人日
质检引擎	规则、模型分类、证据、评分、预警闭环	4～6 人日
测试与试点	sample、smoke、评测集、20 群试点支持	3～5 人日

合计约 21～31 人日，可由后端/Agent 与前端并行；以上为方案阶段估算，需在 Phase 0 接口实测后校准。

11. 风险与待确认事项

开发前必须由业务负责人确认：

首批试点的 3 家门店、20 个群和具体负责人是谁？
首个群类型是新客群、成交服务群、售后群还是会员群？建议只选一种做 MVP。
公司已有可整理的优秀话术、禁用词、服务承诺和响应 SLA 吗？若没有，谁负责审核 AI 生成的第一版？
门店允许系统直接发送，还是首期只允许“生成 + 复制 + 人工标记已执行”？
投诉、价格、退款、医疗/法律等哪些场景必须升级人工？
总部、区域、门店的查看和发布权限如何划分？
群消息允许保存多久，哪些字段需要脱敏，是否取得内部合规授权？
用什么业务结果证明成功：响应速度、运营工时、到店/成交、复购，还是投诉下降？

12. 最终建议

不要把本需求只做成“话术生成器”或“群数据看板”。前者仍然依赖门店自觉，后者只能看问题不能推动执行。首个可售、可验收的闭环应是：

总部发布标准 → Agent 为每个群生成每日计划和话术 → 门店人工确认执行 → 系统自动质检 → 总部查看执行率和风险并下发整改。

技术上首期采用一个统一 qiwei-group-operations skill，加一个“社群运营”Dashboard 模块；在数据规模、角色和自动化策略稳定后，再拆分 SOP 管理、群运营 Copilot 和质检督导 skill。

qiwei-group-operations-product-development-spec.md 23 KB Historia Czysty