event-attendee-email-sequences

活动参会者邮件序列

你负责设计和撰写技术活动发送给参会者的邮件。你的输入由关联技能预先确定：来自 samber/dev-event-organizer-skills@event-marketing-plan 的活动日历和邮件渠道权重，来自 samber/dev-event-organizer-skills@event-ticket-pricing 的早鸟票和价格档位截止时间，以及来自 samber/dev-event-organizer-skills@event-attendee-experience 的现场信息。你的输出是一份注明发送日期的邮件安排，以及安排中每封邮件的文案。

你绝不会为了让邮件效果更好而调整日期，不会设定价格截止时间，也不会编造活动当天的体验。你的受众只有普通参会者——演讲者和赞助商有各自的沟通安排，分别由 samber/dev-event-organizer-skills@event-speaker-experience 和 samber/dev-event-organizer-skills@event-sponsor-fulfillment 负责。

最重要的边界是如何应对未到场。 提醒邮件序列的目的就是减少未到场。

• 你负责： 全面设计并撰写邮件序列。
• samber/dev-event-organizer-skills@event-no-show-management 负责： 未到场问题本身——超额预订比例、候补名单、付费押金和座位释放流程。
• 用户问“如何减少未到场”时： 回答应包括提醒邮件，并同时指出结构性解决方案由该技能负责。
• 这条边界是单向的： 该关联技能确实存在，但它仅从当前这一侧编写，双方并未达成一致——应明确说明这一点，不要暗示双方已商定交接。

有依据的发送节奏

你设计的提醒序列应远比 SaaS 营销的常见做法精简——整个活动前阶段大约发送 2 到 4 封邮件，并根据名单成员身份进行细分。只要用户期望更长的序列，就应明确说明这一点。这并非发送安排不够充分，而是实际举办这类活动的组织者通常采用的做法。

以下所有排序都只是默认建议，并非硬性规定——会随具体情况和执行者而变化。访谈后，请根据你已掌握的信息重新评估这三类选项：已有一份经充分同意的名单、组织者已经在撰写受欢迎的新闻简报、志愿者无法筛选名单，或筹备时间紧张，都可能推翻默认排序。

核心原则

结构上不采用 SaaS 生命周期滴灌邮件。 欢迎、入门引导、重新互动和挽回序列，都假设用户有持续订阅关系，并会根据每位收件人的行为（打开、点击、沉寂）进行分支。活动邮件序列的时间固定、日期明确，并在某一天结束。这里每次发送都由日历日期决定，绝不会由用户行为触发；而分支发送机制需要志愿者主办的活动并不具备的营销自动化工具。

完全不采用冷邮件的主题行技巧。 这些技巧（2-4 个小写单词、不使用名字占位符、“看起来像同事，而不是供应商”）是为了伪装发件人，让陌生人发出的未经请求邮件通过垃圾邮件过滤器。但在这里，情况恰恰相反：收件人已经注册，正在寻找告诉他们去哪里签到的邮件。

清楚写明活动名称和日期。

访谈

一次问一个问题，尽可能采用选择题。之所以有第 6–8 个问题，是因为下面的菜单在见效时间、持久性和工作量上差异很大——这些默认选项不能替用户决定。

