1. 背景描述
1）公司响应新网约车运营政策，清退了大量不合规车辆，以及为保障用户深夜出行的安全问题，推出深夜跑车卡等措施，导致合资公司整体运力降低。
2）公司希望通过春节司机返乡期间，通过激励措施，推荐一批优秀司机补充运力不足问题。
3）电销系统反馈在司机转化漏斗的分析过程中，线索不足是影响司机转化的显著原因。
2. 核心目标
通过为电销系统增加司机线索从而提升司机转化数量，以达到提升公司运力的目标。
3. 解决方法
建立车主多级推荐拉新工具，通过分级激励措施，收集司机线索，打通电销和BD系统，为其提供充足的线索，通过电销和BD人员线下跟进线索，促成转化。
4.推荐拉新系统详细介绍
4.1 车主推荐系统后台及C端模块关系图
4.2 车主推荐系统后台详细介绍
1） 车主推荐活动列表。
--展示举办公司、城市、活动ID、活动名称、开始时间、结束时间、预算当前已达奖励金额、状态、操作栏等字段
--操作栏支持上/下架活动。
2） 推荐活动配置。
--活动的基本信息，公司、城市、名称、时间、预算等。
--超预算提醒。根据生成的推荐明细列表计算当前的活动奖励金额，每日计算，活动奖励超过活动预算后短信通知，意义：增加风控，必要情况下可下架活动。
--奖励规则。包括被推荐人、一级车主推荐人以及二级车主推荐人的达标条件和奖励金额。
3） 推荐活动详情页。
--包括活动详情、以及操作日志。
--通过操作日志中包括操作类型、操作内容、以及操作人、操作时间的记录。记录业务人员从创建到编辑的每次修改过程，实现操作可追踪性。
4） 推荐明细。
--在活动维度下，梳理被推荐人状态与其本人和推荐人以及推荐人上级的达标状态、达标时间以及奖励金额之间的关系。既是风险控制的手段，方便业务对活动的进行情况以及奖励配置的合理性做实时的评估，也是业务发放奖励的必要报表。
--支持查看、导出列表和标注发放情况。
5） 商城（二期规划）。
6） 推荐人列表（二期规划）。
--在推荐人维度下建立表单，可识别优质推荐人，方便进行跟踪培养。
7） 星级规则配置（二期规划）。
--根据与推荐人本人在内的四级推荐关系内成功推荐的司机总人数，构建星级规则。
--推荐人获得的奖励为基本奖励*星级系数，星级越高奖励系数越高。
4.3 车主推荐系统C端H5界面详细介绍
1）推荐系统H5主流程图
2）推荐系统H5功能模块图
5. 项目设计过程中的反思
5.1 活动和星级的关系
介绍一下项目背景
我们对接的业务方是有总部+城市分公司模式，业务方会在不同城市配置不同活动，每个城市在同一时段内只能有一个在上线的活动，同时用户可以去参加不同城市的活动，具体的参与是否成功以最终被推荐人的入职城市决定。
由于没有接触过推荐拉新类后台的设计，所以一开始在设计活动配置时，本着灵活配置的原则，将星级配置关联活动，每一个活动规则配置完成后支持进行星级配置。产品内部需求评审的时候遭到质疑：星际配置要不要关联活动？
所以进行了以下梳理：
1）首先，从活动和星级本身的关系来看
活动的创建是拉新系统的和核心需求，活动直接关联的是用户奖励，而星级属于用户激励手段的一种，是用户奖励的影响因素，所以活动和星级没有直接的关联，而是通过奖励产生间接性关联，在理论两者没有关联的必要性。
2）从业务以及用户的使用场景来看
如果星级关系关联活动
对于业务，如果星级关联活动，那么每个城市可以根据城市的推荐能力设定星级的等级；如果总部统一设计，则方便管理。看似没有太大的差别。
对于用户，如果星级规则关联活动的话，会产生以下两点问题：
--用户可以同时参加不同城市分公司的活动，那么用户A同时参加了公司多个活动后，对应多个星级，这不符合一般星级设置的原则的。
--倘若用户在A城市推荐了非常多的人获得了很高的星级，那么当A城市重新上架一个活动，或者用户参加B城市的活动，用户星级系数会重新累计，也就是说用户之前做出的努力清零，需要重新洗牌开始游戏，这显然是反人类的设计。
综上：星级规则单独进行配置，一个公司的总部和城市使用一套相同的规则。
既然星级规则不关联活动，进行鼓励配置，那么，作为春节前的紧急项目，资源有限的情况下该如何处理星级规则？
再次回溯项目目标：直接目标是为了帮助电销系统增加司机线索,间接目标是而提升司机转化数量，以提升公司运力。那么年前加急小版本首先要达到收集司机线索则的原则，必要的功能为活动的配置以及获奖明细。如果没有星级规则，并不会影响核心功能的实现，所以，星级规则暂时可以根据业务现在的规则，固定写死，将灵活配置安排在二期规划中。
总结：星级规则无需关联活动，一期暂时写死，二期支持业务自行配置。
5.2 奖励明细是推荐人维度统计还是以活动维度统计
1）推荐明细的作用：查看活动效果，方便业务为获得奖励者打款，以及标注奖励的处理进度。
2）推荐人维度统计推荐明细：将推荐人参与的每个活动获得的奖励进行整合，展示总达标金额，业务可明显看出有优质推荐人，以及推荐奖励的金额设置是否合理。。
3）活动维度统计推荐明细：产生该活动下所有的推荐关系明细，条目多，一个推荐人会产生多条明细。
4）结合业务场景分析
业务一般是在一个活动结束后，统一查看达标明细并进行奖励的打款事宜，如果以推荐人维度进行统计，业务依旧需要从推荐人获得的总的奖励中拉取在这次活动中获取的奖励，由此来看，依旧是需要在活动维度统计推荐明细。
刚刚朋友回来说今天我们团队tx全军覆没，
最近每天都好累啊，但是还是要向前冲鸭~~~
