客户案例 · 教培机构 · BC 省
匿名案例｜BC 三校区教培机构运营系统：排课、出勤、课消、结算一条线
为三个校区的教培机构定制一套自己的运营系统，接替按席位收费的排课软件：出勤是数据的源头，课消、发票、教师工时都由它算出来。
隐私说明：机构已匿名，名称和学员信息都已去掉，只保留架构、流程和交付结果。
项目概述
为一家三校区连锁教培机构定制的运营系统，替换了原来按席位付费的 SaaS：学生与家庭档案、课程目录、周期性排课与冲突检测、出勤记录、课时包、发票和收款；教师工时通过版本化 API，自动推送到员工管理系统算薪。客户身份已匿名处理。
教培机构运营的痛点，从来不是「缺一个功能」，而是数据链断了：排课在一个系统，出勤登记在表格里，课消结算靠人工对账，教师工时月底再统计一遍。每个环节都可能出错，每个月都在重复劳动。机构原来用的排课软件按席位收费，面向的是通用市场；机构想要贴合自己的流程，数据也想握在自己手里。 我们为它定制了一套运营系统，核心设计就一句话：出勤是数据的源头，其余一切都由出勤推算。
挑战
三个校区共用一套按席位收费的 SaaS 排课工具：周期课程排课容易冲突，出勤和课消对不上，课时包余额靠人工维护，教师课时费月底手工统计。校区越多，对账的工作量越大，错了也越难追溯。
我们的方案
围绕「出勤就是数据的源头」，重建整条数据链。前面是学生与家庭档案、课程目录、周期性排课（带教师、教室、学生三个维度的冲突检测）；每节课的出勤记录一经确认，就自动驱动后面的一切：课时包扣减、发票生成、收款核销、教师工时累计。教师工时不再手工统计，而是通过版本化 API，自动推送到我们为同一批客户做的员工管理系统，进入薪酬流程。系统按模块交付，三个校区的数据统一，权限隔离。
成果
三个校区在同一个系统里统一运营：排课冲突在创建时就被拦住；出勤一确认，课消、余额、发票自动更新，月底的人工对账没有了；教师工时随出勤实时累计，直通薪酬系统。机构摆脱了按席位付费的 SaaS，数据完全自有。
出勤是数据的源头
系统里所有钱和时间的流转，都从出勤记录推算：
- 出勤确认，课时包自动扣减，余额实时可见。
- 出勤累计，发票按实际消课生成，家长看到的每一笔，都有出勤作依据。
- 出勤就是工时，教师课酬按确认的出勤自动累计，月底不用再统计。
- 改出勤必留痕，任何补登、更正都有操作记录，对账可以回溯。
「哪个数字是对的」这个问题，从制度上就没有了：只有出勤是录入的，其余都是算出来的。
周期排课和三维冲突检测
教培排课的复杂，在于周期性：一门课每周固定时段上 20 周，中途换教室、调教师、学生插班，都是常事。系统在创建和修改排课时，就同时检测教师、教室、学生三个维度的冲突，冲突在保存前就暴露出来，不用等到开课当天才发现。
工时直通薪酬：两套系统的版本化对接
教师在运营系统里产生工时，在员工管理系统里领薪酬。两套系统通过版本化 API 对接：运营系统按确认的出勤推送工时，薪酬那边带着幂等和版本校验来接收，重复推送不会重复计薪，接口升级也不会打乱对账。
- 工时推送幂等：同一节课的工时，不会因为重试而重复入账。
- 接口带版本：任何一边升级，都不影响另一边已有的对账。
- 员工管理系统本身就是我们的独立产品（12 个可开关的模块：考勤、请假、绩效、任务、佣金、薪酬等）。
技术拆解
- 后端是 Python（Flask）加 PostgreSQL 和 Redis 任务队列，前端 Next.js，Docker Compose 部署。
- 和同一批客户的 CRM、员工管理系统，共用同一套平台架构，刻意「复制而不是共用数据库」，各个产品独立演进，互不拖累。
- 按模块交付：档案、排课、出勤、课时包、发票收款，各是一个独立模块，按需启用。
- 三个校区共用一个数据库，按校区隔离权限，跨校区报表开箱即用。
可复用经验
- 运营系统的头一个设计决定，是选定数据的源头；选错了（或者没有），后面全是对账。
- 换掉通用 SaaS，省订阅费是小事，要紧的是数据归自己、流程贴合自己。
- 跨系统的钱务接口，必须幂等加版本化，否则每一次重试和升级，都是一次财务事故。