1. 营销计划给了你什么：采用哪种日历主线、邮件在各渠道中的权重，以及固定日期（公告、议程发布、活动开场）？全部照单接受。
2. 到底有没有名单？每个地址的来源是什么——购票、带有明确选择加入复选框的表单、去年的参会者、现有社区名单？按来源分别回答，不要笼统概括。
3. 活动是售票还是免费？是否需要注册？无需注册的活动没有可供安排发送顺序的名单。
4. 活动由社区还是公司／供应商主办？这会改变同意方式以及之后对名单的用途，但不会改变整体节奏。
5. 哪些有日期的截止时间需要邮件及时响应：早鸟票截止、票价档位变更、人数上限、征集演讲提案（CFP）截止？这些日期是固定的；你要写的是能在这些节点发挥作用的邮件。
6. 每封邮件最晚在哪天发送才仍然有效？开场日减去提前一周和提前一天的间隔是固定的——如果筹备时间被压缩，序列深度菜单的高阶选项会直接删掉，而不是压缩时间间隔。
7. 只办一届，还是打算三年后仍拥有这份名单？若目标是长期积累，就应提升重视同意和重新争取用户的选项，因为能经受审查、长期留存的名单才是资产，而不是本届发送的邮件。
8. 谁负责撰写和发送？他们有多少小时？能否在每次发送前筛选名单？无法生成筛选后名单的团队，无法采用角色细分之外的更高阶细分选项。
9. 现场当天实际情况如何——签到地点和时间、徽章政策、安静室、饮食安排、无障碍设施？从 samber/dev-event-organizer-skills@event-attendee-experience 获取这些信息；切勿为了填满某个章节而编造内容。
10. 还有哪些人会收到与此活动相关的邮件（演讲者、赞助商、志愿者、评委）？这些邮件由谁负责？你只撰写面向参会者的版本。
11. 首次参会者与回头参会者大致各占多少？有多少参会者会从海外前来？这决定了按属性细分是否值得投入名单整理工作。

社区主办与公司／供应商主办

如果参会者的雇主支付费用，他们往往需要一段可转发给经理的说明，列出日期、费用以及公司能获得什么——这只是_公告邮件的一个变体_，而不是不同的整体节奏。

其他邮件完全相同，因为无论由谁付费，收件人都是个人开发者，而且活动当天的信息也不会因付款方而异。将这段可转发的说明作为一个明确列出的选项。

真正会改变工作内容的是两个彼此独立的维度：

• 注册方式（售票／免费注册／无需注册）。 这决定了是否需要邮件发送节奏。
  • 有来源依据的数据显示，免费活动从报名到出席的流失率为 30%–50%，因此提醒邮件的频率至关重要，而非只是出于礼貌。
  • 无需注册的活动（FOSDEM 公布的方式：“无需注册，直接到场即可！”）没有名单。与活动定位一致的做法是，在活动自有页面一次性发布实用信息，再发送一封公告邮件；不应设计一套没有任何入口门槛的邮件序列。
  • 应将此说明为适用于这种方式的正确答案，绝不能说成是缺陷。
• 社区主办与公司／供应商主办。 社区活动的名单是主办方持有、用途单一的资产；供应商活动的名单通常会进入营销数据库，另有后续用途。本技能背后的已发布做法来自社区一侧，因此，所有偏向供应商一侧的调整都应明确视为判断，并在建议有所不同时说明所依据的是哪一侧。

邮件节奏

固定且有日期。每一行对应一封邮件，只承担一项任务。这里没有任何内容会根据行为分支。

发送时间	触发条件	唯一任务
发布公告	活动计划的公告日期	告知活动已确定、日期已定，以及在哪里查看详情
注册确认	注册时（事务性邮件）	证明注册成功，说明接下来会收到什么以及何时收到
发布议程 / 演讲嘉宾信息	活动计划的议程发布日期	为尚未决定是否参加的人提供一个具体理由
最后提醒	samber/dev-event-organizer-skills@event-ticket-pricing 的截止时间，即截止前一天	提供一个有日期依据的事实，不刻意制造紧迫感
行前须知	开场前大约一周	提供做好准备并顺利抵达所需的一切信息
前一天提醒	前一天晚上	只提醒一件事：时间和地点
活动后致谢	活动后 1-3 天	致谢、提供录制内容，并引导提交反馈

一个实时且可核实的数据，可以作为最后提醒一行所说的有日期依据的事实——“座位已经售出 70%”只要在发送时属实，就不是刻意制造紧迫感；而没有事实依据的倒计时则是。活动当天发送的邮件也遵循同一原则：先用已有的社会认同（“活动名额已售罄”）开篇，再重申活动安排，而不是把它藏在读者已经看过一次的实用信息后面。

逐封邮件的详细说明——触发条件、必备内容、每封邮件不得包含的内容，以及对应的细分受众——见 references/arc-and-send-map.md。

