mcpField
E
event-social-media

event-social-media

github.com/samber营销与增长45.7k 次安装2 天前更新
代码仓库

关于 event-social-media

event-social-media 是用于技术活动预热和现场报道的社交媒体管理技能。它将既定营销计划和活动定位转化为平台选择、发帖安排、扩散请求及现场报道方案。

主要功能

  1. 01根据受众选择平台
  2. 02规划各营销阶段的帖子
  3. 03按用途选择标签
  4. 04准备扩散请求和分享素材包
  5. 05制定现场报道与照片规则

适用场景

  1. 01安排会议宣传活动的社交帖子
  2. 02协调合作方与组织者扩散信息
  3. 03依据照片授权规划活动日发帖

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/samber/dev-event-organizer-skills --skill event-social-media

安装后在 Claude Code 中输入/event-social-media确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

evals/
evals.json
references/
phase-post-plan-and-amplification-kit.md
platform-fit-and-hashtags.md

详细介绍

活动社交媒体

你负责技术活动获客宣传活动的社交渠道:活动会在哪些平台发布、每个话题标签承担什么用途、宣传活动各阶段发布什么内容、还会邀请谁帮忙扩大传播,以及活动当天会做什么。

有三件事已经确定。不要重新推导,也不要质疑:

  • 权重、阶段和日期——samber/dev-event-organizer-skills@event-marketing-plan 负责确定渠道组合、宣传日程主线和各阶段目标。它会交给你一个权重、一组日期和一个目标。你的工作从这里开始。
  • 信息——samber/dev-event-organizer-skills@event-positioning 提供活动承诺、受众定义和反定位句(“有很多 [archetype] 活动,但这不是其中之一。”)。社交文案要传达这句话;绝不另辟新角度或点名竞争对手。
  • 语气——samber/dev-event-organizer-skills@event-cultural-identity 会把社交媒体视为语气调整矩阵中的一个触点栏目,与主持人串词、标识和周边商品并列。根据该矩阵确定语域。单独创造一种社交媒体语气,是这项技能旨在防范的最常见身份认同失误。

总计划有意将自有社交媒体渠道的权重设得很低,这并非疏漏,无需纠正。 营销计划对渠道价值的排序中,自有社交媒体低于邮件列表、本地互动和合作伙伴渠道。DevOpsDays 自身的组织指南指出:“随着技术社区从 Twitter 分散出去,许多社区活动都很难触达受众”。

你的工作是做好这个权重较低的基线,而不是重新争论其权重。如果访谈发现受众确实以社交媒体为主,就如实说明,并将权重调整交回营销计划,而不是在这里自行决定。

在任何合作开始时,都要明确说出一个边界:活动结束后将演讲录音制作成短片、帖子串和文章,是 samber/dev-event-organizer-skills@event-content-repurposing 的工作,不是你的。你负责活动前和活动期间的发布。活动后的内容归档挖掘流程就在你的职责边界上,也是最容易无意间被纳入范围的工作。

访谈

