event-sponsor-value-proposition

活动赞助商价值主张

在着手包装、定价或推销之前，先了解每位赞助商的需求，并阐明技术活动能够真正为其提供的价值。赞助商往往无法自行看出活动的价值；活动与赞助商是否契合，要通过调研发现，而不是在演示文稿中想当然地设定。

• 交付内容：为每个赞助商细分群体提供一条价值主张，每项主张都由证据支持，并作为 samber/dev-event-organizer-skills@event-sponsor-prospectus（演示文稿）和 samber/dev-event-organizer-skills@event-sponsor-pricing（价目表）的依据。
• 不在范围内：设计赞助档位、制定价格、开展推广、起草合同、跟踪交付——这些由配套技能负责。
• 范围：主要适用于一天或多天的会议；其他活动形式只有在以相同方式销售赞助时，才沿用这套逻辑。
• 赞助商购买的内容：对赞助商而言，参会者实际上就是产品——赞助商购买的是接触合格受众的机会。接触意味着展示和交流，绝不意味着获取参会者名单；只有参会者主动提供时，才能传递联系信息；在社区主办的活动中，绝不能以名单形式传递（参见“社区主办与供应商主办”）。
• 边界：赞助购买的是展示位置和接触机会，绝不包括演讲名额、评审结果，也不包括对活动议程或路线图的影响（“任何赞助商都不应能靠付费挤进活动议程”——DevOpsDays 组织指南）。

以下所有排序均为默认参考，并非铁律：它们会随情境和执行者而变化。访谈结束后，根据你对该组织者的了解重新排序——以下任一因素都可能颠覆默认排序：

• 已有的参会者数据处理流程
• 回归的核心赞助商
• 没有过往记录的首届活动
• 已获得同意、可检索潜在客户信息的供应商主办活动
• 当地招聘市场降温（Q11）

访谈

每次只问一个问题，尽可能采用选择题。之所以有第 7–9 个问题，是因为下面各菜单在回报时间、持久性和投入精力方面差异很大，不能替用户选定默认排名。

1. 活动属于哪一端：社区主办（独立、由征集提案驱动，赞助用于成本回收）还是厂商／基金会主办（由厂商所有、使用营销预算，赞助用于拓展销售线索）？这决定了哪些价值类别可以如实承诺——在起草任何权益主张前先确定。
2. 这项方案面向哪类赞助商，每次只选一类：产品反馈买家（DevRel／开发者倡导者职位）、招聘买家（人才招聘／HR 职位）、品牌买家（营销／PR 职位），还是社区成员赞助商（社区内的从业者或创始人）？细分分类和职位信号见：references/sponsor-segment-jtbd-worksheets.md。
3. 这家特定合作伙伴实际需要从活动中获得什么？提出方案前先询问；许多赞助商不会主动说出需求。逐一探查典型需求，并将其对应到以下价值类别：雇主品牌或招聘（招聘）、向受众销售（仅限厂商主办活动的销售线索；社区主办活动则是品牌曝光加上由参会者选择的产品交流）、产品反馈（产品反馈）、品牌知名度（品牌曝光）、社区好感度（社区好感度）。任何无法如实归入某个类别的需求，都应列入不提供清单。
4. 有哪些受众证据：往届活动或报名表中汇总的职位／资历／公司规模构成、地理分布？要数字，不要印象。（“哪些受众会参加？”——DevOpsDays 指南中赞助商总会问的三个问题之一。）
5. 有哪些过往业绩：举办过几届、赞助商续约率、真实的活动后赞助商报告？首届活动没有这些数据——请标明，并使用证明材料参考文档中的替代方案，切勿编造数据。
6. 这一细分群体目前在不参加本活动的情况下会怎么做——在更大型的厂商大会上设展、投放招聘广告、开展品牌营销活动，还是向同一受众进行冷启动外联？了解现状，才能让活动价值清晰可见，而不是想当然。
7. 赞助收入必须在何时敲定？（临近截止日期时，应优先考虑能在活动现场见效的类别——招聘交流、产品反馈，而非需要长期积累的类别。）
8. 这种赞助商关系是一次性销售，还是能跨多届活动积累价值的资产？（若要求长期积累，应优先考虑见效较慢的类别：品牌、社区好感度。）
9. 证据收集的投入上限是多少：已有数据、问卷调查能力、组织者可投入的时间？
10. 这项方案具体是为哪家赞助商或哪个等级起草的？该潜在客户自己的尽职调查清单是否会询问购买影响力或资历构成？
11. 这一细分群体当前的招聘压力如何：目标公司目前正在招聘技术人员、暂停招聘，还是在裁员？赞助商主要花钱招聘人才或向技术团队销售产品，而招聘放缓时，招聘类赞助商最先离开。市场降温时，应降低招聘作为联合主推类别的优先级，提高无需投入人员的曝光价值。需核实的信号见：references/value-category-evidence.md。