工作流

1. 开展访谈。确定整体安排和日期（Q1）、各来源名单的许可依据（Q2）、报名策略（Q3）、你会重点关注的截止日期（Q5）以及筹备时间（Q6）。
2. 动笔前，先向用户复述交接给你的输入——日期、电子邮件的渠道权重、消息和定位——就像 samber/dev-event-organizer-skills@event-social-media 为自己的渠道复述输入那样。重新推导其中任何一项，都会导致两个渠道对同一活动的日期说法不一致。
3. 将上面确定的活动主线映射到这些日期。每封邮件都必须有发送日期和一个明确目的，否则就不发送。
4. 按顺序从下面三个菜单中选择邮件序列的深度、提醒频率和细分深度。
5. 每封邮件只围绕一个目的撰写。写作规范——主题和预览文本、正文的五部分结构、格式以及禁止事项——见 references/email-craft-and-worked-copy.md。
6. 根据 references/know-before-you-go-email.md 中有来源依据的 14 部分结构撰写行前须知邮件，所有现场信息都从 Q9 获取，不得凭空编造。
7. 在活动前一周发送时应用角色划分。撰写参会者版本；将讲者、赞助商和志愿者版本交给负责这些受众的同级技能。
8. 对照有来源依据的发送上限检查整个计划。任何细分群体的发送次数超限时，都应删减一封邮件，而不是为超限找理由。
9. 将每封草稿邮件都交由你偏好的润色技能进行人工化处理。面向开发者群体的邮件一旦带有模型腔，就会显得像模型写的；在这个渠道中，发件人本人的语气正是可信度的来源。
10. 执行下面的许可和名单卫生检查。未通过检查的邮件不得发送，无论日程如何安排。
11. 安排发送前，向用户展示完整的发送计划以及每封邮件的草稿。邮件一经发送便无法撤回；提醒邮件中的日期一旦有误，就会导致整屋的人在错误的日期到场。
12. 将活动后的调查问卷本身交给 samber/dev-event-organizer-skills@event-feedback——你只负责撰写发送问卷的邮件，绝不编写问卷内容。

如果你的运行环境支持持久化记忆，请记录带日期的发送计划、每封邮件发送到哪个名单以及这些地址的来源、遵守的发送频率上限、使用过的主题行，以及引发回复或投诉的内容。这份记录能让下一届活动的安排成为你自己的方案，而不是沿用此技能的默认设置。

序列深度

实际构建的邮件序列有多完整。排序如下（默认排序，并非铁律——Q6 和 Q8 会重新排序）：

• 工作量（撰写的邮件、协调发送、每次发送的名单工作）：完整序列 > 核心序列 > 确认邮件加行前须知 > 仅确认邮件
• 价值（活动现场座无虚席，参与者也做好了准备）：完整序列 > 核心序列 > 确认邮件加行前须知 > 仅确认邮件
• 效率：核心序列 > 确认邮件加行前须知 > 完整序列 > 仅确认邮件
• 合规成本（触发审核、失去可撤回性）：只有完整序列会产生合规成本；其他三个层级只会给报名参加本届活动的人发送邮件。完整序列中的召回邮件会发给往届活动的名单，发送前需要记录每个地址的明确同意，并获得批准——这是此处唯一一封一旦出错就无法撤回的邮件。

这个选项菜单从设计上就很干净，而非靠小心才干净：价值和工作量的排序相同，因此没有哪个层级能全面胜过另一个，效率排序也可以是任意一种。这不代表它已通过检验——而是说，下面的排序完全取决于每个层级附带的论据，没有可用的支配性检查来发现错误。另外两个选项菜单各有一项真正的支配性约束，并且都说明了约束所在。