一次只问一个问题,尽可能采用选择题。之所以有问题 5–7,是因为下面的菜单在见效时间、持久性和工作量上差异很大——如果不问这些问题,就无法替用户确定默认排序。

  1. 营销计划对社交媒体推广作了哪些安排:它在整体组合中的权重、确定的日期、各阶段目标?如果没有相关安排,请先停止并转到 samber/dev-event-organizer-skills@event-marketing-plan——没有活动营销主线支撑的内容日历,根本无从实现目标。
  2. 这场活动是否有意不做推广?有些活动会这样做,这是一种切实可行的策略,并非遗漏(见下文的退出推广选项)。
  3. 这个受众实际上聚集在哪里——请说出具体平台,而不是默认会想到的平台。分散的企业基础设施社群、集中在单一校园的学生群体和设计社群,几乎不会使用同一类平台。
  4. 活动现有的资源有哪些:账号及其实际触达范围、往届活动的照片存档、现有的官方话题标签、去中心化品牌的共享标签?哪些组织者会用个人账号发帖?他们的触达范围与活动自己的页面相比如何?
  5. 活动开始日期是什么时候,之前还有多少准备时间?准备时间短时,应优先选择借助他人现有受众的方式,而不是需要从零培养受众的方式。
  6. 是只为本届活动推广一次,还是希望账号能在多届活动之间持续积累?请坦诚告知用户:除非活动持续举办,否则活动账号在每一届开始时几乎都得从零起步,这就是为什么创作者经济中关于粉丝增长的建议并不适用。一次性推广应降低那些回报要到下一届才显现的做法的优先级——例如另开一个针对平台原生形式优化的账号、通过直播建立内容存档;如果目标是持续积累,则应提高这两项的优先级。
  7. 实际负责撰写和发布的人是谁,每周能投入多少小时——同一个人当天还要负责活动运行吗?与其他任何问题相比,这个答案更能决定是否采用现场报道这一层级。
  8. 活动属于哪种治理类型:社群主办、基金会主办,还是公司/供应商主办?这将决定中立政策是否会限制账号可以分享的内容。
  9. 胸牌上标注了什么照片拍摄退出选项?演讲者协议对录制和引用有何规定?应在规划任何现场报道之前收集这些信息,而不是等到活动当天早上。
  10. 任何赞助协议是否要求提供现场报道?是否有现场帖子需要服务的远程受众?
  11. 赞助商入驻流程是否已经会收集社交媒体账号,方便致谢?

社群主办、基金会主办、供应商主办

真正会改变此技能输出的关键因素是活动由谁主办,因为这决定了账号可以发布什么:

  • 社群主办——没有需要遵守的中立政策,也没有品牌审核;谁掌握密码,谁就可以发帖。限制因素是志愿者的时间,而不是权限。

  • 基金会主办——很可能有书面的中立政策,而且限制严格。CNCF 自己的指南:

    • 仅允许发布“供应商中立、由社群提供”的内容。
    • 禁止分享任何宣传供应商产品或指向公司网站的内容。
    • 以明确的转发许可名单取代逐案判断。

    这套规则旨在维护基金会的中立性,不能直接套用到其他类型的活动:供应商主办的活动没有类似理由回避推广自己的产品,小型社群活动也根本没有需要执行的赞助商中立政策。仅在这一类型下采用这套规则。

  • 公司/供应商主办——通常会有品牌审核、负责账号的营销人员,以及另外两种主办方无法触及的付费推广渠道。社群和基金会方面的指南并未涉及这一类型,因此应将从中借鉴的任何规则视为未经验证。

例外情况:有些活动不应安排内容日历

Strange Loop 发布的指导原则开篇就写着 “不做营销”(thestrangeloop.com/about)——这是一个长期举办、名额远超需求的社区主导型会议,并刻意不做主动推广,以此作为自身身份的一部分。这是真实的反例,而非执行上的疏漏。

制定内容日历前,请先检查以下三个条件。如果都符合,建议仅保留最低限度的信息:发布一则公告,说明实用信息,不再添加其他内容;并明确指出,这一选择符合活动的身份定位,并非有所欠缺:

  • 定位建立在稀缺性、策展或口碑之上(samber/dev-event-organizer-skills@event-positioning 的类别策略会体现这一点)。
  • 即使不做推广,需求也已超过容量上限,或往届活动仅凭公告就售罄。
  • 组织者认为推广有悖品牌调性,且活动的文化身份也支持这种做法。

选择不做营销的活动仍需发布实用信息——日期、地点、链接、CFP 截止时间、入场时间——因为已经在寻找活动的人需要找到这些信息。“不做营销”不等于“不提供信息”。

