一、活动运营后的数据分析（内推、红包转发、专场活动）
gzcb218活动的前车之鉴就是和运营报备一下+对流程考虑更周全
还好，现在的2月18号的那个现场招聘会的活动进行了复盘，嗯，那其实的话呢我看了一圈他们的一个事前的准备呢，也是不得不说，各方面都要做到的，比方说一些宣传的物料，嗯展板，然后通知通知的话是发给每个候选人，那么候选人的话呢他们收到的通知的一个内容也比较详细，包括时间，地点，然后一个路线指引，都会有，嗯，然之后呢，还画了一个现场的一个流程图，啊，或者说是一个讲座，一个，平面图晚上大概哪个区做些什么活动才会有列出来？那至于为什么会在系统使用中会遇到一个不顺畅呢？其实我觉得。一个是现场的网络环境，网络的流畅度，决定了系统的快慢。那再来那就是，我们系统的这个运维，有没有保障，就说不会突然系统登录不上，最后就是，会不会有些突发的我们事前没有预料到的，叫做额外因素，你包括，我们当时预估的，是接受了邀请函的人会占大头，没收到通知来的人只占小头，但是现场您反映的却是反过来的。我觉得这个如果没做过现场招聘会的顾问，他不知道，没问题。但如果说有经验的人不知道现场招聘会有大量的这种，嗯，跟单位没有邀约关系的候选人会在各个摊位上流动，那是不能够原谅的。
所以从我们自身的角度去总结这个项目或者这个活动其实是不够到位的。刚才说到的三个因素，没有一个是我们这边可以给到一个专业建议的我们不知道现场的网络环境是否足够我们也没有跟我们也没有跟运维去报备这个事情，导致突发的系统无法使用的情况发生，还有最后我们没有预料到，有大量的没有事前邀约的候选人参与进来，导致我们预先设计的功能使用不了。
好问题来了那么我们原先设计的功能是什么呢？对候选人要提前进行一个面试要约，你要约的信函那里都要带一个二维码，然后到了现场就扫二维码就完成签到。这里要有一个前提条件：候选人必定是事先要邀约，即发面试邀请函。无论是提前扫个人二维码，还是现场的即时扫码，终归识别的前提是这些人在系统且已邀约过（没邀约的叫啥子“签到”呢？叫白撞）。一旦违背这个前提条件，例如：
1、现场突然多了很多系统中有但是没有给他做邀约的候选人，肯定没办法签到的，怎么办？只能给这些候选人做快速面试评价了。
2、现场多了这些候选人，要命的是系统里面根本找不到他的简历，他有一份纸质版，那怎么办呢？我去那样大家都不可能说就用简历云这种黑科技啊，因为大家都不是很熟悉嘛、然后现场现场比较混乱人比较多，肯定不可能说每个人都给引导使用这个全新的技术，那怎么办呢？嗯，其实有一个。在微官网导入51job或智联的简历。但是现场的这种不确定性的混乱性事件很多，我本来可以在前几天分散时间点去做的活动统一集中在同一时点去爆发，这种情况下，会对系统响应支持速度会有比平时几倍甚至十几倍的压力。
二、需求产品化的合理性探讨
包括新老项目。
三、每个项目运行情况分析及预警机制建立（数据分析）
1、项目成果总结报告
这里指的是，我们要对这个客户，有足够的把握。包括他的行业特点，它的规模大小业务流程还有营收多少这些都要我们作出分析判断有些可以问销售的同事但有些可能我们通过自己去查阅相关资料获取。
2、商业价值洞悉（由历史预测未来）
3、流失率分析
四、成功案例汇编
To B 业务的一大特点，就是客户会参考成功案例来评估某个产品是否符合自己的业务需求。丰富的案例，容易帮助客户树立对产品的信心，快速决策。因此运营日常要收集各种案例，按行业划分，汇集成册，供客户查阅。
巧妇难为无米之炊。参与感，及时获知项目状态。
S总试验田、资源稀缺的、必定需要精兵强将（特种兵），我和QL，招聘基础上还懂测评（我还做过HR和实施顾问，对底层技术数据库和代码中间件还是有理论基础）
真心希望领导能用好M
M成为您忠诚的拥护者
把申请正式邮件形式发出来单独给您