社区主办与厂商主办

活动由谁主办，决定了哪些承诺才真实可信；samber/dev-event-organizer-skills@event-first-edition 和 samber/dev-event-organizer-skills@event-format-selection 也围绕这一维度展开：

• 社区主办 - 绝不会提供或出售参会者联系名单，也不能购买演讲名额（DevOpsDays 组织指南两次明确了这两条规则）。只有参会者主动提供信息时，才会收集潜在客户信息。汇总的人口统计数据是潜在客户数据的诚实替代品；诚实的价值类别包括品牌曝光、通过真实交流招聘、从技术观点鲜明的受众那里获取产品反馈，以及赢得社区好感。
• 厂商／基金会主办 - 销售管道价值和征得同意后获取潜在客户信息的价值（扫描胸牌并返回联系详情）可以作为真实承诺，但必须以参会者同意为限。只有在这一端，销售管道价值才存在。

说明每项主张基于哪一端。若价值主张承诺在社区主办的活动上提供潜在客户名单，就夸大了承诺的收益，而这种活动从结构上就无法提供这些名单；了解主办方已发布规则的赞助商会立刻发现其中的矛盾。

工作流

1. 进行访谈；确定定位（Q1）和一个细分市场（Q2）。
2. 探索：与实际潜在赞助商进行 Q3 探索——通过电话或简短交流，而不是根据其招聘广告猜测。用对方自己的措辞记下其明确表达的需求，以及该需求对应的类别；这组对应关系就是该陈述必须服务的活动赞助商匹配点。
3. 先过诚信关：在起草活动将提供什么之前，先写下活动_不会_提供什么——公开发布的组织方惯例（DevOpsDays 会先告诉赞助商“不给参会者名单，不出售演讲时段”，再介绍赞助套餐）。现在就删去不提供的类别；被搁置为“以后再说”的类别会悄悄重现于演示文稿中。
4. 从下方的价值类别菜单中选择主导类别；探索中发现的需求决定共同主导类别。
5. 确保服务内容与活动安排一致：检查计划中的活动安排是否为每个声称的类别都提供了相应活动——招聘对应招聘专区，产品反馈对应动手反馈环节，销售对应由工作人员值守、供参会者自愿参与的演示区。与包含业务导向环节的活动相比，只有演讲的活动较难说服赞助商，因为演讲无法充分满足他们购买赞助的目的。设计这样的环节，而不是照搬其他活动的做法；在活动已十分密集的城市中，赞助商活动若是别处没有的，本身就是差异化优势。定位：samber/dev-event-organizer-skills@event-positioning；活动形式：samber/dev-event-organizer-skills@business-event-formats。赞助商活动不属于 CFP 议程（见“边界”）。
6. 使用 references/sponsor-segment-jtbd-worksheets.md，为这个细分市场填写六部分 JTBD 模板——谁 / 为什么 / 之前的情况 / 如何实现 / 之后的情况 / 替代方案。切勿将多个细分市场合并为一个陈述。
7. 为“如何实现”中的每项主张附上一个证明点，从下方的工具菜单中选择（收集细节见：references/proof-point-instruments.md）。为每项主张标明其为已证实或期望达成——未标注的主张会被视为已证实，并在尽职调查中被认为是凭空捏造的。
8. 使用 references/proof-point-instruments.md 中的价值方程核对，对草稿打分——这是起草后的评分视角，绝不是要填写的结构。
9. 与用户逐节验证——这是一项战略交付成果；每一节都要单独获得明确批准，不能整块一次性确认。每新增一个细分市场，都要重复步骤 2 和步骤 4–8。
10. 将陈述和证明点清单交接给 samber/dev-event-organizer-skills@event-sponsor-prospectus 和 samber/dev-event-organizer-skills@event-sponsor-pricing。

如果你的运行环境支持持久化记忆，请按细分市场记录：

• 探索中明确表达的需求，以及该需求对应的类别
• 选定的主导类别
• 不提供的内容清单
• 每项主张的证明点状态（已证实或期望达成）
• 下届活动前仍需收集的证据