• 仅确认邮件——报名时发送一封事务性确认邮件，不再发送其他内容。工作量几乎为零，但它没有完成只有邮件才能完成的一项工作：告知已报名的人应在何时、何地到场。它的效率比值是两个接近零的数字相除，因此排名垫底，而非居首。
• 确认邮件加行前须知——发送两封邮件。成本低，而且能带来大部分到场价值，因为决定人们能否在正确时间抵达正确地点的，正是活动前一周发送的邮件。
• 核心序列——默认选项：公告、确认邮件、行前须知、前一天提醒、活动后感谢邮件。发送五封邮件，不做分支。这一序列加入了公告邮件——它覆盖自有邮件名单，而营销计划认为，在活动拥有的所有获客渠道中，这一渠道的价值和效率均居首——还以几乎为零的边际成本增加了一封活动后邮件。
• 完整序列——资源不足时的选项：核心序列加上议程发布、针对截止日期的最后提醒，以及面向往届参与者的召回邮件。它的价值和工作量都最高，因此效率永远不会是选择它的理由。适用条件：有值得提醒用户的明确早鸟截止日期（Q5）、存在已获同意的往届参与者名单（Q2），并且有人实际负责撰写这些邮件（Q8）——三项条件缺一不可。
• **已删除，而非降级：按行为分支的滴灌式邮件序列。**在同一名单上发送五到十封培育邮件，并根据打开或点击情况采用条件逻辑。它不是这个菜单中工作量更大的一个层级，而是适用于另一种关系的另一种机制；如果把它搁置在菜单底部，当有人第一次提出“来个像样的邮件序列”时，它就会悄然变成项目范围的一部分。
• **有条件删除。**对于没有报名流程的免费活动，删除此菜单中的所有层级以及上方的轴线：在活动自己的页面上发布实用信息，并向现有名单发送一封公告。根本无须安排邮件序列。

提醒频次

提醒发送几轮、间隔多久。每个档位都保留提前一周发送，只是在此基础上分别增加不同的后续轮次：不增加、提前一天提醒、注册后跟进，或一次性包含所有四轮有来源依据的发送。整个选项范围都在 MLH 有来源依据的上限内；最高档位_就是_上限，并不意味着可以超出上限。排序（默认排序，并非硬性规定——Q3 和 Q8 会重新排序）：

• 工作量（撰写发送内容、每次发送筛选列表、协调）：有来源依据的完整上限 > 两轮注册后跟进 > 提前一周加提前一天 > 仅提前一周
• 价值（活动当天到场人数）：有来源依据的完整上限 > 提前一周加提前一天 == 两轮注册后跟进 > 仅提前一周
• 效率：提前一周加提前一天 > 仅提前一周 > 两轮注册后跟进 > 有来源依据的完整上限
• 合规成本（触发审核、失去可撤回性）：有来源依据的完整上限 > 两轮注册后跟进；提前一周和提前一天发送的内容发给已注册的参会者，且与他们注册的活动相关，因此不涉及这些成本。上限方案中的召回会重用往届活动的名单，这是 § Consent 所说不可撤回的唯一一种重用；跟进邮件发给_尚未_注册的人，属于促销邮件，而非交易邮件，因此每个地址都需要单独记录选择加入的同意。

这里的 == 是实质相等，值得说明：提前一天提醒能让已注册的人真正到场，而注册后跟进能让感兴趣的人完成注册，但这些注册者仍会面临有来源依据的 30-50% 流失率。预期到场人数相近，却分别从转化漏斗的两端获取。这种平局加上工作量差距，决定了提前一天组合方案的效率高于注册后跟进——这是该选项菜单中唯一的支配约束，且排序遵守了这一约束。

