旗舰场景 分析决策 行业 · 文旅与体育

YY-01 · 票务预约与实名制 · 退票梯次与黄牛识别

痛点 表面看是卖票收钱 · 实际是实名绑定、退票梯次、85%公开销售三套口径对不齐,现场必乱

① 场景引入

一、这件事现在是什么样

运营 / 票务 / 游客服务 · 真实业务触发

音乐节开票前,要定退票梯次、实名绑定、85% 公开销售口径,还要识别异常订单。口径对不齐,开票当天就是投诉和现场混乱,事后还要被认定失信主体。

二、痛点 · 每条都有来源

1黄牛囤票哄抬:原价两千内场票被哄抬到数十万依据 · 某法院:2019至2023年8月某法院票务纠纷超百起,黄牛把2000元内场票哄抬到数十万;实名制后退票难成普遍现象2实名制后退票难成普遍现象,游客权益受损依据 · 某法院:2019至2023年8月某法院票务纠纷超百起,黄牛把2000元内场票哄抬到数十万;实名制后退票难成普遍现象3公开销售低于85%或为倒票提供便利,会被认定文旅市场失信主体依据 · 文旅部、公安部《关于进一步加强大型营业性演出活动规范管理的通知》(文旅市场发〔2023〕96号):5000人以上实名购票入场、梯次退票、公开销售不低于核准数85%4退票手续费过低会助长抢票加价,48小时无条件退票可能催生地下交易依据 · 大连市文旅局提案答复:48小时无条件退票+转赠可能催生地下交易;退票手续费过低会助长抢票加价销售5智慧票务系统操作复杂,游客入口排队扫码半小时;门禁只掌握实时流量缺乏预测依据 · 某媒体消费频道:云台山智慧景区门禁系统只掌握实时流量缺乏预测,重大节点游客滞留数小时;电子门票验证方式混乱延长入园时间

三、换个做法之后

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

✕ 现在的做法

  • 黄牛囤票哄抬:原价两千内场票被哄抬到数十万实名制后退票难成普遍现象,游客权益受损公开销售低于85%或为倒票提供便利,会被认定文旅市场失信主体退票手续费过低会助长抢票加价,48小时无条件退票可能催生地下交易

✓ 交给 Agent 之后

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

四、场景闭环

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

  1. 要素校验 · 先判断这些材料能不能用逐项打勾;缺项不阻塞,但要算出对开票口径的影响
  2. 口径对齐 ·实名/退票/公开销售三套对齐把实名绑定、退票梯次、85%公开销售对齐到同一场次
  3. 异常识别 · 找出异常订单同一证件多平台购票、退票后复购、疑似占坑的订单逐条列出
  4. 退票测算 · 各梯次退票量按退票时间窗测算各梯次退款金额,供定价参考
  5. 留证与签批 · 生成可签字的正式件签批栏、口径依据、异常清单一次生成,退票规则留空

要准备什么:订单/退款流水.xlsx票务平台导出,渠道与档位口径不一票务销售方案.docx档位、渠道、退票梯次实名绑定规则.docx96号文实名购票入场要求

为什么这个场景值得做

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

最大差异点:不要求客户先统一票务口径。订单流水、退票规则、实名绑定要求直接扔进来,Agent 对齐三套口径、标出冲突,异常订单按实名绑定与退票时间窗识别。

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

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

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

五、会产出什么

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

  • 正式件本体:票务销售方案.xlsx 口径对齐后的销售方案 · 含签批栏
  • 可派发清单:异常订单清单.xlsx 可派发 · 每条带特征与处理建议
  • 可派发清单:退票测算表.xlsx 各梯次退款金额测算

这套东西不承诺什么:不替客户定退票梯次和拦截黄牛;出的是口径对齐表与异常订单识别清单,退票规则与风控拦截由人定。

② Live Demo(演示逐步)

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