赞助说明书、定价和外联流程将从这份记录开始，而不是重新推导价值主张。

价值类别主导项

对于给定细分群体，哪种类别应作为主张的锚点。排序（默认值，并非铁律——应结合 Q7-Q9 和主导轴重新排序）：

• 努力（诚实地提出该主张所需的证据和交付机制）：pipeline > recruiting > product feedback > brand exposure == community goodwill
• 价值（真正交付时对典型赞助商的回报）：pipeline > recruiting == product feedback > brand exposure > community goodwill
• 效率：brand exposure > product feedback > recruiting > community goodwill > pipeline
• 合规成本（会触发的审查，以及其中有多少无法撤销）：pipeline > recruiting > product feedback == brand exposure == community goodwill

这三处并列都有依据：

• 努力：品牌曝光和社区好感都可以用组织者已经掌握的证据来主张——前者是汇总后的人口统计数据和曝光资源清单，后者是社区的过往表现和价值观；而更高的每个档位都需要投入新的机制（构成数据、对话形式、经同意后收集的数据）。

• 价值：填补一个招聘需求和做出经过验证的产品决策，都是同样具体、能在一个季度内实现的回报；MLH 的组织者指南将招聘和产品反馈并列为赞助商的三大主要动机之一，未作排序。

• 合规成本：只有 pipeline 类别会向赞助商提供个人数据，因此会触发同意流程和数据保护审查，并需要通过合同限制赞助商对数据的再利用，而且无法撤销——参会者的联系方式一旦交出，就无法收回。只有在供应商主导的活动中，招聘才会承担较轻的这类审查。

• 底部三项：并列，影响接近于零，因为它们都不会让姓名脱离组织者的系统；正因如此，它们才是真正并列，而非只是难以区分。

• 品牌曝光——默认主导项。活动默认属于认知度范畴（Phil Leggetter 的 AAARRRP 映射）——这是为了纠正偏差，而不是退而求其次：如果诚实的主要回报是曝光度，却把每项赞助都宣传成 pipeline，这正是这份菜单要纠正的不诚实默认做法。将其与细分群体的 JTBD 类别并列为主导项。

• 产品反馈——面向 DevRel/倡导者买家时的并列主导项：来自技术型、有主见的受众的实时反馈（MLH）。回报在现场就能实现——应在临近截止日期时重点推广（Q7）。

• 招聘——面向人才买家时的并列主导项；在社区主办的活动中，招聘依靠对话（办公时间、有人值守的展位），绝不依赖扫描获取的数据。要明确说明这一点。降级条件，依据 Q11：当该细分群体的招聘放缓时，招聘预算会最先被削减，因此应以品牌曝光为主导，并将招聘作为可选的并列主导项，而非锚点。

• 社区好感——在典型赞助商价值轴上排名较低，但它确实能推动续约，与 pipeline 不同：JetBrains 表示，赞助 PyCon US 是为了支持社区、会见现有用户并了解市场，而不是获取潜在客户（PSF 招商说明中的推荐语；这是一家供应商陈述的理由，并非基准）。推广条件：赞助商来自社区自身成员，或在战略上依赖该生态系统——这种情况很常见，因为许多赞助商联系人本身就是从业者（DevOpsDays）。满足条件时，应以此为主导项。

• Pipeline——最受冷落的选项：在价值轴上排名最高，在努力轴上也排名最高（经同意后收集数据的机制、归因、展位人员配置），所以效率轴永远不会选它。推广条件：由供应商或基金会主办的活动已具备经同意后获取潜在客户信息的机制，_并且_赞助商明确表示其职责是获取 pipeline。

• 在社区主办的活动中，应删除 pipeline，而非将其降级：被降级后放在菜单底部的 pipeline 承诺，会以活动范围的形式重新出现在招商说明中。

证明材料工具

“How” 中的每项主张都需要有勤勉的赞助商认可的证据——他们的尽职调查清单（受众构成、地域、过往业绩、赞助商密度、活动质量）正是需要收集答案的内容。排序（默认排序，并非硬性规则——Q9 的上限会重新排序）：

