本文以代报考服务为例，分享B端产品功能设计的心得体会，一起来看看~
什么是代报考
代报考是指学员报考条件达不到要求或者是自己感觉比较麻烦，委托第三方教育机构代为报考的一种形式。
代报考服务与网课捆绑式售卖是现在职业教育、成人教育的主要售卖形式，它的产生解决了未达到报考条件的考生提升技能的需求，有利于提高网课销售成交率。
但是线下报考资料收集繁杂且纸质资料易丢失，财务收款确认无法一一对应，造成账务混乱等现象的存在，致使线上代报考服务需求的产生。
代报考会涉及哪些功能
上面是关于代报考服务的简易流程图，为了清晰展示业务流，我把后端是如何与前端呼应的也画了出来。从图中我们可以看到学员在网校只做3件事即可，即填写报考信息、缴费、查看成绩，但是对应后台我们看到正常情况下的流程就比前端多一倍的逻辑，这还没有涉及到异常情况的产生。
那下面我们就着重讲一下，后台的逻辑是如何产生的以及还存在哪些异常情况。
创建报考规则
报考规则即不同考试类目下依据考试院要求，制定的不同的报考规范。在设计过程中，要根据业务不同考虑不同规则的需要。
当前场景下，报考规则包含了以下两种：
缴费规则，用于区分用户属性，用户属性是指通过专业和学历判定目标用户是否需要缴纳协报费用（协助未达到报考条件的考生进行报考，所需支付的额外费用）；
补考规则，用于区分用户成绩，判定学员是否需要补考。
创建报考活动
报考规则设置好后，就需要设置报考活动，设置此次考试的考期、关联的商品、报考开始/结束时间、考点以及各类考试费用等。
其中，关联商品是设置报考活动中最为重要的一个环节，通过以下几点进行说明：
第一，为什么要关联商品？
（1）大部分代报考服务项目是和课程捆绑式售卖的，想要获得代报考服务需要选择对应商品。
（2）不同专业的学员报考类目不同，为了区分不同的适用学员，需要与商品进行关联。
第二，关联商品可以解决哪些问题？
（1）仅对商品包含代报考服务的学员进行服务，加强服务的精准性。
（2）针对不同的学员发放不同的报考项目，减少学员信息的冗余性。
第三，注意事项有哪些？
选择指定商品的时候一定要全面，否则学员无法在网校端进行报考。此处为了减少机构漏选，建议在商品列表上增加代报考服务字段，在选择商品时可以对存在代报考服务的商品进行筛选，避免漏选商品带来不必要的损失。
发布报考活动
设置完成报考活动的各类信息即可保存，保存后的报考活动由未发布转为为已发布状态，学员在网校端就可以报考了。
这里我选择的是手动发布，为了避免发布的报考活动存在错误信息，建议机构老师对保存成功的信息检查无误后，手动将状态改为已发布。
如下图所示，一个报考类目对应一个报考规则，一个报考规则对应多个报考活动。为什么存在一对多的关系：报考规则适用于所有的报考活动，而报考活动是在报考规则下设定的每次考试对应的报考细节，如：考期、报考点等。除此之外，分开设置可以简化系统的重复性操作，降低人工操作成本。
学员状态的判定
学员在网校报名后，会在后台生成报名信息，针对收集/上传的信息，学员会存在以下8种状态：
（1）未开始：学员的初始状态
（2）信息填写：学员在网校填写信息但未缴费的状态，学员填写了信息并保存，状态会自动由未开始转变为信息填写
（3）已缴费：学员缴费成功
（4）已退费：学员退费成功
（5）报考成功：即机构帮助学员报考成功，学员有资格进行考试。判定条件：需要把成功报考的学员列表导入系统，存在列表中的已缴费学员，导入成功后状态自动转为报考成功
（6）报考失败：因各种不可抗因素，机构对已缴费学员未能进行报考即为报考失败。判定条件：未在导入列表但已经缴费成功的学员，导入成功后状态自动改为报考失败
（7）成绩通过：根据报考规则的设定，判定成绩通过的学员。判定条件：导入成绩并与报考规则进行校验，根据校验结果对报考成功的学员自动更改状态
（8）成绩未通过：根据考试规则的设定，成绩未通过的学员，判定规则同成绩通过。
如此细分的状态可以让老师时刻掌握学员的情况，在有效时间内督促学员完成报考。
异常情况
每一个业务的都会存在异常情况，在了解需求时需要多想、多问，只有提前考虑到才会解决后期的各种麻烦，以下我列举了3种代报考服务中存在的异常情况及解决方案。
（1）学员信息填写错误怎么办？
做任何产品不论是C端还是B端必不可少的就是增删改查，为了避免信息填写错误，需要留有修改入口，修改入口可以根据实际场景需要放在网校端或者是后台，这里建议放在后台，把修改数据的权限留给老师。
后台的修改入口根据我们的业务需要我放在了两个位置：
第一，以学员为维度，学员中心（以学员维度展示学员信息的集中地）内学员代报考信息展示区的右上角，在这里老师可以通过搜索学员，快速找到学员的代报考信息，并进行更改。
第二，以代报考活动为维度，在学员信息的列表中，老师在查看报考活动时通过搜索学员姓名和手机号，进行信息更改。
第一种相比与第二种会更快速定位到学员；但第二种比第一种更精准，可以看到更多关于学员的信息，如：学员状态、支付时间等。
（2）学员想退费怎么办？
退费即取消报考，对应增删该查中的删，已经缴费但想取消报考的场景。退费有这样几个流程：
发起退费申请；
退费审批成功；
财务老师打款。
一般发起退费申请的都是学员，但是建议把退费权限留给老师，避免学员反复报名/退费带来的不必要的麻烦，但是这里也是需要根据需求分析来定义每个对象所拥有的权限。
退费权限留给老师，退费流程可以适当简化为：
操作退费；
财务老师打款，因为学员退费的申请转变为和老师交流，老师同意退款即审批通过。
退费入口同编辑入口一样为了实现不同场景的需求，分别留在了两个位置，在这里就不多做赘述了。
（3）学员未能在网校端报名，给负责老师已经转账成功，想参加考试怎么办？后期可以在网校查看成绩吗？
针对在线上没有完成报名，但在线下缴费成功的现象也是存在的，与之类似的还有历史数据的存在，如之前一直是线下操作代报考服务，之后想通过线上完成操作，其实这是一类问题，我们把它称之为历史遗留性问题。
考虑到历史遗留性问题的存在，有以下几种方式可以解决：
历史数据一个个补录，手动调整状态；
把数据整理成表格进行导入。
显而易见，第二种方式更为简单，但是历史数据的学员目前所处的状态也存在差别，成绩通过的、成绩未通过的、缴费完成的、缴费未完成的，面对如此多的状态导入哪些数据呢？
经过分析，我的处理方案是，分批导入，即文章前面提到的成绩导入和判断报考是否成功的报考导入，即可解决历史遗留性问题。
第一，成绩导入，可以把成绩通过的和成绩未通过的区分开来，后期成绩未通过的依然可以在网校端进行补考；
第二，报考导入，针对线下缴费成功的学员，报考成功后，需要把线下缴费学员的信息填写到列表中一并导入，学员状态可以自动转为报考成功，针对于在线下还未缴费的学员，老师可以通知学员去网校填写信息并缴费，从而完成报考。
经验之谈
（1）一个新功能的开启需要了解用户需求，并进行业务流程、角色与使用场景的分析
设计一个新功能之前务必全面了解用户需求，串联业务场景、分析使用场景，如果条件允许建议实地考察用户的日常操作，做到知己知彼方能百战不殆。
（2）一个新功能的落地需要做到逻辑缜密，考虑异常情况尤为关键
了解了用户需求和业务流程，就需要设计功能了，首先需要画出一个简易流程图，先把正常流程画出来，再去思考是否存在异常情况，如果存在异常情况应该如何处理，此时你会发现简易流程图会变复杂，你的逻辑也得到了一次次的锻炼。
好了，以上就是我今天的分享了，如果有疑问或者见解欢迎大家留言哦～