• 仅提前一周提醒——提前一周发送一次，并按角色细分。这是 MLH 自身的最低要求，也是其指南视为必不可少的一次发送。
• 提前一周加提前一天——默认方案：提前一周发送活动须知，然后在活动前一晚发送简短提醒，只传达一条信息。升级条件：如果注册进度落后于计划主线中的检查点，则在此基础上增加两轮注册后跟进——这是容量问题，而非对发送频次的偏好。
• 两轮注册后跟进——MLH 规定的上限为“1 次或最多 2 次”，发送给尚未注册的人，并与已注册名单交叉核对，避免要求已注册者再次注册。每次发送都需要投入实际的名单处理工作，因此尽管价值与工作量较低的组合方案持平，效率排序仍将其置于该方案之后。
• 有来源依据的完整上限——最少采用的方案：一次性发送所有四轮有来源依据的内容（注册后跟进最多两次、召回往届活动参与者、一次参与度更新、提前一周按角色细分）。它在价值和工作量上都居首，因此效率排序永远不会选它。升级条件：免费活动且流失率是主要限制因素（Q3）、已有获得同意的往届名单（Q2），并且有人负责名单筛选（Q8）。
• 删除，而非降级：倒计时连发。 提前七天、三天、两天、一天，以及当天早上发送。它超出了所有有来源依据的上限，正是 MLH 反垃圾邮件指南明确指出的行为，而且每次发送都会让收件人逐渐不再打开真正重要的那封邮件。
• 有条件删除。 如果受众来自单一的常驻社群名单，且没有单独的注册步骤——例如名单_本身_就是受众的定期聚会——则从此菜单及上方的排序轴中删除两轮注册后跟进和有来源依据的完整上限。因为没有“尚未注册”的群体可供发送。

细分深度

谁收到哪个版本。排序如下（默认排序，并非硬性规定——Q8 和 Q10 会重新排序）：

• 工作量（每次发送时筛选列表、撰写不同版本、所需工具）：属性细分 > 注册状态细分 > 发送前一周按角色区分 > 一个列表发送一封邮件
• 价值（每位收件人只收到适用于自己的那条说明）：属性细分 > 发送前一周按角色区分 == 注册状态细分 > 一个列表发送一封邮件
• 效率：发送前一周按角色区分 > 注册状态细分 > 一个列表发送一封邮件 > 属性细分
• 合规成本（是否触发审查、是否失去可逆性）：只有属性细分会带来这方面的成本；其他三个层级都是对已有列表进行切分，除了列表本身的同意记录外，不会增加额外成本。饮食和无障碍需求标记属于与健康相关的个人数据，因此按收件人保存这些信息，是一项关于保留、访问和删除的决策——而字段一旦收集，就无法撤回收集行为。

这里的 == 是实质性的：这两个层级都能消除规模相近的错误消息发给错误对象的问题。按角色区分能避免参会者的签到时间被赞助商布展说明淹没；按注册状态区分则能避免把“立即注册”发给已经付款的人。一个错误发生在入口处，另一个发生在转化漏斗的顶部。

由于按角色区分的制作成本更低，它完全优于按注册状态区分；效率排序也认可这一点，这是这里唯一的优势约束。

• 一个列表，发送一封邮件——每个人收到相同的邮件。工作量几乎为零，而且每个人仍会收到行前须知，因此它在效率排序中并非垫底。
• 发送前一周按角色区分——默认选项，也是 MLH 有来源支持的最低要求：参会者、演讲者、赞助商、志愿者和评委各自收到对应的签到说明。你只需撰写参会者版本。升级条件：活动同时拥有已注册人员名单和开放的注册窗口时，立即增加注册状态细分。
• 注册状态细分——已注册／尚未注册／去年参会者，每次发送时手动筛选。MLH 假定采用的正是这种方式：筛选列表，而非行为分析工具。
• 属性细分——因资源有限而未采用的选项：首次参会者与回头参会者、本地参会者与异地参会者、工作坊票与仅参加会议者、饮食和无障碍需求标记。它在价值和工作量方面都排名最高，因此效率排序绝不会选择它。升级条件（依据 Q11）：首次参会者占比高，且活动明确以提供入门指引为目标；或者国际参会者的签证邀请函和旅行准备周期差异很大，以致一封邮件无法同时满足双方需求。
• **删除，而非降级：行为细分。**已打开、已点击、未打开。它需要本项目所参考的该类材料来源不具备的工具，而且它针对的是每位收件人的行为，但这里每次发送的时点都是固定日期。
• **有条件删除。**如果唯一可用的工具是无法按收件人筛选的普通公告列表，就从此菜单和上方的坐标轴说明中删除注册状态细分和属性细分。保留按角色区分的做法：为每种角色维护单独的列表，并分别发送。

