event-sponsor-prospectus

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Event Sponsor Prospectus

活动赞助计划书

You assemble the sponsorship prospectus for a technical event: the standard, published document a prospect reads before any call. The deliverable is the document itself, its section order, tier table, perks catalog, audience evidence, distribution format, and the per-edition refresh routine.

This skill presents content sibling skills produce, never invents it:

Value claims and the not-offered list, from

samber/dev-event-organizer-skills@event-sponsor-value-proposition

Tier prices and caps, from

samber/dev-event-organizer-skills@event-sponsor-pricing

It does not set prices, run outreach, draft contracts, or track delivery - those are sibling skills.

Every ranking below is a default, not a law - it shifts with context and with who executes it. After the interview, re-rank every menu against what you know about this organizer: a designer on the team, a photo archive from past editions, a first edition with no assets, or a hard outreach deadline each overturn a default rung.

你为技术活动组装赞助计划书：这是潜在赞助商在进行任何通话之前阅读的标准、已公开发布的文档。交付物包括文档本身、章节顺序、层级表、权益目录、受众证据、分发格式，以及每期刷新流程。

本skill呈现的是同级skill产生的内容，从不自行发明：

价值主张和不在清单，来自

samber/dev-event-organizer-skills@event-sponsor-value-proposition

。

层级价格和上限，来自

samber/dev-event-organizer-skills@event-sponsor-pricing

。

它不负责定价、外联、起草合同或跟踪交付——这些由同级skill负责。

以下每个排序都是默认值，而非定律——它会随情境和执行者而改变。在访谈后，根据你对组织者的了解重新排列每个菜单：团队里有设计师、往届活动有照片档案、首届活动没有资产、或外联截止日期紧迫，这些都足以推翻默认层级。

Interview

访谈

Ask one question at a time, multiple-choice where possible. Questions 6-8 exist because the menus below diverge sharply on time-to-effect, durability, and effort - the default rankings cannot be picked for the user.

Which pole does the event sit on: community-run (independent, CFP-driven, sponsors as cost recovery) or vendor/foundation-run (vendor-owned, sponsors as pipeline)? This bounds which benefit rows the document may honestly print.
Do the upstream inputs exist: per-segment value-proposition statements and the not-offered list, and a priced tier ladder with any à-la-carte prices? If either is missing, route to the sibling skill first - a prospectus drafted without them invents its own value claims and prices, the two things this skill must never do.
What real assets exist from past editions: candid photos, sponsor logos, attributed testimonials, press mentions? Assets you have, not assets you could gather.
What audience data is verified: headcount only, a rough band (age, "industry professionals"), aggregate role/industry/company-size percentages from registration forms, or survey-backed detail?
Which caps are genuinely real: booth floor-space limit, single-exclusive branding surfaces (lanyard, party, coffee), a hard sponsor-count ceiling? Only real caps may be printed.
When must the first outreach send land? (A near deadline promotes the fast rungs: a web tier page ships this week; an illustrated kit does not.)
Is this document a one-off for this edition or a compounding annual asset? (A compounding mandate promotes the PDF kit and the per-edition refresh system built around it.)
What is the effort ceiling: design hours or a designer, layout tooling, and who maintains the document between editions?
Which specific sponsor or tier is this prospectus being prepared for, and does that prospect's own diligence checklist ask about buying influence or seniority mix?

一次问一个问题，尽可能使用选择题。第6-8题之所以存在，是因为下面的菜单在见效时间、持久性和工作量上存在显著分歧——默认排序不能替用户选定。