工作流

  1. 进行访谈。先根据 Q1 确定权重、日期和目标,再做其他事情。
  2. 测试退出条件(结合定位解读回答 Q2)。如果符合条件,就发布最精简的动态,然后到此为止。
  3. 重述 samber/dev-event-organizer-skills@event-positioning 中的信息和反定位语句,并阅读 samber/dev-event-organizer-skills@event-cultural-identity 中语气矩阵的社交媒体栏。以下每篇帖子都要遵循这两项。
  4. 根据广度菜单选择平台组合。平台名称在全文中仅作示例——组合每隔几年就会变化,而且 Q3 中关于受众的回答优先于任何列表。
  5. 根据目的而非习惯决定话题标签。完整分类,以及社群信号对比,参见:references/platform-fit-and-hashtags.md。
  6. 根据计划的各阶段安排帖子——公告、征集演讲提案开放与截止、演讲者介绍、议程发布、早鸟优惠截止、最后冲刺、活动进行中、活动总结。各阶段的帖子类型、示例日历及其反面案例,参见:references/phase-post-plan-and-amplification-kit.md。
    • 批量撰写。组织者表示,他们会在一次集中工作中撰写并安排约一个月的帖子,借助排期工具或自动化工具。这很适合志愿者的时间安排:一次完成,而非每天都要做。每篇批量准备的帖子都要关联到真实的宣传日期;计划日期一旦变动,就重新检查整批帖子——排期帖子宣布已变更的日期,还不如不发。
  7. 根据姿态菜单设计传播请求,并一次性制作可分享资料包,而不是每次有人提出请求时都制作。
  8. 选择现场报道级别,然后将指定志愿者和照片规则写入活动流程表——不要只写进当天没人会打开的文档。将运营时段交给 samber/dev-event-organizer-skills@event-run-of-show。
  9. 将录制内容、照片存档和可引用的精彩片段交给 samber/dev-event-organizer-skills@event-content-repurposing。说明你移交了什么;不要开始剪辑片段。
  10. 将各平台带跟踪信息的链接交回营销计划,用于衡量引荐信号。衡量层属于计划,而非你的工作——你提供链接,由它来读取数据。

如果你的运行环境支持持久记忆,请记录平台组合及其依据的受众回答、话题标签的决定及其目的、向哪些人提出了哪些请求,以及实际发布了什么、获得了什么反响。下一届活动就能从真实存档和实际参与传播的人员名单开始,而不是面对一张空白日历。

以下所有排序都是默认方案,不是铁律——它们会随情境和执行者而变化。根据你已知的组织者情况,重新评估这三份菜单的排序:拥有大量个人关注者的组织者、以剪辑视频为职业的志愿者、使用共享社群标签的去中心化品牌、禁止拍照的行为准则、受众集中在一所校园。每种情况都会推翻某个默认级别,下面的每份菜单都会指出是哪一个。

平台覆盖广度

按投入排序:每单位组织者精力所带来的触达。以下排序基于判断,并非测量结果。

  • 投入(撰写、调整、账号维护):全面布局 > 两个平台原生适配 > 主平台加镜像平台 > 单一主平台
  • 价值(判断可触达的非既有受众人数):两个平台原生适配 > 全面布局 > 主平台加镜像平台 > 单一主平台
  • 效率:主平台加镜像平台 > 两个平台原生适配 > 单一主平台 > 全面布局

有意将运营良好的双平台布局排在全面布局之上。新增平台触达的受众往往与现有受众高度重叠,而且在志愿者精力有限的情况下,新增平台会变成一眼就能看出无人维护的账号——一个最后一篇帖子是四个月前的账号,只会削弱活动的可信度,而不是扩大触达。

  • 单一主平台——一个账号,选在 Q3 中受众实际所在的平台。其他所有平台只需在营销计划本就会搭建的沟通枢纽上放置链接。

  • 主平台加镜像平台——将相同帖子同步发布到第二个平台,并做少量调整。成本低,因为无需重写。

  • 两个平台原生适配——针对各个平台的格式和受众重写每篇帖子。重写本身很快;耗时之处在于逐个平台检查版本是否符合其表达风格,并确保两个账号都有人回复。

  • 全面布局——维护四个或更多账号。MLH 的校园规模策略列出六个平台以及社区群组:这是一份适用于受众确实分散在这些平台上的完整清单。

  • **默认档位:**主平台加镜像平台。

  • **升级条件:**当 Q3 指出有两个平台分别聚集着不同受众,且他们有不同的参会理由时,升级为两个平台原生适配——例如,一个专业社交平台触达负责批准差旅预算的管理者,另一个社区平台触达真正想听演讲的从业者。若只是同一类受众的两种表达方式,做适配毫无价值。

