作为一个入行不久的教育圈新人，分享一下这1年多，对教育行业中，关于“K12教育整体业务流程所涉及各类产品分析”的分享。

其实教育行业整体来说， 分为很多模式，以及针对不同年龄段和不同受众的教育产品。

从模式上来说，有以下几类：

• 做教育类产品，然后把产品卖给学校或者培训机构，比如一起作业和作业盒子；

• 为教育行业提供解决整套解决方案，比如云学堂等；

• 以教育培训为主的新东方和学而思；

• 做直播课或AI（录播课）进行售卖，比如斑马英语、VIPKID；

• 从受众群体来看，有的是K12，有的是职业教育。

• 而互联网渗透的比较多的，也就是K12和职业教育。

互联网教育类公司，会比一些正常的互联网公司多很多部门，比如说正常的互联网公司，有研发、测试、产品、市场、商务、运营；偏销售类的互联网公司，会有电销和客服；偏电商类的会有整个供应链；而互联网教育公司包含以上部门的同时，还会多教务以及教学教研部门。

其实K12互联网公司，就像是一个小学校——有班主任对学生的管理、有教研团队研发课程、有教务部门做排班排课管理、有教学对整体师资进行管理。

那么相对涉及的业务流程也会比较复杂，同时也会涉及到各类的产品系统。

那么接下来，我从一个教育公司，一个用户（家长）的角色，从注册到最后付费，以及到退费的整体流程来进行展开说明，会涉及到的各类产品。

1、注册

涉及产品岗位：增长类产品、营销活动类产品、数据产品。

涉及产品系统及模块：营销中台、活动管理、优惠券管理、数据中台、用户标签体系、数据埋点、账号中台、用户入库。

分析：

注册大概分为2个场景，一个是APP的自然增长，用户从APP端进行注册；另外一个场景就是通过各个市场投放页，或者转介绍拉新，用户进行注册从而成为一个用户。

那么表面上看只是个简简单单的拉新，其实这其中的逻辑可能涉及了运营活动人员和增长产品的配合，对整体活动的配置；以及如果有优惠券，对应的策略，和有针对性的对某些重点用户，使用用户标签体系去做对应的活动；同时需要做好数据埋点，方便对整体活动进行监控，设计活动漏斗分析，对整体活动进行数据监控，同时用户入库。

对于有多个业务线的教育公司来说，比如有1对1，或者小班课，或者录播课业务的公司；需要把入库用户进行同步，方便后续对用户的引导转化等。

2、Leads进入公海

涉及产品岗位：CRM产品。

涉及产品系统以及模块：业务后台系统、Leads分配策略、数据中台、用户标签体系。

分析：

教育行业一般会把新注册的用户叫做Leads，然后教育行业的售前角色、CC（课程顾问），会对进入的Leads进行沟通，同时进行付费转化的引导。

那么其实教育公司的CC角色的人数是很多的， 稍大体量的教育公司，CC的人数会占据将近50%左右；那么Leads的分配是一个很关键的问题，Leads也会分为各个等级，比如从官网过来的，肯定是意向度相对最高的，一般称为S级；从落地页过来的，也会根据对应的市场渠道优质，分为ABC等级，从转介绍过来的一般我们会称为R级等等。

那么优质例子会需要更专业的CC去进行转化，转化率会高和稳一些；然后大量的非优质Leads，可以给一些新手CC熟悉业务等，那么整体的Leads分配策略会显得尤为重要，因为同样大量的Leads，以及对应的CC，如何进行策略分配，才能达到最高转化；而且Leads也基本都是有时效的，如果未在一定时间内联系用户，那么后续再想转化肯定会对用户有不好的体验。

同时当某个CC未进行Leads转化，那么Leads是需要再回流公海等等；同时用户的某些试听行为，以及对应的用户行为，通过数据中台沉淀，再为用户标记标签，从而结合分配策略，更好的提升业务人员工作效率。

3、预约试听

涉及产品岗位：教务产品、呼叫产品、物流产品。

涉及产品系统以及模块：排课系统、呼叫策略、供应链、数据中台、教师标签体系。

分析：

Leads进行合理分配到CC手上后，CC需要进行电话沟通家长，并进行预约试听课；此处呼叫则会需要呼叫产品，涉及对应呼叫的SOP，以及质检、呼叫稳定性、策略以及防骚扰机制设定等。

有些教育公司的试听课，在试听之前，会进行教具的邮寄；那么就涉及到整个物流、供应链的产品、物流路由的配置；根据用户的上课时间，以及所在地，就近发货，采用最低成本的物流进行发货等等；以及仓库监控、库存预警、补货，以及取消发货等等。

在拨打电话，邮寄教具后，还需要进行对应的教师排课，如何从众多老师当中，选出教师进行排课，试听课是决定是否能够转化的一环；不同于后续的排课，需要根据教师标签找出优质师资，例如近7天出勤率、试听转化率、准时率等等，进行排课。

用户试听课后，也需要对应的CC进行及时的回访，访问用户的上课流程体验，能够在一定周期内迅速关单。

4、购买课程

涉及产品岗位：业务后台产品、支付产品。

涉及产品系统以及模块：订单、支付、商品模块。

分析：

用户预约试听后，决定购买课程，购买可以从2个地方进行购买，APP或者业务人员在业务后台生成H5订单发给家长支付；目前由于appstore的分成策略，大多数公司还是选择从业务后台进行订单的生成；那么用户在购买课程的时候，也会有商品以及课时等概念，涉及到商品模块、订单模块、对应的订单有效期等等；订单生成后，又涉及到支付，需支持多场景下的支付，比如H5、APP内，以及公众号、小程序支付等等。