活动属于哪一端：社区驱动（独立、CFP驱动、赞助商作为成本回收）还是厂商/基金会驱动（厂商所有、赞助商作为销售管道）？这决定了文档可以诚实印出哪些权益行。
上游输入是否存在：各细分受众的价值主张声明和不在清单，以及带任何点菜价格的定价层级阶梯？如果任何一项缺失，请先转到同级skill——没有它们起草的计划书会自行编造价值主张和价格，而这两件事是本skill绝不能做的。
往届活动有哪些真实资产：现场照片、赞助商logo、署名推荐语、媒体报道？是你已有的资产，而不是你能收集的资产。
哪些受众数据经过验证：只有人数、粗略范围（年龄、"行业专业人士"）、来自报名表的角色/行业/公司规模汇总百分比，还是有调研支持的具体数据？
哪些上限是真实存在的：展位面积限制、单一独家品牌面（挂绳、派对、咖啡）、赞助商数量硬性上限？只有真实的上限才能印出。
首轮外联邮件最晚必须什么时候发出？（截止日期临近会提升快速层级：网页层级表本周就能上线；图文并茂的PDF套件则不行。）
这份文档是本期的一次性产物，还是逐年累积的年度资产？（累积型任务会提升PDF套件及其周围的每期刷新系统的优先级。）
工作量上限是多少：设计工时或有设计师吗、排版工具，以及各期之间由谁维护文档？
这份计划书是为哪个具体赞助商或层级准备的？该潜在赞助商自己的尽职调查清单是否会问到购买影响力或资历构成？

Community-run vs vendor-run

社区驱动 vs 厂商/基金会驱动

Who owns the event decides what the document may print, the same axis

samber/dev-event-organizer-skills@event-first-edition

samber/dev-event-organizer-skills@event-format-selection

and

samber/dev-event-organizer-skills@event-sponsor-value-proposition

argue:

Community-run - no attendee-list or badge-scanning row may appear anywhere in the tier table or add-ons, since no attendee list is ever given or sold and no speaking slot is purchasable. The DevOpsDays Graz 2026 kit contains no lead-data benefit anywhere. Aggregate demographics are the honest substitute, and the document should say what sponsors will not get.
Vendor/foundation-run - consented lead-retrieval rows (badge scanning) are honestly printable, bounded by attendee consent, and pipeline framing is available.

Say which pole the document assumes. A tier table promising scanned leads at a community-run event is caught immediately by any sponsor who reads the organizer's own published rules.

活动的所有权决定了文档可以印出什么，这与

samber/dev-event-organizer-skills@event-first-edition

、

samber/dev-event-organizer-skills@event-format-selection

和

samber/dev-event-organizer-skills@event-sponsor-value-proposition

所论证的轴线一致：

社区驱动 - 层级表或附加套餐中不得出现任何观众名单或徽章扫描行，因为观众名单从不提供或出售，演讲名额也不可购买。DevOpsDays Graz 2026 的套件中没有任何线索数据权益。汇总人口统计数据是诚实的替代品，文档应说明赞助商不会得到什么。
厂商/基金会驱动 - 经同意的线索抓取行（徽章扫描）可以诚实印出，受参会者同意约束，并且可以使用销售管线框架。

说明文档假设的是哪一端。在社区驱动活动中，任何阅读过组织者自己发布规则的赞助商都会立即发现一个承诺提供扫描线索的层级表。

Workflow

工作流程

Run the interview to fix the pole (Q1) and collect the sibling inputs (Q2):
- Statements, not-offered list, proof-point inventory.
- Tier prices, caps, add-on prices.
Honesty sweep: before laying out anything, list what the document may not print - lead-data rows at the community pole, caps that aren't real, benefits absent from the value proposition, any guarantee (see Failure modes). The not-offered list travels into the document, not just the drafting notes.
Choose the document depth from the menu below.
Lay out sections in the credibility-before-price order, per references/document-anatomy.md. Proof always precedes price.
- Cover
- Brand imagery
- Event facts
- Value proposition
- Proof
- Tier table
- Add-ons
- Logistics
- Named contacts
Build the tier table per references/tier-table-and-perks.md:
- Price row first.
- A max-available row only where the cap is real.
- Plain checkmark cells.
- Numeric cells only for genuine quantities.
- Named perks.
Choose the perk presentation from the menu below. Move single-exclusive surfaces into named add-on cards when they exist.
Write the audience-evidence section at the depth the demographics menu picks - never deeper than the data is verified, per references/audience-evidence-and-distribution.md.
Set distribution and the per-edition update cadence from the same reference:
- A dated document.
- Refreshed testimonials and logos.
- Caps re-verified each edition.
Validate section by section with the user before any design or layout effort is spent - content errors are cheap to fix in outline and expensive after layout.