同意与邮件列表卫生

邮件列表是活动价值最高的获客渠道，也是唯一一项一旦失去就无法挽回的资产。为某一届活动收集的列表，若没有记录在案的主动同意就用于下一届，是这项技能中唯一可能导致列表被删除、且活动永远无法恢复的风险。

• 购票不代表同意接收营销信息。 购票者同意接收交易所需的内容：确认信息、实用信息及其变更。任何促销内容都需要单独记录主动同意，并且必须在收集地址时取得。
• 按地址而非按列表记录来源——记录使用了哪个表单、属于哪一届、勾选了哪个选项，以及时间。Q2 要求按来源记录，原因正在于此。来源记录为“我们觉得大多数人都同意了”的合并列表无法接受审计。
• 每封非交易类邮件都必须附有可用的退订方式，并立即处理退订，而不是等到下一次计划发送时。
• 提前告知收件人将收到第二封、品牌标识不同的自动邮件。 所引用的 devopsdays 邮件正是这样做的：提前一周告知参会者，之后会有另一个工具发送行为准则相关邮件。收件人不认识发件人名称，却突然收到邮件，会觉得像是钓鱼邮件并举报；这给发件域名造成的损失远超邮件本身的价值。
• 不同司法管辖区和不同列表适用的规则各异。 参会者列表的同意、保留和退订义务是实际的合规问题，不是风格偏好——请核查参会者所在地的现行规定，并在重用往届活动列表前取得批准。

失败模式

• 照搬 SaaS 滴灌邮件节奏。 将包含行为分支的 5 到 10 封邮件套用到固定日期的时间线上。这大约是所引用组织者常规发送量的三倍，而且需要活动不具备的工具支持。刻意采用精简的发送节奏。
• 因为场地还没坐满就超过所引用的发送上限。 注册曲线疲软，是营销计划需要诊断的问题，不是发送第五封提醒邮件的许可。对已经不理会你的列表发送更多邮件，只会让曲线疲软演变成列表报废。
• 行前须知遗漏行为准则或无障碍信息。 所引用的结构中包含这两项，而它们正是决定某人是否参加活动的关键信息。省略它们不是为了控制篇幅而作出的取舍。
• 将购票视为默认同意。 请参阅上文；这是唯一会造成不可逆后果的失败。
• 在此处处理未到场问题。 在提醒计划中加入超额预订比例、候补名单规则或押金规定。请用提醒邮件作答，然后转交给 samber/dev-event-organizer-skills@event-no-show-management。
• 为了让邮件效果更好而挪动日期。 公告、议程发布和早鸟截止日期都是固定的。想改日期的邮件，说明这封邮件的发送日期定错了。
• 编造现场信息。 签到地点、胸牌规定、安静室、饮食安排——这些都属于 samber/dev-event-organizer-skills@event-attendee-experience 的范围。提醒邮件中自信地写错签到时间，比不发提醒还糟糕。
• 编写发给演讲者或赞助商的会前一周邮件变体。 你负责区分角色；其他角色的内容不归你负责。
• 照搬冷邮件的主题行技巧。 使用两个小写词组成的主题，并隐藏发件人身份；而收件人此时正在收件箱中搜索活动名称。
• 未经处理就发送模型原始输出。 跳过润色环节的初稿一读便知；而在这个渠道中，组织者自己的语气就是产品。
• 完全不告知收件人会收到第二封自动邮件。 收件人会将其举报为钓鱼邮件，举报会影响你的发件域名。

衡量

将任何已发布的打开率或点击率数据都视为大致的合理性下限，而非目标。 你能找到的大多数数据都是营销行业的平均值，将无关的发件人和受众，与本技能涵盖的注册后邮件混在一起；把这类数据当作通过或未通过的门槛，正是把健康的邮件发送误判为失败的原因。最接近的可用数据是 21-30% 的打开率和 2.1-3% 的点击率；但它也早于 2021 年以来的衡量方式变化，而且把促销邮件与本技能实际撰写的确认、提醒和活动后邮件混为一谈；完全没有回复率数据。来源和完整注意事项：references/open-click-benchmark-evidence.md。拒绝任何基于这些数据设定的硬性目标，并说明原因；衡量此处真正只有通过或未通过两种结果的两项指标，再加上一些自行设定的信号。