案例设定:云岭湖畔音乐节 HD-2026-009 开票前,要定退票梯次、实名绑定、85% 公开销售口径,还要识别异常订单。口径对不齐,开票当天就是投诉和现场混乱。

输入文件 4 份 · 公开销售 5,100 张 · 异常订单 57 单退票测算 21 万 · 元

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

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

  • 01_订单退款流水.xlsx 票务平台导出的本场订单与退款流水,渠道与档位口径不一运营部吴桐维护 · 平台导出
  • 02_票务销售方案.docx 档位、渠道、退票梯次的现行方案——三套口径对不齐的源头运营部吴桐 · 本月初草拟
  • 03_实名绑定规则.docx 96 号文实名购票入场要求合规部郑洁 · 摘录文旅市场发〔2023〕96 号
  • 04_内部票发放清单.xlsx 赠票、媒体票、嘉宾票的发放记录,实名绑定最容易漏的一环运营部吴桐 · 手工登记

注意标橙色那一份 —— 02_票务销售方案.docx。它运营部吴桐 · 本月初草拟,平时压根不在核对范围里。这个场景的价值,很大一部分就来自把它读进来。

提示词就说这么几句

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

帮我把这场音乐节的票务口径对齐一下。 把订单流水、退票规则、实名绑定三样东西对到一起,对不上的标出来。 帮我找出同一证件多平台购票、退票后复购这些异常订单。 退票梯次最终怎么定,我自己拍。

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

触发开票前要定口径

退票梯次、实名绑定、85% 公开销售三套口径对不齐

音乐节 HD-2026-009 开票前,要定退票梯次、实名绑定、85% 公开销售口径,还要识别异常订单。口径对不齐,开票当天就是投诉和现场混乱。

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

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

演示数据(表格原文)检查项结果影响处理订单流水是否可读可读—对齐档位口径退票梯次是否合规冲突公开销售 80%<85%按 96 号文改实名绑定是否覆盖漏内部票900 张未实名补实名异常订单是否识别未识别—跑识别规则公开销售 80% 与 96 号文的 85% 冲突,是开票前必须先堵的洞。排除性结论「这批订单里九成是正常散客,异常集中在一成」——把人工排查范围从5100 张缩小到 57 单,省掉整轮逐单排查。

第 2 步 · 口径对齐 · 实名/退票/公开销售三套对齐

把实名绑定、退票梯次、85% 公开销售对齐到同一场次

演示数据(表格原文)口径项现行合规要求差异公开销售比例80%≥85%+5%公开销售张数4,8005,100+300内部票1,200900−300实名绑定公开票已实名含内部票实名900 张未实名总票数6,0006,000—6000 张票,85% 公开 = 5100 张,15% 内部 = 900 张,两张口径必须对齐。把技术动作翻译成钱把「公开销售比例从 80% 提到 85%」翻译成「公开多放 300 张、内部少 300 张」,内部票 900 张若都免费,少卖 300 张公开票对应的收入是可见的。

第 3 步 · 异常识别 · 找出异常订单

同一证件多平台购票、退票后复购、疑似占坑的订单逐条列出

演示数据(表格原文)异常类型订单数特征处理建议同一证件多平台购票37跨 2 个平台重复购实名核验拦截退票后复购12退票后同一证件复购进需人工确认疑似占坑/黄牛特征8短时多单+高价票交平台风控合计57——识别结果标置信度,拿不准的进「需人工确认」,不自动拦截。从历史里想起了公司踩过的坑去年音乐节「同一证件多平台购票」没拦截,现场实名核验失败堵在门口。这次同一异常特征又出现(37 单),Agent 直接拎出。这条不靠当年经手的人还在不在职。

第 4 步 · 退票测算 · 各梯次退票量

按退票时间窗测算各梯次退款金额,供定价参考