If your harness has persistent memory, record per edition: which tiers and add-ons sold out against their printed caps, which perks prospects asked about that the document didn't carry, and the refresh checklist state. Next edition's prospectus starts from that record instead of a blank page.

进行访谈以确定活动端（问题1）并收集同级输入（问题2）：
- 价值主张、不在清单、证明点清单。
- 层级价格、上限、附加套餐价格。
诚实性扫描：在排版任何内容之前，列出文档不得印出的内容——社区端点上的线索数据行、不真实的上限、价值主张中不存在的权益、任何保证（见失败模式）。不在清单要进入文档，而不仅仅是起草笔记。
从下面的菜单中选择文档深度。
按照
```
[references/document-anatomy.md](references/document-anatomy.md)
```
中的先信誉后价格顺序排列章节。证据总是先于价格。
- 封面
- 品牌形象
- 活动事实
- 价值主张
- 证据
- 层级表
- 附加套餐
- 物流信息
- 具名联系人
按照
```
[references/tier-table-and-perks.md](references/tier-table-and-perks.md)
```
构建层级表：
- 价格行优先。
- 只有在上限真实时才设置“剩余数量”行。
- 简洁的勾选单元格。
- 只有真实数量才使用数字单元格。
- 命名权益。
从下面的菜单中选择权益展示方式。如果存在单一独家品牌面，将其移至具名附加卡片中。
按照人口统计菜单选择的深度编写受众证据部分——绝不超过数据经过验证的深度，详见
```
[references/audience-evidence-and-distribution.md](references/audience-evidence-and-distribution.md)
```
。
根据同一参考设置分发方式和每期更新节奏：
- 标注日期的文档。
- 刷新的推荐语和logo。
- 每期重新验证上限。
在花费任何设计或排版工作之前，与用户逐节验证——内容错误在提纲阶段修复成本低，排版后修复成本高。

如果你的环境有持久化记忆，请记录每期：哪些层级和附加套餐按其印出的上限售罄、潜在赞助商询问过但文档中没有的权益，以及刷新检查清单的状态。下一期的计划书从这些记录开始，而不是从空白页开始。

Document depth

文档深度

How much document to build. Ranking (default, not a law - Q6-Q8 re-rank):

effort (design + assembly hours):

full illustrated PDF kit > in-page tier-table page == text one-pager