最不受青睐的选项是全面布局——价值排第二,投入排第一,因此效率排序永远不会选它。在两种情况下应升级到此选项:一是由公司主办的活动,维护账号本来就是某人的职责;二是校园规模的黑客马拉松,其受众确实遍布 MLH 所列的平台,且任何单一主平台都无法触达其中一半受众。

当 Q3 只指定一个平台时,应删除其他档位,而不是将它们降级。为了“以防万一”创建第二个账号后又弃之不顾,还不如从未开设;而在菜单底部闲置的档位,会在第三周重新变成项目范围。

扩大传播请求的策略

按投入排序:每单位协调精力所借助的传播力。此排序基于判断。

  • 投入(协调、他人的日程安排、逐项制作):协调合作伙伴集中推广 > 请每位演讲者帮忙推广 > 赞助方致谢 == 现成素材包

  • 价值(通过发帖者已获信任的受众扩大触达,基于判断):请每位演讲者帮忙推广 > 协调合作伙伴集中推广 > 现成素材包 > 赞助方致谢

  • 效率:请每位演讲者帮忙推广 > 现成素材包 > 赞助方致谢 > 协调合作伙伴集中推广

  • 合规成本(触发审核、消耗可撤回空间):赞助方致谢 == 协调合作伙伴集中推广 > 请每位演讲者帮忙推广;现成素材包不产生此类成本。

  • 工作量并列(赞助方致谢 == 现成套件):两者都是一次性的内容制作,不受他人日程安排影响。套件只需制作一次;向每位赞助方致谢只需几分钟,而且其社交媒体账号已在入驻清单中。

  • 合规成本并列(赞助方致谢 == 协调合作伙伴推广):两者都受已签署的协议约束,协议中的品牌使用和交付条款决定了可以发布什么内容。两者都需要在发布前向负责该协议的内部团队确认——公开发布后就无法撤回。

  • **单个演讲者的请求所处位置:**低于上述两个并列选项,高于套件(零成本),因为这确实需要一项许可——演讲者同意被点名并展示照片。演讲者协议通常已授予这项许可,而且请求中还明确说明可以选择退出。

  • 现成套件 - 演讲者卡片、文案区块、主题标签、链接、图片尺寸。制作一次,供其他每项请求使用。为发给演讲者、评委和教练的模板添加个人折扣码栏位,让他们发布的内容包含该折扣码——这样一来,“请分享这条内容”也能为他们自己的社交圈带来价值,与不含此类激励的普通赞助方模板有所区别。

  • 单个演讲者的请求 - 确认时,将演讲者卡片发给演讲者,并附上一句话,请他们发布卡片并告知活动官方帖文的发布时间。这可以随一封本来就要发送的邮件一起发出,因此成本很低。规模扩大后,应分散发送工作,而不是让所有套件都经由一位社交媒体负责人处理:在内部负责某位演讲者、赞助方或教练关系的人,直接把对应的套件交给对方。这样,推广覆盖范围就能随内部关系负责人的数量扩大,而不是卡在某一个人的待办队列里。

  • 赞助方致谢 - DevOpsDays 的组织指南在收集徽标和发票信息时,也会询问“一个可用于致谢的 Twitter 账号(完全自愿)”。关键就在于它对此事的定位:表达善意,而不是要求交付内容。请按这种方式介绍。

  • 协调合作伙伴推广 - 合作伙伴社群、媒体合作伙伴和大使计划在指定时间发布内容。合作协议本身归 samber/dev-event-organizer-skills@event-media-partnerships 和 samber/dev-event-organizer-skills@cross-event-promotion 负责;你只需提供日期和素材。

  • **默认层级:**现成套件加上单个演讲者的请求。

  • **升级条件,以 Q11 为依据:**赞助方入驻流程开始收集社交媒体账号时,就添加赞助方致谢——只需几分钟。只有在营销计划已为该阶段规划合作伙伴渠道的权重,并且合作协议已签署后,才添加协调合作伙伴推广。

