标准场景 数据整理 行业 · 文旅与体育

CH-02 · 活动复盘与结案报告 · 从散装数据出可归档件

痛点 表面看是活动做完写个总结 · 实际是票房、赞助、投诉、事故散在四处,结案报告永远凑不齐

① 场景引入

一、这件事现在是什么样

策划 / 内容 · 真实业务触发

音乐节或赛事结束后一周内要交结案报告,老板要问「赚了多少、赞助给没给足、投诉处理完没」,三天内要一份能归档、下次立项能用的正式件。

二、痛点 · 每条都有来源

  1. 票房结算、赞助尾款、投诉记录、事故整改散在四个环节,结案报告凑不齐
    依据:腾讯服务商吐槽大会:需求一天三变定稿前一天推翻重来、改了12版选第1版、群里十几个人不知道谁拍板、比了8家选最便宜
  2. 结案报告做完就扔,没人归档,下次立项又从零问一遍
    依据:某媒体活动策划人调研:策划一人身兼报告狗/图表狗/流程狗/对接狗/物料狗/背锅狗,熬夜改方案,出事背锅
  3. 投诉和事故不回流到方案整改,同一个坑反复踩
    依据:《旅游投诉处理办法》(文旅部令第14号,2026.3.15施行):投诉由住所地/合同签订地/纠纷发生地管辖,受理后60日内处理,超合同履行期届满90日不予受理
  4. 结案要过会,数据口径对不上被老板当场问住
    依据:文旅部、公安部《关于进一步加强大型营业性演出活动规范管理的通知》(文旅市场发〔2023〕96号):5000人以上实名购票入场、梯次退票、公开销售不低于核准数85%

三、换个做法之后

变化不在「快」,在「参与的角色」和「覆盖的范围」

✕ 现在的做法

  • 票房结算、赞助尾款、投诉记录、事故整改散在四个环节,结案报告凑不齐
  • 结案报告做完就扔,没人归档,下次立项又从零问一遍
  • 投诉和事故不回流到方案整改,同一个坑反复踩
  • 结案要过会,数据口径对不上被老板当场问住

✓ 交给 Agent 之后

  • 多来源文件一次读入,先做口径与完整性校验,再开始算
  • 每条结论绑定来源文件、字段或条号,可以被审
  • 产出是企业真会流转的正式件(带签批栏),不是一张展示用的表
  • 该拦的地方给出「现在还不能提交」,并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

  1. 要素校验 · 先判断这四路材料能不能用逐项打勾;缺项不阻塞,但要算出对结案口径的影响
  2. 口径归一 ·票房与赞助对齐到同一基准把票务流水、赞助台账对齐到同一场活动的编号与金额
  3. 投诉事故回流 · 生成整改清单投诉与事故逐条归因到方案与安全预案,形成整改项
  4. 结案初稿 · 出可归档件盈亏表、权益落地、投诉闭环、整改清单一次生成
  5. 留证与签批 · 生成可签字的正式件签批栏、数据依据、不足条件的说明一次生成

要准备什么:票房结算流水.xlsx票务平台导出,档位与渠道口径不一赞助商台账.xlsx谁付了、付多少、权益给没给,来自招商部游客投诉登记表.xlsx投诉编号、处理状态、赔付金额现场事故/整改记录.docx事故经过与整改措施,纸质留档为什么这个场景值得做

优先级评分:痛感 4 × AI 适配 5 ÷ 落地难度 2 = 11.0

最大差异点:不要求客户先汇总结案数据。票房流水、赞助台账、投诉登记、事故记录四路原件直接扔进来,Agent对齐口径、标注差异,投诉与事故自动回流到「方案与安全预案整改」清单。

评分口径:痛感看「这事没做好谁会生气、生气到什么程度」;

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」;

落地难度是分母 —— 需要客户先做数据治理的场景,分数会被压得很低。

五、会产出什么

判断标准只有一个:这份东西能不能直接进企业的流程

  • 正式件本体:结案报告.docx 结案底稿 · 含盈亏表与整改清单 · 含签批栏
  • 可派发清单:整改清单.xlsx 可派发 · 每条投诉/事故对应整改项与负责人
  • 可派发清单:归档清单.xlsx 对应归档要求 · 附件编号与页码索引

这套东西不承诺什么:不替客户下「这场活动赚没赚」的最终结论;出的是可归档的结案底稿,盈亏结论和责任认定由人填。

② Live Demo(演示逐步)

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」,用的是真实业务格式的脱敏构造数据, 不宣称已接入客户生产系统,也不承诺任何效率提升百分比。

案例设定:云岭湖畔音乐节 HD-2026-009 结束后一周内要交结案报告,老板要问「赚了多少、赞助给没给足、投诉处理完没」。票房流水、赞助台账、投诉登记、事故记录散在四个环节,三天内要一份能归档的正式件。

输入文件 4 份 · 应收未收 38 万元 · 投诉回流 15 条 · 结论暂缓过会

