主题篇，既要被发现，也要被传播奖励篇，调动用户参与意愿的关键规则篇，让双方交换更容易达成宣传篇，不是通知用户，而是打动用户成本篇，控制活动成本的四个环节风险篇，正确认识风险，积极拥抱风险数据篇，必须了解的数据分析方法论执行篇，执行的关键在于公共人力资源复盘篇，团队加速成长的秘密
在外行人的眼中，做活动的成本是活动发放的那些奖励。
在旁观者的眼中，做活动的成本是奖励加开发活动的时间和精力。
在运营人的眼中，做活动的成本是从开始到结束所支付的所有脑力和体力。
任何活动始于策划环节，落实于后面的执行环节（开发、宣传、运营），为了自己最初运营目标不打折扣，要付出的太多太多，运营是发起方，其他是协作方，当遇见了问题，所有人会问你怎么办；当其他人遇见一些都不想做或者执行不到位的事，也得运营掏出人力资源来填补；当出现任何问题，都是运营收拾残局。
不管是做营收还是拉新，往往都是跟公司的年度计划，季度计划相关联的，继而拆解到月计划，周计划里。所有的策划环节都是围绕着一个周期内的目标而展开的。
除了配合其他部门做用户新进，余下运营部门每天思考的是，以现有的用户量，如何最大化去完成营收工作，在这一块，运营是完完全全的主导，其他部门为协同。
对于配合的部门而言，大部分时候看到的就是一个个具体的执行方案。而这一个个的执行方案背后，是负责人和团队一起关在会议里不断折磨、推翻、舍弃，最终形成的落地执行方案。在执行的过程中，又可能因为各种原因而不断调整迭代。
好的活动策划，从来都是从无数选择中挑选出最合适的一种。有追求的团队，大约每写5张纸才能留下1张有用的，每跟4个不同的部门的人员交换信息才能确认一套方案的可行性，每进行3个小时的会议讨论，才能确认活动的基础框架。而没追求的团队，支付的智力资源可以极其稀少，照搬竞品的节奏抄就好。
这个过程，就是运营负责人，带着团队用尽所有的智力和体力资源，绞尽脑汁去努力达成。
前面的章节写到【主题篇】，【奖励篇】，【规则篇】通通算作策划阶段要支付的智力资源。在那三篇文章里，要确认的问题实在太多。
我们假设自己设计出了很多好的方案，但也可能由于执行人员的能力不到位而夭折，被迫降级，责怪他人能力不到位没有任何意义，考虑好执行层面，各个阶段的成本，在策划阶段是重中之重的事情。
当然，随着工作经验的积累，团队的成长，对协同人员的能力判断，策划环节所支付的智力资源是可以不断减少的。
不同的活动支付的开发成本不一样，有些简单的，发布一篇活动案就完事了，比如冲级赛，登录游戏领礼包，论坛征文等。但是稍微麻烦一些的就需要开发了，比如预约和兑换礼包，转盘抽奖，报名、注册、竞猜等。这些活动都涉及到页面功能开发和数据库存储。当然，还有很多的活动直接做到游戏内置。
有些运营会模仿产品经理写需求文档，跟跨部门的美术、程序、测试进行沟通，有些则是直接拜托更为专业的同学进行。写出让开发团队看得懂的需求文档绝对是门专业活，写完了不算完事，还有后面的需求评审，交互设计，前后端开发，运维上线等等等等。
运营掌握开发知识是必须的，如果兴冲冲的设计一套玩法，开发说实现有难度有风险，然后我们就得被迫重新设计方案，无形中浪费时间成本。
会写文档，跟开发的沟通会高效，如果不会，则是边开发边补充完善规则，跨部门之间的协作成本往往大得超过想象。
有积累的团队，会把每次开发的功能模块尽量模板化，以形成复用性，对于开发团队而言，如果反复做某个东西（专业术语叫造轮子），等于是原地踏步，做苦力，开发意愿低下。
活动模板如同武器库，是各个团队的积累。以抽奖为例，世界上的随机活动跑不出那几种类型，一旦模板化，每次只需要更新设计图，配置表格即可。武器库里的东西越多，运营能做的套路就越多。
这一块的成本，随着技能的提升，活动模板的建设而不断减少。
宣传的重要性不再强调，这是直接影响活动参与人数，辐射范围的一个重要维度，这一块的工作也是有框架的，我前面的【宣传篇】章节里有详细介绍。
有些活动宣传层面的工作，比如营收类和活跃类活动，是由运营人独立完成，包含搭建宣传渠道，设计宣传文案，控制宣传节奏。
有些活动的宣传，运营无法独立完成，则需要其他部门协助完成。
物料、文案、广告图，是宣传内容生产层面的，主要由设计师输出。
内容投放渠道、曝光频率，营销资源预约是执行层面的，这类工作则是市场商务部门协同工作。
超大型活动的宣传，往往公司里会指派市场、商务、品牌、公关负责人配合运营团队进行，小活动则运营人员直接自己搞定。
在超大型活动和小活动之间，往往存在于一些中间地带，很多时候需要他人帮忙，此时则是考验安排能力和情商的阶段了。做不好安排，一旦出现混乱，反复折磨他人，情商再高也没用。有很多的需要他人帮忙的环节，人家本来可以准点下班，自己有本事让人家额外加班么？
此处预告后面更新的内容【执行篇】，如何有效的调动公共人力资源的工作积极性。
1、因为规则设计，支付的经营成本
比如征文，选美活动，评选名次的过程就会占据我们的精力。还有一些竞技类比赛类活动，分轮次进行的，每轮结束后，运营人员要做结果核对，写战报结果，公告晋级选手等。
一个貌似不起眼的问题：0点开始24点结束，12点开始次日12点结束，我们到底用哪种？
我的建议：奖励自动结算的随意，如果活动运营的过程中需要投入人力资源，那么建议设计成中午12点结束。同理，也不要设计成周五下班前18:00结束。
有些活动需要比较长的结算时间，需要数据的同事去提数据，然后陪着你验算结果，然后你再公布获奖名单结算奖励，如果你设计24点结束，那么他们要陪你加班到24点，然后一起忙碌到1点，其实人家心里在骂人，人家凭啥陪你加班？另一方面，我们又要照顾用户，第一时间公布名单，如果24点结束，你公布名单应该是在凌晨，如果这个时候结算出了问题，那么再做调整也是非常麻烦的事，没有谁愿意晚上出来陪你擦屁股。
同理，一些未曾做过，流程跑得不通畅的新活动，不要尝试在长假之前上线，如果不稳定，长假期间线上活动出了问题，整个协同配合的团队都过不好假期。（此处隐藏血泪教训3000字略过不表……）
2、因为结算方式，支付的发奖成本
游戏内由系统自动结算的奖励不在此列，游戏外的页面活动，有些活动奖励本身就是礼包CD-KEY的形式兑现，论坛活动你得发站内信吧，页面活动你得要手机号，然后请平台的同事通过短信完成CD-KEY发送。
有些活动都会搭载一些实物和现金奖励，实物奖励结算，在收集用户地址的过程中，你往往会收集到千奇百怪的地址，然后运营得一个个的去找用户核对（或请客服协助），不然无法完成邮寄.
现金奖励结算，绝对不是微信支付宝转账那么简单，公司一般走财务汇款劳务费流程，走内部流程逐级审批，需要收集到用户的银行卡，要求对方传真身份证复印件等麻烦事。
我原来做过的大型竞技比赛活动就发过100台ipadmini2，能拿到奖励的都是土豪用户，统计核对地址的过程就不说了，时值新品上市，采购100台的流程已经走完，有3个土豪用户们在CEO的微博下留言，说要指定颜色，希望自己加钱升内存（16G升32G），CEO为了满足土豪们逐一允诺，直接打断了原来已经走好的采购流程，从财务到供应商全部重新来，最终为了那3个用户，其他97个用户最终拿到实物的时间，距离预期整整晚了1个半月。
现在回头来看，这件事非常蠢（比如多为那些用户采购指定的3台嘛，但当时就是采购规则和政策条件不允许，这一块的操办人是财务部门，运营无法更改政策），我们有很多种方式规避或解决掉这个问题，但是在当时的实际情况中，各部门信息不同步，承诺就要做到，流程不可逆等原因，就导致了这种事情的发生，这一段是我的亲身经历，印象深刻又无可奈何。
所有的事情，在后面看来都是显得此前的行为非常蠢，但是当时发生的时候，确实是各种各样原因交织在一起导致的，我们只能当事后诸葛亮。
所有的维护成本，都取决于此前的策划，在设计活动的过程中，留足时间，这些也不算什么了，但最糟糕的是，由于意外引发的成本。
3、因为意外情况，引发的维护成本
尽管我们仔细检查，认真测试，但是活动难免会出意外，不管是自己主观造成的意外，还是因为其他原因引发的，都由此前的活动负责人来收尾。
不管你的活动规则写得多么好，总有一些用户提出疑问，这种情况是常态，超过一定面积的反馈，就得不断的补充迭代，解释说明。还有一些用户，规则放在那里根本不看，参与过程中遇见了问题就过来问我们，针对这类情况，要么运营充当客服回答问题，要么事先做一个FAQ培训客服同学，让他们协助答疑。这些事情，均消耗我们的时间和精力。
遇见了业务能力菜的开发人员，活动就容易BUG，只能是临时维护修订。有些并非BUG，比如访问迟缓，浏览器不兼容，分辨率问题，未做负载均衡，扛不住并发压力等等一系列的体验问题……
任何一个环节上没控制好，就会造成不可控的风险，最大的成本从来不是金钱成本，而是犯错赔进去的人力资源成本，以及为了弥补错误而浪费的时间机会成本。
意外之所以叫意外，就是自己不可预料的。这些可能出现的意外，想要规避，纯吃经验，我会专门在后面的【风险篇】里详细介绍。
上述内容都与活动中的各项成本有关，旨在帮助大家建立一种成本上的意识形态。文末，谈谈组织运转中的提升效率，降低成本的方法论。
我们每天的时间被各种事情拆分，落实到日常工作中，是会议室里头脑风暴，工位上的文档撰写，各种场合下的沟通协作执行……
几乎每个管理者都在强调高效，如果嘴巴上勤奋，实际工作偷懒，那就只是管理者的一厢情愿。每个人都有追求高效的主观意愿，问题是如何做呢？一味的强调指导思想，对于实际业务操作没有任何帮助。
每个工作到一定年份的从业者，心中一定要有2个框架，一个是效能框架，一个是业务框架。
效能框架指的是，每次做事情的时候，调用/消耗了公司多少资源？花费了多长时间？最终取得什么样的质量结果？心中总是得有点数的。
放在活动场景中，质量（活动KPI）摆在那里，降低成本的唯一方式，就是提升效率，即用更少的人力资源，更短的时间交付更好的结果，每个管理者强调高效应当从这三个角度出发。
每个部门又有其负责的各业务模块；每个业务模块又能（像本文一样）被拆解成各种环节；每个环节又可以再次被拆解成各种执行细节。这种拆分的过程，就是搭建业务框架的过程。
为此在编写部门手册的时候，不光光是要告诉大家怎么做，还要提供过往的经验心得，易错点和解决方案（绝大多数人没意愿，没能力完成），这是一个困难事，但是做成了会很有成就，这也是一个管理者成为甩手掌柜的必要条件，同时也是自己的核心竞争力。
效能框架和业务框架互为因果，互相迭代，经验浅的人没有业务框架，但做事的时候可以用效能框架思考问题，经过工作经验的积累，慢慢就能够打造出业务框架了。心中有业务框架的人，再经过效能框架的反复验证，做什么都是信心十足。
业务框架越精细，越能够让业务高效运转。业务框架越精细，越能够衡量出实现目标需要多少资源。业务框架越精细，我们才能够看出自己、部门运转是否高效。
回到文本的主题——成本，极尽可能地精细化业务框架，是追求高效，降低成本的唯一解法。