• 工作量（收集 + 分析小时数）：深度参会者调查 > 活动后赞助商报告 > 赞助商证言 > 注册表单人口统计信息 > 回头赞助商比例 == 活动内容比例
• 价值（提升勤勉赞助商感知到的可能性）：深度参会者调查 > 注册表单人口统计信息 > 活动后赞助商报告 > 回头赞助商比例 > 活动内容比例 > 赞助商证言
• 效率：回头赞助商比例 > 注册表单人口统计信息 > 活动内容比例 > 赞助商证言 > 活动后赞助商报告 > 深度参会者调查
• 合规成本（会触发的审查，以及其中有多少无法撤销）：深度参会者调查 > 注册表单人口统计信息 > 赞助商证言 > 回头赞助商比例 == 活动内容比例 == 活动后赞助商报告

这两处并列都有依据：

• 工作量：回头赞助商比例和活动内容比例都只需花约一小时统计组织方已有记录——每届活动的赞助商名单和已发布的活动日程——无需新收集数据。

• 合规成本：调查和注册字段都会收集个人数据，需要隐私声明、保留规则和合法依据；但调查会询问就业情况和购买决策权详情，而且问题一旦问出便无法收回，表单字段则可在下一届活动中移除。具名证言需要赞助商本人批准带署名的引语，并可应要求撤回。

• 后三项：并列为零，因为每项都只统计组织方已有记录，并以汇总形式报告——不涉及新的个人数据，无需审批，也没有需要撤回的内容。

• 默认阶梯：现在就计算回头赞助商比例和活动内容比例（工作量几乎为零），并在本届活动中更改注册表单，以便汇总收集角色／资历／公司规模信息。这是唯一一种会逐届累积价值的工具：每届活动的数据都会为今后的每项主张提供依据，也是社区组织活动中替代潜在客户数据的诚实做法。

• 深度参会者调查（购买影响力、工具采用情况、资历详情）——资源不足时的选项：价值最高，工作量也最大，因此效率排序永远不会选它。启用条件与 Q10 挂钩：争取核心赞助商或最高级别赞助商，且其尽职调查会询问购买影响力；或者活动由供应商主导，参会者构成会影响定价。

• 首届活动：没有回头赞助商比例、活动报告，也没有过往人口统计数据。应在陈述中标明诚实的替代依据：组织方自身的过往业绩、社区规模和参与度证据（聚会出席人数、CFP 投稿量）。切勿把预测说成历史数据——参见 references/proof-point-instruments.md。

失败模式

• 在由社区运营的活动上，先拿出符合条件的潜在客户名单。 从结构上就无法交付——没有名单，也不能扫描——而且主办方自行发布的规则明确禁止这样做。应改为提供汇总的人群统计数据，并通过对话开展招募、获取反馈。
• 暗示赞助能换来主题演讲、评审结果或对路线图的影响力。 这不是强硬推销，而是错误的承诺；赞助商一验证就会立刻露馅。主办方指南明确将其列为硬性规定，而非可协商的附加条件。
• 跳过需求探索，推销臆测的需求。 赞助商通常不会主动看出活动的价值，因此，建立在假设需求上的陈述听起来千篇一律，也无法推进。先与潜在客户一起完成 Q3。
• 只有演讲环节的活动，却承诺商业价值。 如果议程上只有演讲，却声称能带来招聘、反馈或销售价值，赞助商到现场就无事可做。添加能支撑每项承诺的活动，否则就删掉承诺。
• 把价值主张写成权益清单。 展位大小、Logo 展示位置、门票数量都是套餐内容，应由赞助方案说明。价值主张要回答的是：为什么这个细分受众会购买，而不是选择列明的其他方案。
• 所有细分受众都用同一段笼统陈述。 逐一填写模板正是为了避免多细分受众画布中的这种问题；否则内容会被稀释成“向优质受众提供绝佳曝光”，没有哪个预算负责人能把这种说法用于内部审批。
• 声称受众质量好，却没有受众构成数据。 对审慎的赞助商来说，没有证据却声称“能接触到优秀的资深工程师”，与买方一侧所警惕的信号（受众人数含糊、无法验证）并无区别。收集证明材料，否则就删掉这项主张。
• 捏造 ROI 数据或转化基准。 这个领域没有可引用的数据。DevOpsDays 展示了如何在不引用数据的情况下表达信心：“我们认为，与赞助商获得的价值相比，定价很低”——表达确信，但不附上捏造的数据。
• 把社区善意当成填充内容。 它是明确的续约驱动因素，与销售线索不同；对于面向从业者的赞助商，它是首要类别，而不是最后补上的一段。
• 主张以展位为主，预算收紧时却没有无需派驻员工的方案。 展位除了费用，还会让赞助商投入多天人力；招聘放缓时，招聘类赞助商会最先退出，展位主导的套餐也会停滞，而 Logo 和数字曝光仍然有销路。解决办法：先阅读 Q11，再选择共同主推的价值点，并在每个细分受众的 How 中说明无需派驻员工的品牌曝光方案，以便 samber/dev-event-organizer-skills@event-sponsor-pricing据此定价。
• 忽略赞助商的成本分母。 他们会把总成本——费用、展位搭建、差旅和员工工时——纳入心算；主动说清楚比保持沉默更可信。

