后台系统:代报考服务设计

1 评论 6574 浏览 11 收藏 14 分钟

本文以代报考服务为例,分享B端产品功能设计的心得体会,一起来看看~

什么是代报考

代报考是指学员报考条件达不到要求或者是自己感觉比较麻烦,委托第三方教育机构代为报考的一种形式。

代报考服务与网课捆绑式售卖是现在职业教育、成人教育的主要售卖形式,它的产生解决了未达到报考条件的考生提升技能的需求,有利于提高网课销售成交率。

但是线下报考资料收集繁杂且纸质资料易丢失,财务收款确认无法一一对应,造成账务混乱等现象的存在,致使线上代报考服务需求的产生。

代报考会涉及哪些功能

上面是关于代报考服务的简易流程图,为了清晰展示业务流,我把后端是如何与前端呼应的也画了出来。从图中我们可以看到学员在网校只做3件事即可,即填写报考信息、缴费、查看成绩,但是对应后台我们看到正常情况下的流程就比前端多一倍的逻辑,这还没有涉及到异常情况的产生。

那下面我们就着重讲一下,后台的逻辑是如何产生的以及还存在哪些异常情况。

创建报考规则

报考规则即不同考试类目下依据考试院要求,制定的不同的报考规范。在设计过程中,要根据业务不同考虑不同规则的需要。

当前场景下,报考规则包含了以下两种:

  1. 缴费规则,用于区分用户属性,用户属性是指通过专业和学历判定目标用户是否需要缴纳协报费用(协助未达到报考条件的考生进行报考,所需支付的额外费用);
  2. 补考规则,用于区分用户成绩,判定学员是否需要补考。

创建报考活动

报考规则设置好后,就需要设置报考活动,设置此次考试的考期、关联的商品、报考开始/结束时间、考点以及各类考试费用等。

其中,关联商品是设置报考活动中最为重要的一个环节,通过以下几点进行说明:

第一,为什么要关联商品?

(1)大部分代报考服务项目是和课程捆绑式售卖的,想要获得代报考服务需要选择对应商品。

(2)不同专业的学员报考类目不同,为了区分不同的适用学员,需要与商品进行关联。

第二,关联商品可以解决哪些问题?

(1)仅对商品包含代报考服务的学员进行服务,加强服务的精准性。

(2)针对不同的学员发放不同的报考项目,减少学员信息的冗余性。

第三,注意事项有哪些?

选择指定商品的时候一定要全面,否则学员无法在网校端进行报考。此处为了减少机构漏选,建议在商品列表上增加代报考服务字段,在选择商品时可以对存在代报考服务的商品进行筛选,避免漏选商品带来不必要的损失。

发布报考活动

设置完成报考活动的各类信息即可保存,保存后的报考活动由未发布转为为已发布状态,学员在网校端就可以报考了。

这里我选择的是手动发布,为了避免发布的报考活动存在错误信息,建议机构老师对保存成功的信息检查无误后,手动将状态改为已发布。

报考规则与报考活动的关系——一对多

报考规则和报考活动为什么要分开设置,之间又存在什么关系。

如下图所示,一个报考类目对应一个报考规则,一个报考规则对应多个报考活动。为什么存在一对多的关系:报考规则适用于所有的报考活动,而报考活动是在报考规则下设定的每次考试对应的报考细节,如:考期、报考点等。除此之外,分开设置可以简化系统的重复性操作,降低人工操作成本。

学员状态的判定

学员在网校报名后,会在后台生成报名信息,针对收集/上传的信息,学员会存在以下8种状态:

(1)未开始:学员的初始状态

(2)信息填写:学员在网校填写信息但未缴费的状态,学员填写了信息并保存,状态会自动由未开始转变为信息填写

(3)已缴费:学员缴费成功

(4)已退费:学员退费成功

(5)报考成功:即机构帮助学员报考成功,学员有资格进行考试。判定条件:需要把成功报考的学员列表导入系统,存在列表中的已缴费学员,导入成功后状态自动转为报考成功

(6)报考失败:因各种不可抗因素,机构对已缴费学员未能进行报考即为报考失败。判定条件:未在导入列表但已经缴费成功的学员,导入成功后状态自动改为报考失败

(7)成绩通过:根据报考规则的设定,判定成绩通过的学员。判定条件:导入成绩并与报考规则进行校验,根据校验结果对报考成功的学员自动更改状态