输入文旅体手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

  • 01_票房结算流水.xlsx 票务平台导出的本场票房结算,档位与渠道口径不一运营部吴桐维护 · 平台导出
  • 02_赞助商台账.xlsx 谁付了、付多少、权益给没给,记不全——结案最怕这一份招商部赵磊维护 · 上次更新 3 周前
  • 03_游客投诉登记表.xlsx 本场活动期间的游客投诉,来自微信、电话、12345 转派运营部客服 · 各渠道手工登记
  • 04_现场事故整改记录.docx 现场事故经过与整改措施,纸质留档,没人整理运营部吴桐 · 现场手写后锁抽屉

注意标橙色那一份 —— 02_赞助商台账.xlsx。它招商部赵磊维护 · 上次更新 3 周前,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

帮我把这场音乐节的结案报告写个底稿。 把票房流水、赞助台账、投诉登记、事故记录四样东西对到一起,口径不一致的地方标出来。 投诉和事故要归到方案整改清单里。 盈亏结论和责任认定留空,我自己写。

短是因为结案规则沉淀在能力包里,你只需要说清这是哪场活动。

触发结案报告要过会

三天内交一份能归档、下次立项能用的正式件

音乐节 HD-2026-009 结束一周,老板要一份结案报告过会:赚了多少、赞助给没给足、投诉处理完没。

第 1 步 · 要素校验 · 先判断这四路材料能不能用

缺项不阻塞,但要算出对结案口径的影响

演示数据(表格原文)检查项结果影响处理票房流水是否可结算可读—对齐档位口径赞助台账是否记全记不全38 万未收标出差异投诉登记是否齐全散装—归集 15 条事故整改是否留档纸质散装—回流预案四路数据各自记各自的口径,对齐口径是这一步的全部价值。排除性结论「投诉里的三条是同一根源,合并成一条整改项」——TS-2026-081(补给不足)、TS-2026-090(卫生间排队)、TS-2026-093(存包收费)都指向现场服务配置,省掉重复整改的整轮扯皮。

第 2 步 · 口径归一 · 票房与赞助对齐到同一基准

把票务流水、赞助台账对齐到同一场活动的编号与金额

演示数据(表格原文)收口金额(万)说明票房收入302.8HD-2026-009 公开销售 5100 张赞助现金应收130冠名 80 + 钻石 30 + 普通 20赞助现金实收92已付 50 + 30 + 12赞助尾款未收38云泉 30 + 湖畔 8合计应到位340.8票房 302.8 + 赞助应收 130赞助尾款口径与招商台账差 38 万,正是结案过会时会被当场问住的点。把技术动作翻译成钱把「赞助尾款未结」翻译成「应收未收 38 万」,老板只看这一行。云泉 30 万、湖畔 8 万,两笔都还没进账。

第 3 步 · 投诉事故回流 · 生成整改清单

投诉与事故逐条归因到方案与安全预案

演示数据(表格原文)根源涉及投诉整改项负责人现场服务配置不足TS-2026-081 / 090 / 093补给点、卫生间、存包点按人流重排吴桐入场排队与引导TS-2026-082 / 089增设引导岗与分时入场吴桐退票与黄牛TS-2026-083 / 086 / 095对齐退票梯次与实名拦截郑洁看台安全现场事故护栏加固纳入安全预案郑洁每条整改项对应具体文件与负责人,不是流水账。从历史里想起了公司踩过的坑去年马拉松的投诉记录里藏着一笔「补给不足引发差评」的教训,今年音乐节同一个补给方案特征又出现(TS-2026-081)。这条不靠当年经手的人还在不在职。

第 4 步 · 结案初稿 · 出可归档件

盈亏表、权益落地、投诉闭环、整改清单一次生成

演示数据(表格原文)结案项结果依据状态盈亏测算票房 302.8 万 − 支出 149 万01流水+02台账待老板定口径赞助权益落地冠名 LOGO 缩水30%ZS-2026-003待核对投诉闭环15 条归集,9 条待处理03登记表回流整改整改清单4 条可派发04事故记录已生成结案底稿可归档,下次立项直接调用上一场的底稿。该拦的地方拦住了结论是「这份结案报告现在还不能过会」——赞助尾款口径与招商台账差 38 万。给出不用干等的替代方案:按招商台账和票务流水各出一版盈亏,标出差异。

第 5 步 · 留证与签批 · 生成可签字的正式件

签批栏、数据依据、不足条件的说明一次生成

演示数据(表格原文)栏位状态说明盈亏结论留空赚没赚由老板下结论责任认定留空尾款与事故责任由人认定整改验收留空整改完成由人签字验收盈亏结论和责任认定留空,由人填。这份结案报告现在还不能过会赞助尾款口径与招商台账差 38 万,直接过会会被老板当场问住。办法一:按招商台账口径出一版盈亏,尾款 38 万全额计提应收,让老板先看最坏情形再定。办法二:按票务流水口径出一版,只计已到账 92万赞助,把 38 万差异单独标出来,两种口径并列交给老板选。之后这一次跑完,公司多了什么