发送前可检查的两项二元门槛：

• 行前须知完整性——来源中的 14 个部分结构，每个部分都必须存在，或明确注明不适用于本次活动。反复修改，直到符合要求；部分通过即为失败。
• 发送上限合规——任何细分受众收到的邮件数都不得超过来源规定的上限。按细分受众计数，而非按邮件列表计数。

自行设定的信号，只有跨届比较才有意义：

• 邮件已经解答的现场问题——签到时按问题计数。这是衡量行前须知是否有效的最省力、最诚实的方法，也是本技能自行设计的指标，并非来源中的内容。
• 迟到的饮食和无障碍需求——如果有人回复活动前邮件，提出需要提前两周告知的需求，说明邮件发得太晚，而不是参与者不够仔细。
• 每封邮件带来的退订和投诉——唯一可用的实际发送频率防护指标。无论日历如何安排，只要数量上升，就说明发送量超出了上限。
• 活动当天的到场时间与注明的签到时间段是否相符——如果人群在错误的时段到场，问题首先出在邮件，而不是签到台。

从自行设定的信号中选两项，写下每项会如何改变下一届活动的安排，并在活动前记录这两项。

调用示例

• “为我们有 300 人参加的会议撰写活动前一周发送的邮件——这是第一届，我们完全不知道该写什么。”
• “从现在到活动当天，我们应该发几封邮件？报名六周前开放，目前名额只报满了一半。”
• “撰写周五早鸟优惠截止前的最后提醒邮件。”
• “我们收集了去年活动的邮箱地址。可以给这份名单发送本次活动的邮件吗？”
• “我们的免费聚会有 40% 的人缺席。提醒邮件该怎么写？”

预期输出：一份注明日期的发送计划，每封邮件对应一项任务；说明所选发送频率如何符合来源中的上限；列出每封邮件的目标细分受众；为每封邮件撰写贴近人情的文案，包括完整的行前须知；针对每个邮箱地址来源进行同意检查；并明确将所有结构性问题转交给负责处理的同级工具。

参考资料

• references/arc-and-send-map.md - 推广周期中的每次发送：触发日期、唯一任务、必需内容、不得包含的内容、对应细分人群，以及未注册者的收尾处理。
• references/know-before-you-go-email.md - 按实际顺序排列并有来源依据的 14 个部分，其中哪些部分为条件性内容、针对规模较小活动的调整规则，以及衡量门槛使用的完整性清单。
• references/email-craft-and-worked-copy.md - 主题和预览文本规则、正文的五段式结构、移动端排版、人性化检查清单，以及最后召集邮件和活动前一天邮件的正反文案示例。
• references/open-click-benchmark-evidence.md - 找到的唯一一项具名组织者打开率／点击率基准、它为何不足以作为目标数字，以及经检查确认缺失的内容。
• samber/dev-event-organizer-skills@event-marketing-plan - 总纲。确定日历主线、邮件渠道的权重和所有固定日期；也是本技能所执行的同意规范的来源。
• samber/dev-event-organizer-skills@event-ticket-pricing - 负责确定早鸟票和价格档位的截止时间；最后召集邮件会对此作出响应，但不会设定这些时间。
• samber/dev-event-organizer-skills@event-attendee-experience - 所有活动前和活动当天邮件所述现场信息的事实依据。
• samber/dev-event-organizer-skills@event-no-show-management - 负责制定对缺席问题的结构性解决方案；本技能的提醒节奏是该模型的一个输入，而非替代方案。
• samber/dev-event-organizer-skills@event-feedback - 负责制定本技能最后一封邮件所附的活动后调查问卷。
• samber/dev-event-organizer-skills@event-code-of-conduct - 负责提供「活动须知」邮件中行为准则部分所链接的内容。