value (conversion signal to a diligent sponsor: prices visible, proof visible, forwardable inside the prospect's org):
```
full illustrated PDF kit > in-page tier-table page > text one-pager
```

efficiency:

in-page tier-table page > text one-pager > full illustrated PDF kit

The effort tie is argued: both bottom rungs are an afternoon of assembling content the sibling skills already produced, with no photography and no layout tooling required. The difference between a prose summary and an HTML table is formatting, not new work.

In-page tier-table page - the default rung: a web page carrying the full tier grid, prices, and a contact email. Ships in days with zero design capacity, and it is a real format - DevOpsDays Graz built exactly this table before moving to a PDF kit. Right for a first edition with no photo assets or a hard outreach deadline (Q6).
Text one-pager with tier prices - the floor when even a table can't be maintained. Keep the price summary and the three facts sponsors always ask about (audience, why sponsor, what per level).
Full illustrated PDF kit linked from a web stub - the starved option: tops value and effort, so efficiency never picks it, yet it is the dominant pattern for community conferences past edition one - the live sponsor page is a short stub whose real prospectus is a downloadable, dated PDF. Promotion conditions: prior-edition photos and testimonials exist (Q3), design hours are available (Q8), or the mandate is a compounding annual asset (Q7).
A no-price document is deleted, not demoted - a prospectus that never states prices forces a reply-to-ask step that costs conversions. The one exception: the rate card was deliberately quote-gated in
```
samber/dev-event-organizer-skills@event-sponsor-pricing
```
(a network/portfolio-scale pattern) - then the gate is a pricing decision this document inherits, not a document omission.

要构建多少文档。排序（默认值，而非定律——问题6-8会重新排序）：

工作量（设计与排版工时）：

完整图文PDF套件 > 页内层级表页 == 纯文本一页纸

价值（对勤勉赞助商的转化信号：价格可见、证据可见、可在赞助商组织内部转发）：
```
完整图文PDF套件 > 页内层级表页 > 纯文本一页纸
```

效率：

页内层级表页 > 纯文本一页纸 > 完整图文PDF套件

工作量并列是有理由的：两个底层层级都只需一个下午组装同级skill已经产出的内容，不需要摄影，也不需要排版工具。散文摘要与HTML表格之间的区别只是格式，而不是新工作。

页内层级表页 - 默认层级：一个承载完整层级网格、价格和联系邮箱的网页。无需设计能力数天内即可上线，而且这是一种真实格式——DevOpsDays Graz 在转向PDF套件之前正是构建了这样的表格。适合没有照片资产或外联截止日期紧迫（问题6）的首届活动。
带层级价格的纯文本一页纸 - 即使表格也无法维护时的底线。保留价格摘要和赞助商总会问到的三个事实（受众、为什么赞助、每个级别包含什么）。
由网页短页链接的完整图文PDF套件 - 最耗资源的选项：价值和投入都最高，所以效率永远不会选它，但它是第二届以后社区会议的主流模式——线上赞助页面只是一个短页，真正的计划书是一份可下载、带日期的PDF。提升条件：存在往届照片和推荐语（问题3）、有可用设计工时（问题8）、或任务属于累积型年度资产（问题7）。
无价格文档应予删除，而非降级 - 一份从未标明价格的计划书会迫使“回复询问”的步骤，从而损失转化。唯一的例外：价目表是在
```
samber/dev-event-organizer-skills@event-sponsor-pricing
```
中刻意选择“报价门控”模式（一种网络/组合规模模式）——那么门控是这份文档继承的定价决策，而不是文档遗漏。

Demographics-evidence depth

人口统计证据深度

How deep the audience section goes. Ranking (default, not a law - the verified data from Q4 is the ceiling, never the target to inflate toward):

effort (collection + verification):

survey-backed breakdown > aggregate composition breakdown > verified one-liner

value (what it answers for a diligent sponsor's "who attends"):

survey-backed breakdown > aggregate composition breakdown > verified one-liner

efficiency:

aggregate composition breakdown > verified one-liner > survey-backed breakdown

Dominance check: 3 pairs, zero strict-dominance relations - clean only by construction, and by-construction is never a pass. Value and effort are the same list, so one mechanism blocks every pair: the deeper breakdown answers more and costs strictly more to collect and verify, and no third axis is printed. The check catches no misordering; the ordering rests on the argument below.

Default rung: print the deepest rung that is real and verified. With registration-form data, that is the aggregate composition breakdown - role mix, industry mix, company-size bands, each as labeled percentages, the shape PyCon US prints (2,500+ attendees, 53.9% Developer, Software 43%/Finance 13%/…).
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
's default instrument produces exactly this data.
Verified one-liner - the honest floor for a small or first-edition event: DevOpsDays Graz prints one sentence ("Up to 300 industry professionals, aged 25 to 40 years"). A thin true line beats a thick fabricated table.
Survey-backed breakdown (buying influence, seniority detail, tool adoption) - the starved option: top of value and effort. Promotion condition, keyed to Q9: courting an anchor or presenting-tier sponsor whose diligence asks about buying influence, or a vendor-pole event where composition claims carry the price. Collection mechanics and their compliance load belong to
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
's instruments menu.
Hard rule at every rung: never publish a breakdown whose category-to-number mapping you cannot verify - the PyCon PDF itself prints a company-size split whose band mapping is layout-ambiguous, and the discipline is to not quote it. A garbled table is a worse credibility signal than fewer categories shown correctly. Never fabricate percentages to match a bigger event's table shape.

受众部分的深入程度。排序（默认值，而非定律——问题4中经过验证的数据是上限，绝不是要膨胀趋近的目标）：

工作量（收集+验证）：

调研支持的分项 > 汇总构成分项 > 经核实的一句话

价值（对勤勉赞助商“谁参加”问题的回答）：

调研支持的分项 > 汇总构成分项 > 经核实的一句话

效率：

汇总构成分项 > 经核实的一句话 > 调研支持的分项

支配性检查：3对，零严格支配关系——仅靠构造干净，而构造干净永远不是通过。 价值和投入是同一个列表，所以一种机制阻挡了每一对：更深的分项回答得更多，但收集和验证的成本也严格更高，并且没有印出第三轴。检查无法发现排序错误；排序依赖于下面的论证。

默认层级：印出真实且经过验证的最深层级。如果已有报名表数据，那就是汇总构成分项——角色构成、行业构成、公司规模区间，每个都有明确标注的百分比，即 PyCon US 印出的形态（2500+ 参会者、53.9% 开发者、软件 43%/金融 13%/…）。
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
的默认工具恰好产生此类数据。
经核实的一句话 - 小型或首届活动诚实的底线：DevOpsDays Graz 只印一句话（“最多 300 名行业专业人士，年龄 25 至 40 岁”）。一条单薄但真实的话胜过一张厚实但伪造的表格。
调研支持的分项（购买影响力、资历详情、工具采用情况）——最耗资源的选项：价值和工作量都最高。提升条件，与问题9对应：正在争取锚定或展示级赞助商，其尽职调查需要了解购买影响力；或者处于厂商驱动活动的端点，其中构成声明直接支撑价格。收集机制及其合规负担属于
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
的工具菜单。
每个层级的硬规则：绝不发布你无法验证类别到数字映射的分项—— PyCon 的 PDF 本身就印有一个公司规模细分，其区间映射在排版上有歧义，纪律就是不要引用它。一张混乱的表格比少数几个正确展示的类别带来更差的可信度信号。绝不编造百分比来模仿更大活动的表格形态。

Perk presentation

权益展示

How the perks catalog appears on the page. Ranking (default, not a law - Q5 re-ranks):

effort:

tier grid + named add-on cards > single checkmark grid

value:

tier grid + named add-on cards > single checkmark grid

efficiency:

single checkmark grid > tier grid + named add-on cards

Dominance check: 2 rungs, 1 pair, zero strict-dominance relations - clean only by construction, and that is not a pass. Value and effort run in one order, so the single pair fails on cost: the add-on cards buy more and cost more. A two-rung menu has nothing else to check, no third axis is printed, and the efficiency call is argued below, not verified.

Single checkmark grid - the default: rows are perk line items, columns are tiers, plain marks for inclusion, numbers only for genuine quantities (ticket counts, discount percentages). Keep 3-7 named perk items per tier before the table stops being readable (the real Graz table holds ~10 line items across 5 tiers, most cells blank).
Grid + named add-on cards - the starved option. Promotion condition: single-exclusive surfaces or experiential perks exist (Q5).
- Move them out of the grid into à-la-carte cards, each an icon + name + price + one line: the sourced pattern ("Photo Booth Sponsor", "Party Sponsor").
- Name every perk, don't describe it. Container words that signal format ("Track", "Fair", "Lounge", "Corner") do the work.
Bespoke per-sponsor proposals are deleted, not demoted - a prospectus is a standard published offer sent to many prospects. A proposal scoped to one buyer's stated requirements is a different document. Tailoring which sections to emphasize per reader title (DevRel → product feedback, Marketing → brand, HR → recruiting perks) belongs to
```
samber/dev-event-organizer-skills@event-sponsor-outreach
```
, not to this document.

Each tier's perk stack should visibly answer a real sponsor concern - attendee value, who else sponsors, package value, the three that hackathon organizer guidance names - not just pile on logo placements. The full perk catalog, including hackathon-specific perks (sponsored prize tracks, sponsor chat channels, workshops, recruiting formats), is in references/tier-table-and-perks.md.

权益目录在页面上的呈现方式。排序（默认值，而非定律——问题5会重新排序）：

工作量：

层级网格 + 具名附加卡片 > 单一勾选网格

价值：

层级网格 + 具名附加卡片 > 单一勾选网格

效率：

单一勾选网格 > 层级网格 + 具名附加卡片

支配性检查：2个层级，1对，零严格支配关系——仅靠构造干净，那不是通过。 价值与工作量以同一顺序排列，所以唯一一对在成本上失败：附加卡片买得更多、花得也更多。只有两个层级的菜单没有其他可检查的，没有印出第三轴，效率判断在下面论证，而非验证。

单一勾选网格 - 默认方式：行是权益细项，列是层级，用简明标记表示包含，数字只用于真实数量（门票数、折扣百分比）。每个层级保持3-7个命名的权益项，超过后表格将不再易读（真实的Graz表在5个层级中约有10个细项，大多数单元格为空）。
网格 + 具名附加卡片 - 最耗资源的选项。提升条件：存在单一独家品牌面或体验式权益（问题5）。
- 将它们从网格中移出，放入点菜式卡片，每张卡片包含图标+名称+价格+一句话：源自真实案例的模式（“Photo Booth赞助商”、“派对赞助商”）。
- 为每项权益命名，而不是描述它。表示格式的容器词（“Track”、“Fair”、“Lounge”、“Corner”）就能发挥作用。
为单个赞助商量身定制的提案应予删除，而非降级 - 计划书是发给众多潜在赞助商的标准公开发布报价。针对某个买家具体要求范围的提案是另一种文档。根据读者身份定制强调哪些章节（DevRel → 产品反馈、市场 → 品牌、HR → 招聘权益）属于
```
samber/dev-event-organizer-skills@event-sponsor-outreach
```
，而不是本文档。

每个层级的权益堆叠应明显回答一个真实的赞助商关切——参会者价值、还有谁在赞助、套餐价值，这是黑客松组织指南提到的三个——而不只是堆砌logo位。完整的权益目录，包括黑客松特有权益（赞助奖项轨道、赞助商聊天频道、工作坊、招聘形式），见

[references/tier-table-and-perks.md](references/tier-table-and-perks.md)

。

Hackathon note

黑客松说明

MLH itself gates sponsorship behind a contact form and publishes reach numbers, not a prospectus, and its own organizer guidance tells member hackathons to keep any prospectus to 2-3 pages since "sponsors generally don't have time to read through a big sponsorship deck" - likely why MLH-affiliated campus events (HackMIT, PennApps, TreeHacks) route to email instead of a PDF. Independently-run hackathons do publish fuller kits: Cal Hacks 13.0's 5-page packet matches the conference anatomy almost completely, though it orders its tier table before proof and testimonials, reversing the conference proof-before-price default (see references/document-anatomy.md). Hackathon perks slot into the same tier-table and add-on structure either way. Validate page order and depth with the organizer rather than assuming either pattern - MLH's thin-deck advice and Cal Hacks' full kit are both real, sourced inputs, not the same recommendation.

MLH 本身将赞助门槛设在联系表单后面，并只发布触达数字，而不是计划书；它自己的组织者指南告诉会员黑客松将任何计划书控制在2-3页，因为“赞助商通常没有时间阅读一份冗长的赞助演示文稿”——这很可能是 MLH 附属校园活动（HackMIT、PennApps、TreeHacks）转向邮件联系而不是PDF的原因。独立举办的黑客松确实会发布更完整的套件：Cal Hacks 13.0 的 5 页文档几乎完全匹配会议解剖结构，但它将层级表排在证据和推荐语之前，逆转了会议“证据先于价格”的默认顺序（见

[references/document-anatomy.md](references/document-anatomy.md)

）。无论哪种方式，黑客松权益都嵌入相同的层级表和附加结构。应与组织者确认页面顺序和深度，而不是假定采用哪种模式——MLH 的薄文档建议和 Cal Hacks 的完整套件都是真实、可溯源的输入，而非同一建议。

Failure modes

失败模式

Printing a guarantee - any guarantee. DevOpsDays Graz, PyCon US, DjangoCon US and Cal Hacks 13.0 all omit a guarantee clause of any type, a named anti-pattern, not an omission, across both conference and hackathon documents. A performance guarantee ("we guarantee 50 qualified leads") directly contradicts the honesty constraint: community-run events cannot promise lead value at all, and even vendor-run events sell access and placement, never a promised outcome. The nearest real counterexample found is GoatHacks 2023's recruiting section, which promises "the resumes and contact information of all participating students" to every sponsor tier with no cap or hedge - never phrased as a guarantee, but functionally one, and the exact shape this failure mode exists to catch. General offer-construction advice pushes guarantees hard, but this skill rejects it explicitly.
Manufactured scarcity. A "max available" row is printable only when the cap is real (floor space, a single lanyard) - the honest pattern is a published, genuine ceiling (Gold capped at 3, Silver 6, Bronze 20). Never invent a cap, never leave a stale "2 left" counter running past the point it's true.
Stale prospectus reuse. An undated evergreen document, last year's testimonials presented as current, logos of sponsors who didn't return, caps that no longer match inventory. The cadence is a fresh dated document per edition ("Sponsor Information 2026") with per-edition testimonial refresh.
Demographics overclaiming. Fabricated percentages, an unverifiable mapping, or a first edition wearing a big event's table shape - see the hard rule in the demographics menu.
Burying the price. The price row leads the tier table in published prospectuses, and every unanswered price costs a reply-to-ask exchange. Prices go in the document unless quote-gating was a deliberate pricing decision.
Selling sponsor benefits harder than the attendee experience. The buyer-side warning sign diligent sponsors are told to watch for. The anatomy above spends its first half on the event's own credibility (brand, facts, community) before any package appears.
Lead-data rows at the community pole. Structurally undeliverable. See the pole section.
A perks list with no why. Booth sizes and logo placements without the value-proposition content upstream produce a document no budget holder can route internally - route back to
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
instead of padding the table.

印出任何形式的保证。 DevOpsDays Graz、PyCon US、DjangoCon US 和 Cal Hacks 13.0 在会议和黑客松文档中都完全省略了任何类型的保证条款；这是一个被点名的反模式，而非疏漏。绩效保证（“我们保证50个合格线索”）直接违背诚实性约束：社区驱动活动根本无法承诺线索价值，即使是厂商驱动活动销售的也是接触机会与展示位置，而不是承诺的结果。找到的最接近的真实反例是 GoatHacks 2023 的招聘部分，它向每个赞助商层级都承诺“所有参与学生的简历和联系方式”，且没有任何上限或对冲——从未表述为保证，但在功能上就是保证，这正是该失败模式要捕捉的形态。通用的报价构建建议会大力推动保证，但本skill明确拒绝。
人为制造的稀缺性。 只有在上限真实（展位面积、唯一挂绳）时，“剩余数量”行才可以印出——诚实的模式是发布一个真实的上限（Gold上限3、Silver 6、Bronze 20）。绝不杜撰上限，绝不让过时的“剩余2个”计数器在不再真实之后继续显示。
复用陈旧计划书。 一份无日期的常青文档、被当作当前的去年推荐语、未回归赞助商的logo、已与库存不符的上限。正确的节奏是每期发布一份带日期的新文档（“Sponsor Information 2026”），并每期刷新推荐语。
人口统计过度宣称。 编造的百分比、无法验证的映射、或首届活动套用大型活动的表格形态——参见人口统计菜单中的硬规则。
埋没价格。 在已发布的计划书中，价格行位于层级表首位；每一个没有标出的价格都会造成一次“回复询问”的往返。价格应写入文档，除非“报价门控”是一个刻意的定价决策。
推销赞助商利益胜过参会者体验。 这是勤勉赞助商被告知要警惕的买方端警告信号。上面的解剖结构在前半部分先展示活动自身的可信度（品牌、事实、社区），然后才出现任何套餐。
在社区端点出现线索数据行。 结构性不可交付。参见端点部分。
没有为什么的权益清单。 只有展位大小和logo位而没有上游价值主张内容的文档，是任何预算持有者都无法在内部推动的——请导回
```
samber/dev-event-organizer-skills@event-sponsor-value-proposition
```
，而不是给表格注水。

Measurement

衡量

Prospectus quality has no close-rate figure behind it, so never quote one. What is observable is downstream and self-set. Pick 2-3 and write down the revision each triggers:

Reply-to-ask rate (self-set): prospects replying to ask for information the document should carry - price, dates, audience composition, what a tier includes - flag a document defect, not a sales problem. Have
```
samber/dev-event-organizer-skills@event-sponsor-outreach
```
log these by section.
Forwardability (self-set): the document should survive being forwarded to the budget holder without the organizer on the thread. A champion who has to explain it from the top signals a missing section.
Per-edition freshness check (self-set): before each edition's first send - dated title matches the edition, testimonials and logos are from the latest edition, every printed cap re-verified against real inventory.

计划书质量背后没有转化率数字，所以永远不要引用一个。可观察的是下游指标，且由自己设定。选择2-3个，并写下每个指标触发的修改：

回复询问率（自设）：潜在赞助商回复询问文档本应包含的信息——价格、日期、受众构成、层级包含什么——标志的是文档缺陷，而不是销售问题。让
```
samber/dev-event-organizer-skills@event-sponsor-outreach
```
按章节记录这些询问。
可转发性（自设）：文档应能在组织者不在邮件线程的情况下被转发给预算持有者。一个需要从头解释文档的内部支持者，意味着缺少某个章节。
每期新鲜度检查（自设）：在每期首封外联邮件发出之前——日期标题与当季相符、推荐语和logo来自最近一期、每个印出的上限都已对照真实库存重新验证。

Invocation examples

调用示例

"Our DevOps conference has its value story and tier prices - turn them into the sponsorship kit PDF."
"Build the sponsor packages page for our first-edition meetup; we have no photos yet and outreach starts in two weeks."
"Rework our tier table: five tiers, two of them are just 'your logo on the lanyard' style exclusives, and sponsors keep emailing to ask what things cost."
"Refresh last year's prospectus for the 2027 edition."

Expected output, in the credibility-before-price order and presented section by section for validation:

A section-by-section document outline, or full draft.
The tier table with its price and cap rows.
Add-on cards where promoted.
The audience-evidence section at its verified depth.
The distribution choice.
The per-edition refresh checklist.

“我们的DevOps会议已经有了价值故事和层级价格——把它们变成赞助套件PDF。”
“为我们首届meetup构建赞助套餐页面；我们还没有照片，外联两周后开始。”
“重做我们的层级表：五个层级，其中两个只是'你的logo印在挂绳上'式的独享权益，而赞助商一直在邮件问价格。”
“为2027年活动刷新去年的计划书。”

预期输出，按先信誉后价格的顺序，逐节呈现以供验证：

逐节文档大纲，或完整草稿。
带价格行和上限行的层级表。
在采用时提供附加卡片。
受众证据部分按经过验证的深度呈现。
分发方式选择。
每期刷新检查清单。

References

参考

references/document-anatomy.md - the generalized page-by-page anatomy with a 9-page worked example, the pitch-deck comparison, the sponsor logistics FAQ checklist, and what real prospectuses deliberately leave out.
references/tier-table-and-perks.md - the worked tier table (rows, prices, caps), the perk catalog by sponsor motivation including hackathon perks, naming guidance, and the scarcity never-do list.
references/audience-evidence-and-distribution.md - the two audience-evidence models (composition breakdown and one-liner floor), the verification rule, distribution formats, and the per-edition update cadence.