衡量

价值主张的表述无法用行业转化数据衡量，因此绝不要引用这类数据。可以观测的是后续表现，并由自己设定指标——选择 2-3 项，并在开始联系潜在赞助商之前，写下每项指标出现什么结果时要进行怎样的修订：

• 首次通话覆盖情况（自行设定）：赞助商通话应一开始就回答三个已知问题——受众是谁、为什么要赞助、各级别分别包含什么（DevOpsDays）。如果对话卡在“我们究竟能得到什么？”，说明 How 含糊不清；如果卡在“哪些人会参加？”，说明缺少受众构成的证明材料。
• 异议记录（自行设定）：让 samber/dev-event-organizer-skills@event-sponsor-outreach 按细分受众标记异议；反复出现的异议说明该细分受众的陈述有缺陷，而不是销售出了问题。
• 陈述复用情况（自行设定）：赞助方案、定价材料和外联内容应几乎逐字引用这些陈述；如果需要改写，就说明陈述还不够具体，经不起实际检验。
• 赞助续约率反映的是整体关系——交付情况、报告质量和合作关系——而非这项技能本身；它应归入 samber/dev-event-organizer-skills@event-market-fit（信号）和 samber/dev-event-organizer-skills@event-sponsor-renewal（追踪）。

调用示例

• “为什么会有人赞助我们这个由 300 人社区运营的 DevOps 大会？在我制作演示文稿之前，帮我把理由讲清楚。”
• “一家开发工具供应商问，他们的 DevRel 团队赞助我们的黑客马拉松究竟能获得什么——起草一份价值说明。”
• “我们正在争取一家银行的早期人才团队成为主要赞助商。招聘价值主张是什么？我们需要先准备哪些证据？”
• “今年赞助商续约率下降了——为我们现有的从业者赞助商重新构建价值主张。”

预期输出：针对每个细分群体，提供一份六部分的价值主张陈述（谁 / 为什么 / 之前 / 如何 / 之后 / 替代方案），一份证据要点清单，为每项主张标明其有证据支持或仍属愿景，并注明所依据的测量工具；还要在开头列出不提供的内容——按章节逐项呈现，以供验证。

参考资料

• references/sponsor-segment-jtbd-worksheets.md - 六部分 JTBD 模板及各细分群体的工作表（产品反馈、招聘、品牌、社区成员买家）、五类赞助商类型，以及一对正反陈述示例。
• references/value-category-evidence.md - 类别集合及其背后的框架（DQL 路由、AAARRRP、五项 ROI 目标）、赞助商动机和顾虑分类、组织者亲述的诚实原则、善意评价的证据，以及赞助商需求如何随招聘市场变化。
• references/proof-point-instruments.md - 对应的尽职调查清单、各类测量工具的数据收集指南、首届活动的替代方案，以及价值方程评分检查。

另请参阅，同一集合中的内容：

• samber/dev-event-organizer-skills@event-sponsor-prospectus - 将此技能整理出的陈述打包成一份包含赞助级别和证据要点的演示文稿。
• samber/dev-event-organizer-skills@event-sponsor-pricing - 为此技能阐明的价值定价；价值主张应证明价格表合理，而不是反过来。
• samber/dev-event-organizer-skills@event-sponsor-outreach - 负责推广；将异议记录反馈给此技能，用于改进衡量方式。
• samber/dev-event-organizer-skills@event-sponsor-fulfillment - 履行承诺，并撰写推动续约的活动后报告。
• samber/dev-event-organizer-skills@event-positioning - 此技能在社区与供应商的对立选择上分支；活动如何在本地替代方案中脱颖而出，也是在此确定的定位选择。
• samber/dev-event-organizer-skills@business-event-formats - 设计面向商业的活动形式，让所主张的类别能够在现场兑现。
• samber/dev-event-organizer-skills@event-first-edition - 适用于没有过往记录的情况；其中的证据门槛为此技能提供首届活动的替代方案。