演示数据(表格原文)档位退票张数单价(元)退款额(元)早鸟票4028011200预售票10048048000正价票9068061200VIP票70128089600合计300—210,000退票 300 张,退款额合计 21 万元;另按梯次:24h 内 100 张、24-72h 120 张、72h-7d 80 张。该拦的地方拦住了结论是「这套退票规则现在还不能上线」——梯次口径与 96 号文要求冲突。给出不用干等的替代方案:按合规梯次和宽松梯次各出一版,各带退款金额。

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

签批栏、口径依据、异常清单一次生成,退票规则留空

演示数据(表格原文)栏位状态说明退票梯次留空最终梯次由人拍拦截策略留空黄牛拦截由平台+公安实名规则已对齐含内部票实名退票规则与拦截策略留空,由人定。这套退票规则现在还不能上线公开销售 80% 与 96 号文要求的 85% 冲突,内部票 900 张未实名,上线就是开票当天的投诉和现场核验失败。办法一:按合规口径改——公开销售 5100 张、内部票 900 张全实名,退票按 24h 免 / 72h 30% / 7d50% 上线,先合规再谈宽松。办法二:先按宽松梯次(72h 内免手续费)测算多退金额,把 21 万退款额与多退的差额并列给老板看,由老板定梯次。之后这一次跑完,公司多了什么

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

演示数据(表格原文)✓票务口径入库:实名/退票/公开销售三套口径留档✓异常识别规则被固定:同一证件多平台购票等特征被标记✓一条历史教训被真正用上:实名核验失败的异常特征被标记✓岗位角色变了:从「开票后救火」变成「开票前对齐口径、只看被标出的异常」追问现场可能被问到的答不上来的问题,比答得漂亮的问题更能决定这场演示的结果能不能直接帮我定退票梯次?不能,退票规则要担责。我们出合规基准和退款测算,梯次你自己拍。它会不会误伤正常购票?识别结果会标置信度,拿不准的进「需人工确认」,不自动拦截。它读得懂不同平台的流水吗?能读,但口径对不上的会标成「需人工确认」。

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

1. Skill 能力包

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

票务预约与实名制 · 退票梯次与黄牛识别 · Skill

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

版本 v1.0

ticketing-realtime.zip

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

包内结构

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

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

2. 原始素材

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

📁YY-01 · 演示素材

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

共 4 份

  • 01_订单退款流水.xlsx 票务平台导出的本场订单与退款流水,渠道与档位口径不一
  • 02_票务销售方
  • 案.docx 档位、渠道、退票梯次的现行方案——三套口径对不齐的源头
  • 03_实名绑定规则.docx 96 号文实名购票入场要求
  • 04_内部票发放清单.xlsx 赠票、媒体票、嘉宾票的发放记录,实名绑定最容易漏的一环

怎么用

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

3. 提示词卡片

帮我把这场音乐节的票务口径对齐一下。 把订单流水、退票规则、实名绑定三样东西对到一起,对不上的标出来。 帮我找出同一证件多平台购票、退票后复购这些异常订单。 退票梯次最终怎么定,我自己拍。

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

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

  • YY-01_票务销售方案.xlsx 口径对齐后的销售方案 · 含签批栏
  • YY-01_异常订单清单.xlsx 可派发 · 每条带特征与处理建议
  • YY-01_退票测算表.xlsx 各梯次退款金额测算

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

输入清单:订单/退款流水.xlsx票务平台导出,渠道与档位口径不一票务销售方案.docx档位、渠道、退票梯次实名绑定规则.docx96号文实名购票入场要求

人工边界:不替客户定退票梯次和拦截黄牛;出的是口径对齐表与异常订单识别清单,退票规则与风控拦截由人定。

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

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

运营 / 票务 / 游客服务 · 产出即下一步输入

YY-02 · 游客投诉与现场服务 · 登记认定赔付留证 — 表面看是安抚游客 · 实际是九十天时效、六十天办结、责任认定留证,处理不好进评级黑历史 查看 →

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

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

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

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