除此以外，还需支持多种支付方式，银行卡、微信、支付宝、信用卡、花呗等等；同时每种支付方式需要对接多家通道、多家服务商、设定支付路由，提高支付稳定性；以及涉及到的费率、支付流水核算等问题，如何能够节省企业支付成本。

5、分配班主任

涉及产品岗位：业务后台产品、教务产品。

涉及产品系统以及模块：业务后台产品、教务产品、学员管理。

分析：

用户完成付费后，系统会自动为学员分配班主任；班主任有各项职责，需要督促以及回答用户的各类学习问题，并针对学员制定学习计划，以及课程安排；同时用户有请假，想要更换老师等诉求，需要跟班主任进行报备，调课等等。

同时有些公司的班主任肩负着更重要的续报率，以及需要完成公司指标，希望家长能够进行转介绍行为，比如转发朋友圈、邀请好友等等。

6、正式上课

涉及产品岗位：教室产品、用户端产品。

涉及产品系统以及模块：课中互动、课件管理。

分析：

用户上课后，一般都是通过APP进行上课，那么K12的产品中，一般教室和除了教室以外分别是2个产品负责：

• 教室外的产品，会负责一些会员体系，APP的常规功能的设计；

• 教室中的产品，注重用户的上课体验，同时对接第三方音视频，一般都是采用的第三方提供的现有能力。

其实上课过程中，用户跟老师的互动尤为重要，站在老师角度，需要提供方便快捷，容易上手的工具提升上课效率，以及上课体验；从学员角度来说，需要能够提起孩子兴趣，跟老师互动，整体的课程体验。从非产品的角度，则是整体教研团队的课程设计，是否能够让家长看到自己孩子的成长，从而为之付费。

同时也需要在课前及时跟家长沟通，调整课前的调试设备，确保用户能够流畅上课；如课中遇到问题，能够迅速找到课中支持人员，进行技术支持。

7、课程评价/阶段性测评

涉及产品岗位：用户端产品、业务后台产品。

涉及产品系统以及模块：投诉管理、工单系统。

分析：

课程到一定时间后，有每节课的课后评价，以及整体系统性的、阶段性测评报告；由教研团队的人进行给用户出具，也能够让家长了解到每个阶段孩子的进步以及还有哪些不足，整体性的对孩子的学习有个里程碑式的记录。

阶段性报告除了系统会根据用户上课的行为做些记录，同时也是需要业务人员自己去填写一些东西，通过人工的一些判断和分析；所以通过工单的方式去进行提醒，工单生成后，指派到学员对应的教研团队和负责的教学经理，然后再由对应的人员完成履行工单。

8、复购

涉及产品岗位：业务后台产品，支付产品。

涉及产品系统以及模块：订单、支付、商品模块、学员管理。

分析：

通过班主任的干涉，用户决定复购后，同样通过业务后台生成订单方式，进行复购。

9、积分累计

涉及产品岗位：用户端产品。

涉及产品系统以及模块：积分商城。

分析：

为增加学员上课积极性、活跃性，以及用户黏性，现在大多数教育产品都会有对应的积分兑换；为了提高消课率、用户活跃率，会在用户上完对应课程后，赠送对应积分，并做积分商城，售卖一些教具或者孩子们喜欢的各种商品；一般会采用第三方或者自建的方式，不管是自建还是第三方，关于商品，都可以通过公司跟供应商合租的方式，进行第三方建库，发货。

10、退费

涉及产品岗位：业务后台产品、用户端产品。

涉及产品系统以及模块：订单、工单系统。

分析：

当用户想要申请退费后，大多由于教育产品的特殊性，其实是没办法在一个可视化的页面由用户直接去申请退费操作的；大多是先跟自己的班主任进行沟通，然后进入一个相对比较长的退费流程，比如说对应的班主任挽单、主管挽单，然后再去进行到财务审核、打款、确认等一系列操作；所以一般通过工单去进行完成整体的退费。

而退费的计算也是比较复杂的，涉及到前期的一些筹备工作，比如一些提前协议的准备，以及每节课的成本核算、老师，以及提给CC的提成、用户的教具，退费的费率，以及已开发票的冲红等等，都需要进行核算后，再给用户退费；同时也要保证整体退费的时间周期，避免由于退款周期过长，引起家长投诉等。

11、其他

除了以上的业务流程，还有很多其他内部系统诸如整体的权限管理，对于这么多系统的统一权限划分；比如消息系统，对于如此长的业务流程，每个节点的触达用户方式，消息提醒包含服务号，app push以及短信等等；统一的财务平台，对于多业务系统的财务核算；

那么以上基本上就是整个K12教育的业务流程，更偏向于1对1的业务；那么其实AI业务还会有所不同，AI业务线大多会采用社群的方式，由电销CRM转为SCRM，以后我会单独就这方面进行展开描述。

我们看到K12教育公司整体会涉及到非常多的系统产品：工单、权限、消息、数据、物流、账号、支付、财务、呼叫、CRM、订单、供应链、商品、教务以及各个业务后台系统等等；单独每个系统其实都很重要的，整体的业务复杂度相比某一单一业务的互联网公司来说要复杂的多。

先分享到这里，欢迎大家一起补充讨论，以上仅对于我个人对于K12教育公司的业务理解，如有不足，希望大家多提建议。

↘好文推荐：

王慧文清华产品课

写给未来产品总监的一封信

菜鸟网络 | 寄件业务的产品逻辑

点个“在看”吧