产品经理后台系统：代报考服务设计

1、本文以代报考服务为例，分享B 端产品功能设计的心得体会，一起来看看代报考是指学员报考条件达不到要求或者是自己感觉比较麻烦，委托第三方教育机构代为报考的一种形式。代报考服务与网课捆绑式售卖是现在职业教育、成人教育的主要售卖形式，它的产生解决了未达到报考条件的考生提升技能的需求，有利于提高网课销售成交率。但是线下报考资料收集繁杂且纸质资料易丢失，财务收款确认无法一一对应，造成账务混乱等现象的存在，致使线上代报考服务需求的产生。上面是关于代报考服务的简易流程图，为了清晰展示业务流，我把后端是如何与前端呼应的也画了出来。从图中我们可以看到学员在网校只做3 件事即可，即填写报考信息、缴费、查看成绩，但是

2、对应后台我们看到正常情况下的流程就比前端多一倍的逻辑，这还没有涉及到异常情况的产生。那下面我们就着重讲一下，后台的逻辑是如何产生的以及还存在哪些异常情况。报考规则即不同考试类目下依据考试院要求，制定的不同的报考规范。在设计过程中，要根据业务不同考虑不同规则的需要。当前场景下，报考规则包含了以下两种：报考规则设置好后，就需要设置报考活动，设置此次考试的考期、关联的商品、报考开始/结束时间、考点以及各类考试费用等。其中，关联商品是设置报考活动中最为重要的一个环节，通过以下几点进行说明：第一，为什么要关联商品？（ 1）大部分代报考服务项目是和课程捆绑式售卖的，想要获得代报考服务需要选择对应商品。（

3、2）不同专业的学员报考类目不同，为了区分不同的适用学员，需要与商品进行关联。第二，关联商品可以解决哪些问题？（ 1）仅对商品包含代报考服务的学员进行服务，加强服务的精准性。（ 2）针对不同的学员发放不同的报考项目，减少学员信息的冗余性。第三，注意事项有哪些？选择指定商品的时候一定要全面，否则学员无法在网校端进行报考。此处为了减少机构漏选，建议在商品列表上增加代报考服务字段，在选择商品时可以对存在代报考服务的商品进行筛选，避免漏选商品带来不必要的损失。设置完成报考活动的各类信息即可保存，保存后的报考活动由未发布转为为已发布状态，学员在网校端就可以报考了。这里我选择的是手动发布，为了避免发布的报考

4、活动存在错误信息，建议机构老师对保存成功的信息检查无误后，手动将状态改为已发布。报考规则和报考活动为什么要分开设置，之间又存在什么关系。如下图所示，一个报考类目对应一个报考规则，一个报考规则对应多个报考活动。为什么存在一对多的关系：报考规则适用于所有的报考活动，而报考活动是在报考规则下设定的每次考试对应的报考细节，如：考期、报考点等。除此之外，分开设置可以简化系统的重复性操作，降低人工操作成本。学员在网校报名后，会在后台生成报名信息，针对收集/ 上传的信息，学员会存在以下 8 种状态：1）未开始：学员的初始状态2）信息填写：学员在网校填写信息但未缴费的状态，学员填写了信息并保存，状态会自动由未

5、开始转变为信息填写3）已缴费：学员缴费成功4）已退费：学员退费成功5）报考成功：即机构帮助学员报考成功，学员有资格进行考试。判定条件：需要把成功报考的学员列表导入系统，存在列表中的已缴费学员，导入成功后状态自动转为报考成功6）报考失败：因各种不可抗因素，机构对已缴费学员未能进行报考即为报考失败。判定条件：未在导入列表但已经缴费成功的学员，导入成功后状态自动改为报考失败7）成绩通过：根据报考规则的设定，判定成绩通过的学员。判定条件：导入成绩并与报考规则进行校验，根据校验结果对报考成功的学员自动更改状态8）成绩未通过：根据考试规则的设定，成绩未通过的学员，判定规则同成绩通过。如此细分的状态可以让老

6、师时刻掌握学员的情况，在有效时间内督促学员完成报考。每一个业务的都会存在异常情况，在了解需求时需要多想、多问，只有提前考虑到才会解决后期的各种麻烦，以下我列举了 3 种代报考服务中存在的异 常情况及解决方案。1）学员信息填写错误怎么办？做任何产品不论是C 端还是 B 端必不可少的就是增删改查，为了避免信息填写错误，需要留有修改入口，修改入口可以根据实际场景需要放在网校端或者是后台，这里建议放在后台，把修改数据的权限留给老师。后台的修改入口根据我们的业务需要我放在了两个位置：第一，以学员为维度，学员中心（以学员维度展示学员信息的集中地）内学员代报考信息展示区的右上角，在这里老师可以通过搜索学员，

7、快速找到学员的代报考信息，并进行更改。第二，以代报考活动为维度，在学员信息的列表中，老师在查看报考活动时通过搜索学员姓名和手机号，进行信息更改。第一种相比与第二种会更快速定位到学员；但第二种比第一种更精准，可以看到更多关于学员的信息，如：学员状态、支付时间等。2）学员想退费怎么办？退费即取消报考，对应增删该查中的删，已经缴费但想取消报考的场景。退费有这样几个流程：一般发起退费申请的都是学员，但是建议把退费权限留给老师，避免学员反复报名/退费带来的不必要的麻烦，但是这里也是需要根据需求分析来定义每个对象所拥有的权限。退费权限留给老师，退费流程可以适当简化为：退费入口同编辑入口一样为了实现不同场景

8、的需求，分别留在了两个位置，在这里就不多做赘述了。3）学员未能在网校端报名，给负责老师已经转账成功，想参加考试怎么办？后期可以在网校查看成绩吗？针对在线上没有完成报名，但在线下缴费成功的现象也是存在的，与之类似的还有历史数据的存在，如之前一直是线下操作代报考服务，之后想通过线上完成操作，其实这是一类问题，我们把它称之为历史遗留性问题。考虑到历史遗留性问题的存在，有以下几种方式可以解决：显而易见，第二种方式更为简单，但是历史数据的学员目前所处的状态也存在差别，成绩通过的、成绩未通过的、缴费完成的、缴费未完成的，面对如此多的状态导入哪些数据呢？经过分析，我的处理方案是，分批导入，即文章前面提到的成绩导入和判断报考是否成功的报考导入，即可解决历史遗留性问题。第一，成绩导入，可以把成绩通过的和成绩未通过的区分开来，后期成绩未通过的依然可以在网校端进行补考；第二，报考导入，针对线下缴费成功的学员，报考成功后，需要把线下缴费学员的信息填写到列表中一并导入，学员状态可以自动转为报考成功，针对于在线下还未缴费的学员，老师可以通知学员去网校填写信息并缴费，从而完成报考。1）一个新功能的开启需要了解用户需求，并进行业务流程、角色与使用场景的分析设计一个新功能之前务必全面了解用户需求，串联业务场景、分析使用场景，如果条件允许建议实地考察用户的日常操作，做到知己知彼方能百