最缺乏支持的选项是协调合作伙伴推广 - 价值排名第二,工作量排名第一。若合作协议已签署(此时新增工作仅为协调日期,无需谈判),以及首届活动尚无自有受众、借助他人受众是唯一可行选择时,应优先考虑此选项。

**组织者的个人账号——菜单之外的一点说明,信心较低。**组织者表示,各章节和各活动的社交媒体页面触达人数少于组织者自己的个人账号。这与 Q6 中提到的近似冷启动问题相符:个人账号的影响力会随每届活动累积,而活动页面每个周期都要重新开始。这不是一个层级选项,因为它并非向第三方提出请求——而是团队使用自己的账号发布内容。请按以下方式使用:

  • 询问每位组织者是否愿意通过个人账号转发或发布帖子,并记录同意的人。切勿擅自假定;个人账号属于个人,而非活动。
  • 给组织者提供与演讲者相同的现成素材包,确保他们的帖子包含定位句和可追踪链接,而不是临时发挥。
  • 为每位组织者的个人账号设置专属的可追踪链接,以便在本期的数据中将相关说法与活动页面进行核验。
  • 无论如何,都要保留活动页面作为实用信息的权威来源。个人账号负责扩大传播,而非取代信息源。

对于多分会网络,这会削弱为每个分会单独创建页面的理由。创建页面前,先确认是否有指定人员负责发布,以遵循上述平台广度删除规则。

如果活动没有赞助商,就删除赞助商这一层级,不要把它作为目标留在选项菜单中。如果不存在合作关系,且本周期也不会推动合作,合作伙伴推广同样如此。

关于先发布_再询问_:检查赞助协议是否已约定在社交媒体上提及赞助商。如果有,这条帖子就是由 samber/dev-event-organizer-skills@event-sponsor-fulfillment 负责的履约事项;漏发属于违约,而非错失礼貌之举。

现场报道深度

分级菜单——在大家都已忙得不可开交的日子里,衡量每单位精力能换来多少证据和现场传播效果。

  • 精力投入(人员、注意力、当天的工作能力):full live desk > roving poster > scheduled skeleton > single recap
  • 价值(传播范围,以及下一届活动和下一年度赞助商需要的归档内容,综合判断):full live desk > roving poster > single recap > scheduled skeleton
  • 效率:single recap > roving poster > full live desk > scheduled skeleton
  • 合规成本(获取同意、牺牲可撤回性):full live desk > roving poster == single recap;scheduled skeleton 则没有合规成本。

合规成本并列这一点值得讨论:roving poster 和 recap 都会发布可识别参会者身份的照片,因此都需要事先建立相同的同意机制——由 samber/dev-event-organizer-skills@event-accessibility-inclusion 负责、通过胸牌携带的照片拍摄退出机制。两者的区别在于发布数量,而非所需的许可。full live desk 还会实时引用演讲者的话,而且通常会进行直播;这需要录制同意,而演讲者协议可能已经授予,也可能没有。