(8)成绩未通过:根据考试规则的设定,成绩未通过的学员,判定规则同成绩通过。

如此细分的状态可以让老师时刻掌握学员的情况,在有效时间内督促学员完成报考。

异常情况

每一个业务的都会存在异常情况,在了解需求时需要多想、多问,只有提前考虑到才会解决后期的各种麻烦,以下我列举了3种代报考服务中存在的异常情况及解决方案。

(1)学员信息填写错误怎么办?

做任何产品不论是C端还是B端必不可少的就是增删改查,为了避免信息填写错误,需要留有修改入口,修改入口可以根据实际场景需要放在网校端或者是后台,这里建议放在后台,把修改数据的权限留给老师。

后台的修改入口根据我们的业务需要我放在了两个位置:

第一,以学员为维度,学员中心(以学员维度展示学员信息的集中地)内学员代报考信息展示区的右上角,在这里老师可以通过搜索学员,快速找到学员的代报考信息,并进行更改。

第二,以代报考活动为维度,在学员信息的列表中,老师在查看报考活动时通过搜索学员姓名和手机号,进行信息更改。

第一种相比与第二种会更快速定位到学员;但第二种比第一种更精准,可以看到更多关于学员的信息,如:学员状态、支付时间等。

后台系统:代报考服务设计

(2)学员想退费怎么办?

退费即取消报考,对应增删该查中的删,已经缴费但想取消报考的场景。退费有这样几个流程:

  1. 发起退费申请;
  2. 退费审批成功;
  3. 财务老师打款。

一般发起退费申请的都是学员,但是建议把退费权限留给老师,避免学员反复报名/退费带来的不必要的麻烦,但是这里也是需要根据需求分析来定义每个对象所拥有的权限。

退费权限留给老师,退费流程可以适当简化为:

  1. 操作退费;
  2. 财务老师打款,因为学员退费的申请转变为和老师交流,老师同意退款即审批通过。

退费入口同编辑入口一样为了实现不同场景的需求,分别留在了两个位置,在这里就不多做赘述了。

(3)学员未能在网校端报名,给负责老师已经转账成功,想参加考试怎么办?后期可以在网校查看成绩吗?

针对在线上没有完成报名,但在线下缴费成功的现象也是存在的,与之类似的还有历史数据的存在,如之前一直是线下操作代报考服务,之后想通过线上完成操作,其实这是一类问题,我们把它称之为历史遗留性问题。

考虑到历史遗留性问题的存在,有以下几种方式可以解决:

  1. 历史数据一个个补录,手动调整状态;
  2. 把数据整理成表格进行导入。

显而易见,第二种方式更为简单,但是历史数据的学员目前所处的状态也存在差别,成绩通过的、成绩未通过的、缴费完成的、缴费未完成的,面对如此多的状态导入哪些数据呢?

经过分析,我的处理方案是,分批导入,即文章前面提到的成绩导入和判断报考是否成功的报考导入,即可解决历史遗留性问题。

第一,成绩导入,可以把成绩通过的和成绩未通过的区分开来,后期成绩未通过的依然可以在网校端进行补考;

第二,报考导入,针对线下缴费成功的学员,报考成功后,需要把线下缴费学员的信息填写到列表中一并导入,学员状态可以自动转为报考成功,针对于在线下还未缴费的学员,老师可以通知学员去网校填写信息并缴费,从而完成报考。

经验之谈

(1)一个新功能的开启需要了解用户需求,并进行业务流程、角色与使用场景的分析

设计一个新功能之前务必全面了解用户需求,串联业务场景、分析使用场景,如果条件允许建议实地考察用户的日常操作,做到知己知彼方能百战不殆。

(2)一个新功能的落地需要做到逻辑缜密,考虑异常情况尤为关键

了解了用户需求和业务流程,就需要设计功能了,首先需要画出一个简易流程图,先把正常流程画出来,再去思考是否存在异常情况,如果存在异常情况应该如何处理,此时你会发现简易流程图会变复杂,你的逻辑也得到了一次次的锻炼。

好了,以上就是我今天的分享了,如果有疑问或者见解欢迎大家留言哦~

 

作者:Linda,公众号:教育产品人

本文由 @Linda 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 通俗易懂,逻辑清晰,赞👍

    回复