成本篇：控制活动成本的四个环节

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