scheduled skeleton 虽然成本很低,效率排名却垫底,这是有意为之:预先写好的“会场已开放”帖子不会留下任何成果,传播范围也主要限于已经身处现场的人。它的精力花在营造活跃假象上,而不是创造可重复利用的内容。

  • Single recap——闭门后发布一条帖子,配上当天的真实照片和感谢语。只需半小时,就能产出下一届活动可复用的内容。刻意精简的活动后传播计划到此为止,另加一段较长的 recap 视频,发布到归档渠道中;不要把它扩展成冗长的多周 recap 宣传活动,否则团队难以同时承担下一届活动的工作。

  • Scheduled skeleton——预先撰写并安排发布三到五条帖子。即使当天无人分心关注,也能可靠发布,这就是它唯一的优点。

  • Roving poster——指定一名志愿者全天发布照片和引语。由此产生的归档内容可用于撰写赞助商报告、宣传下一届活动,以及支持 samber/dev-event-organizer-skills@event-content-repurposing。

  • Full live desk——由数人负责,逐场发布帖子、维护实时动态串、管理照片流程并即时回复。

  • 默认级别: single recap。

  • **升级条件:**只要有志愿者能被_明确列入活动流程表_,就升级到 roving poster;不能指望当天早上才找到人。没有明确指定负责人的实时发帖任务,往往会悄无声息地落空。

最容易被忽视的选项是 full live desk——价值排名第一,精力投入也排名第一,因此效率排序永远不会选它。升级条件,与 Q10 对应:赞助协议明确约定了实时报道,或者活动有远程观众,而实时帖子_就是他们参与活动的方式_。

对于行为准则或文化身份对摄影有所限制的活动——例如严格的摄影政策、不公开传播的惯例,或大多数参会者都会使用的胸牌退出机制——直接删除基于照片的级别,而不是把它们降级。规划纯文字报道或不作报道,并说明原因,避免有人在活动当天悄悄重新拿起相机。

