运营日报与周报
优先试点这一场景的目标是把业务数据、昨日事项、异常和目标整理成日报、趋势、异常与待办。
- 输入
- 业务数据、昨日事项、异常和目标
- 输出
- 日报、趋势、异常与待办
- 验收
- 检查日报耗时、流程执行完整率、异常闭环时长
- 边界
- 指标口径和数据刷新时间必须标注

运营工作适合把日报、SOP、活动、反馈和复盘连起来,减少重复搬运和口径混乱。
左起第一列是这个岗位可交给 WorkBuddy 的场景; 中间两列是它需要什么、能交付什么;最后一列是必须由人或系统决定的部分 —— 这一列才是评审时真正要看的,因为它决定哪些环节不能自动化。
| 场景 | 需要输入 | WorkBuddy可辅助交付 | 人工或系统边界 |
|---|---|---|---|
| 运营日报与周报 | 业务数据、昨日事项、异常和目标 | 日报、趋势、异常与待办 | 指标口径和数据刷新时间必须标注 |
| 流程与SOP整理 | 现有流程、角色、规则、例外 | 流程图、SOP、检查表和升级条件 | AI不能凭空补业务规则 |
| 活动运营 | 活动目标、受众、流程、预算 | 方案、报名页、执行清单和复盘表 | 预算、对外发布和用户数据收集需审批 |
| 问卷与用户反馈 | 调研目标、用户群、历史反馈 | 问卷、主题聚类和改进建议 | 题目偏差、样本结构和隐私需检查 |
| 运营数据看板 | 订单、用户、活动、转化等数据 | 指标看板、漏斗和异常 | 不能用单一指标替代业务判断 |
| 定时任务与提醒 | 任务频率、输入、通知规则 | 自动执行结果和失败告警 | 外部发布、付费和删除操作默认确认 |
| 跨系统工作流 | 表单、文档、消息、系统接口 | 数据同步、通知和状态回写 | 需要接口幂等、权限、日志和回滚 |
| 异常与复盘 | 异常记录、影响、处置和数据 | 时间线、根因假设、行动项 | 相关性不是因果,责任认定由人完成 |
三个优先场景在各岗位下按同一套方法拆解:明确任务口径 → 收集并检查输入 → 让 WorkBuddy 执行整理、检索或生成 → 输出可编辑结果 → 由岗位负责人复核后进入下一流程。
这一场景的目标是把业务数据、昨日事项、异常和目标整理成日报、趋势、异常与待办。

这一场景的目标是把现有流程、角色、规则、例外整理成流程图、SOP、检查表和升级条件。

这一场景的目标是把活动目标、受众、流程、预算整理成方案、报名页、执行清单和复盘表。
同一个岗位的场景会分散在四层里:文件层只用本地文档就能跑, 知识层要先建好有版本、有出处、有权限的资料,系统层要接业务系统, 决策层则必须保留人工批准。先看自己能从哪一层起步。
使用本地文档、表格和模板,结果可人工检查
建立有版本、有出处、有权限的知识资料
通过受控的Connector、MCP或API读写业务系统
展示依据、假设和影响,高风险决定由人批准
推荐先做“流程与SOP整理”。它所需输入是现有流程、角色、规则、例外,目标交付是流程图、SOP、检查表和升级条件。
试点可按四个动作推进:第一,抽取一批真实历史任务作为基线;第二,用同一批输入让人工流程和WorkBuddy流程并行;第三,记录失败、遗漏和人工修改原因;第四,只在结果稳定、权限清楚、可以回滚时扩大范围。
建议验收指标包括:日报耗时、流程执行完整率、异常闭环时长。如果结果需要大量重做、来源无法追溯、系统写入不可回滚,试点应暂停并先修复数据或流程。
把你们这个岗位最耗人的一件事说清楚,我们按上面四层能力给出可切入点、需要对接的系统清单和人工边界 —— 不是通用方案,是照着你们现有流程改的版本。