少儿编程约课小程序案例：班级名额、课时与作品｜互联商通

一、客户背景与痛点

这家机构单校区运营，主打少儿编程班课。招生靠公众号，但排课、点名、作品展示还在群里和人脑里。

四个最疼的问题：

• 约课靠接龙：家长群里接龙报班，名额超编、漏报时有发生。
• 课时口算：课时包用了几次靠老师心算，家长质疑无从对证。
• 作品难归档：学员作品散在微信群和电脑里，学期末没法系统展示。
• 续费无依据：课消与作品没有沉淀，续费沟通缺少材料。

二、方案总览：4 步从群接龙到课时闭环

首版克制，只做「班、课、账」闭环，先不做卖课商城。

1. 班级与名额上架：班级、时段、名额结构化，约课前先看余位。
2. 家长选班约课：家长按孩子时段选班约课，名额锁定不超编。
3. 课时核销：到课上完即核销，课时余额双方可见。
4. 作品集归档：作品按学员归档，家长端可回看可分享。

完整能力清单见 少儿编程解决方案；同类机构可参考 外语约课案例。

三、核心功能清单

• 班级名额管理：班级、时段、上限结构化，超编约不进去。
• 家长约课：选班、请假、补课都在小程序完成。
• 课时核销：上课即核销，余额与消耗记录可查。
• 作品集：作品按学员归档，按学期筛选回看。
• 家长通知：约课成功、课消、请假提醒自动触达。

四、落地实施过程

总览讲的是方案逻辑，这一节讲它怎么落到机构里：五周完成上线，拆成下面五个动作，前一步跑顺再进下一步。

1. 进场准备：班级与课时包建档。开工先把班级、时段、老师、名额逐项录入校对，课时包规则先定死——请假扣不扣次、补课怎么补、有效期多久。商家看到的是一张张班级卡片对完；家长此时还感知不到变化，但客服回答「这期还剩几个名额」时已经不用翻表。
2. 系统对接：课时余额与通知打通。上线前把课时包、核销记录与家长端打通对账，约课、请假、课消三类通知自动触达。课时不再口算，按学员就能查到用了几次、还剩几次；商家感知是家长质疑课时的时候，截图一发就能对清。
3. 员工培训：一条主线加两套话术。老师只强调一条：下课即点核销。对家长话术很简单——「小程序里约课、看课时、看作品，不用再接龙」；前台学会后台调班、看课消，日常运营不再事事找技术支持。
4. 灰度试点：两个班先跑，改完再全铺。全量放开前先拿两个班试跑，前台与老师跟着盯：名额有没有超、核销有没有漏、作品归档顺不顺。试出的问题当场改——班级时段校准、扣次规则修正，再逐班铺开；试点期不做数字考核，只看流程顺不顺。
5. 值班与应急：首月盯课消与请假。上线首月重点盯两类突发：老师调课、家长集中请假。核销点漏了当天补录；家长不会用，前台代操作兜底，接龙与小程序并行不强制。试点暴露的问题全部进了第七节的复盘清单。

五、明确没做的事（对比与取舍）

首版不做直播售课商城，不做全国连锁招生玩法。先保证课消闭环可验，再叠加大班课与线上课；第二校区复制前先只读并行一个月，再切换强制流程。

六、上线后效果（试点数据口径）

试点期内：

• 课时账目从口算变成按学员可对账。
• 班级约课不再撞班超编（试点口径）。
• 机构验收只看「课时对平、约课成功率」，而不是群消息数。

所有数字为项目试点口径，复制前请重估班级结构、师资与扣次规则；数据对比写清分子分母与排除周。

七、坑与复盘

1. 教育类目卡审：类目与资质先按线下办学材料备齐，见 类目选择。
2. 儿童隐私信息收集过度：学员信息只留必要字段，见 隐私协议。
3. 请假扣次规则打架：口头规则与系统规则不一致引发投诉，规则先写死再开约课。

复盘沉淀为方法论：把可勾选验收句写进开工单，避免「上线了」代替「课时对平了」；扣次与补课规则从第一天写进系统，否则解释权只能留给客服吵架。

八、常见问题 FAQ