不讲省了多久 · 讲少了几个隐患、沉淀了什么

演示数据(表格原文)✓结案底稿归档:下次立项直接调用上一场的底稿✓投诉与事故的回流机制被固定:整改清单成为下一场方案的输入✓一条历史教训被真正用上:补给不足的供应商特征被标记✓岗位角色变了:从「散装凑报告」变成「对齐口径、只看被标出的差异」追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果能不能直接告诉我这场活动赚没赚?不能,盈亏结论要担责。我们把四路数据对齐、标出差异,结论你自己下。投诉和事故会不会只是列一遍?不会,每条都归因到方案和预案,生成可派发的整改项,不是流水账。它读得懂票务平台的导出流水吗?能读,但不同渠道口径对不上的会标成「需人工确认」。

③ 能力沉淀(Skill / 提示词 / 预期输出 / 人工边界)

1. Skill 能力包

导入之后,同类任务会自动按这套规则走 —— 提示词才能写得那么短

活动复盘与结案报告 · 从散装数据出可归档件 · Skill

SKILL.md 主本 + references(输出骨架 / 判据 / 渲染脚本)· 符合 WorkBuddy Skill 规范

版本 v1.0

event-review-report.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

  • SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
  • references/output_template.md 输出骨架(sheet 名 / 分区顺序 / 列头)+ 可直接运行的渲染脚本
  • references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细,不会拖慢每次对话。

2. 原始素材

这些就是文旅体手上真实能拿到的东西 —— 格式不统一是常态,不是问题

📁CH-02 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 4 份

  • 01_票房结算流水.xlsx 票务平台导出的本场票房结算,档位与渠道口径不一
  • 02_赞助商台账.xlsx 谁付了、付多少、权益给没给,记不全——结案最怕这一份
  • 03_游客投诉登记表.xlsx 本场活动期间的游客投诉,来自微信、电话、12345 转派
  • 04_现场事故整改记录.docx 现场事故经过与整改措施,纸质留档,没人整理

怎么用

  • 把素材全部拖进 WorkBuddy 对话框(不需要整理格式、不需要改文件名)
  • 粘贴下方提示词发送
  • 拿到正式件初稿 —— 签批栏留空,推荐意见留空,由你填

3. 提示词卡片

帮我把这场音乐节的结案报告写个底稿。 把票房流水、赞助台账、投诉登记、事故记录四样东西对到一起,口径不一致的地方标出来。 投诉和事故要归到方案整改清单里。 盈亏结论和责任认定留空,我自己写。

为什么这么短就够了:短是因为结案规则沉淀在能力包里,你只需要说清这是哪场活动。

换成你自己的业务:把素材换成你手上的真实文件即可。导入 Skill 之后,

该走几步、什么口径、什么情况必须拦住,Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

  • 用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说:什么事、什么文件、什么要求。不用讲究格式。
  • 调用 Skill 补齐专业规则 —— 导入本页 Skill 后,流程、口径、硬规则 Agent 自己知道。
  • 用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮,把随口说的话补成更完整的表述。

分工:自然语言负责「这是什么事」,Skill 负责「该怎么做」,增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

  • CH-02_结案报告.docx 结案底稿 · 含盈亏表与整改清单 · 含签批栏
  • CH-02_整改清单.xlsx 可派发 · 每条投诉/事故对应整改项与负责人
  • CH-02_归档清单.xlsx 对应归档要求 · 附件编号与页码索引

Skill 里固化了什么:从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单:票房结算流水.xlsx票务平台导出,档位与渠道口径不一赞助商台账.xlsx谁付了、付多少、权益给没给,来自招商部游客投诉登记表.xlsx投诉编号、处理状态、赔付金额现场事故/整改记录.docx事故经过与整改措施,纸质留档

人工边界:不替客户下「这场活动赚没赚」的最终结论;出的是可归档的结案底稿,盈亏结论和责任认定由人填。

升为客户真实案例还缺什么:客户当前真实输入文件(不要整理过的)岗位现行 SOP 与审批链(金额分档、谁签字)至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径(多少天算临期、多少金额算大额)

5. 同一角色下的其他场景

策划 / 内容 · 产出即下一步输入

CH-01 · 活动策划方案与宣传推文 · 数据驱动差异化初稿 — 表面看是缺创意、要憋方案 · 实际是往年方案散落各处、新方案永远从零重写 查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入,不用在不同工具之间来回复制粘贴。

场景内容基于 WorkBuddy 产品能力整理,演示中的企业、人物与数据均为虚构,不代表任何客户的实际成效;痛点引用的公开来源已做脱敏处理。网页版由原资料转换,部分演示表格以原文形式展示。

想把这个场景在你们企业跑通?

顾问会先看你们的数据和流程够不够,再决定从哪一步开始。