失败模式

  • 反驳总计划中的渠道权重。 社交媒体计划一上来就主张社交媒体应当占主导,与 samber/dev-event-organizer-skills@event-marketing-plan 已经作出的决定相矛盾,还会把精力浪费在计划已解决的问题上。把折扣后的基线方案执行好;如果确实需要重新分配权重,就把理由反馈给计划。
  • 照搬创作者经济的基准。 “在专业社交平台上每周发 3-5 次,在微博客上每天发 3-10 次”是持续经营个人品牌的节奏,适用于粉丝数经过多年积累的账号。活动营销周期短、有明确日期和检查点,每届活动开始时关注者都接近于零;两者的差异是结构性的,不是语气上的差异。
  • 把社区标签当作活动标签。 DevOpsDays 建议潜在组织者发帖时“(使用 #devopsdays 标签。)”——这是长期使用的社区身份标签,方便分散各处的社区成员彼此找到对方,而不是用于衡量单届活动的标签。只使用社区标签、没有自己的活动标签,就会完全失去衡量效果的作用。
  • 在帖子中重新定义定位。 为配文临时编造的新角度,会造成第二种相互竞争的活动叙事。沿用定位句;不要改进它。
  • 越俎代庖,做了活动内容再利用的工作。 活动结束后剪辑演讲片段、撰写回顾文章、制定常青内容分发计划,都属于 samber/dev-event-organizer-skills@event-content-repurposing。移交存档,然后到此为止。
  • 把赞助商致谢说成必做事项。 其原始资料称这“非常可选”。如果把它当作义务,就会把善意之举变成没有经费支持的交付任务——如果协议确实约定了鸣谢,那属于履约事项,不在此列。
  • 把基金会的中立政策照搬到社区活动或厂商活动中。 CNCF 的规则旨在维护基金会中立性:
    • 用于小型社区活动时,这些规则会毫无理由地禁止一些完全正常的帖子。
    • 用于厂商主办的活动时,这些规则会禁止活动本身的宗旨。
  • 让同一个人既负责实时发帖,又负责活动当天的现场工作。 值班组织者无法同时处理场地问题并跟进主题演讲。指定其他人,或降至活动回顾这一档。
  • 为了显得精确而编造发布频次。 应当以确实存在的活动日期为锚点安排帖子——日期有据可依,频次则没有。

衡量

此技能不设定任何数值及格线,这是有意为之。像“4% 互动率”这样的目标,是从不相关的领域生搬硬套来的虚假精确;读者会围绕一个在这里毫无意义的数字进行优化。评估渠道时,应看已排期的帖子是否按时发布、跟踪链接是否带来了流量,而不是看比例。

有一项真实的活动账号数据值得准确说明,以免被误认为目标:一项 2025 年的学术研究调查了 X 上 22 个具名的计算机科学会议账号(arXiv:2503.01038),测得每条帖子的点赞数中位数为 9、转发数中位数为 3,粉丝数从 206 到 74,115 不等,且粉丝数与点赞数高度相关(Pearson 0.95)。这些账号是成熟的会议品牌,粉丝是在最多 14 届的持续举办中积累起来的——受众不断增长,并非每届都从近乎零起步的活动——因此,这些数据描述的是该受众,而不是可照搬到这里的及格线。

  • 计划中的每条定期发布的帖子都按计划日期发布(自行设定,二元指标):这是唯一完全在你掌控范围内的衡量标准,也是志愿者团队最常无法达成的一项。
  • 各平台的跟踪链接(自行设定):每个平台使用一个独立链接,并在发布前确定,因为事后无法补加。营销计划负责查看这些链接的数据;你负责创建链接。
  • 个人账号与活动主页(自行设定):针对同一条帖子,比较各组织者个人账号链接与活动主页链接的点击量。这是在你自己的受众中测试个人账号是否比分会主页触达更多人的唯一方法。
  • 扩散参与度(自行设定):实际发布内容的演讲者和合作伙伴人数,占受邀人数的比例。比例低说明邀请方式有问题,而非受众有问题——通常是因为邀请时没有附上可直接使用的素材。
  • 制作的内容档案(自行设定,也是能惠及下一届的指标):可供 samber/dev-event-organizer-skills@event-content-repurposing 和下一届宣传使用的照片、引言和录音。活动当天如果无人记录,就不会有可供来年宣传的内容。

调用示例

  • “距离我们的 300 人基础设施大会还有四个月。我们应该发布什么内容,又该发到哪些平台?”
  • “我们的首批演讲者刚刚确认,如何宣布他们并邀请他们分享消息?”
  • “我们的黑客马拉松应该上 TikTok 吗?还是说这对学生受众来说是浪费时间?”
  • “活动当天应该发布什么?那天没人能抽出人手来做这件事。”
  • “我们的大会一直靠口碑宣传,组织者也讨厌营销。我们真的需要社交媒体计划吗?”

预期输出,每项经过评估或自行设定的内容都应标注其性质:

  • 平台选择,以及据以决定的受众分析。
  • 话题标签的选择,以及每个标签的用途。
  • 与阶段对应、并锚定营销计划实际日期的发帖计划。
  • 扩散邀请方案,包括何时邀请谁,以及他们会收到哪些素材。
  • 现场报道安排,包括指定人员和照片规则。
  • 移交给 samber/dev-event-organizer-skills@event-content-repurposing 的清单。

参考资料

另请参阅同一集合中的:

  • samber/dev-event-organizer-skills@event-marketing-plan - 总体规划:负责确定本技能所执行的渠道权重、活动宣传主线、预算和各阶段目标。
  • samber/dev-event-organizer-skills@event-positioning - 提供每条帖子都会传达的信息和「对比而非攻击」的句式。
  • samber/dev-event-organizer-skills@event-cultural-identity - 提供语体;社交媒体是其语气调整矩阵中的一个接触点栏目。
  • samber/dev-event-organizer-skills@event-run-of-show - 规定当天现场发帖的时段及负责的志愿者。
  • samber/dev-event-organizer-skills@event-content-repurposing - 活动结束后接手录制内容和照片档案;负责短片、文章和常青内容的分发。
  • samber/dev-event-organizer-skills@event-accessibility-inclusion - 负责徽章上标注的照片和录制退出选项,每个级别的现场报道都依赖于此。

评论

支持 Markdown