先说清楚培训机构的三笔糊涂账
培训机构的规模通常不大，但账一点都不简单。前台、教务、老师各记一份，到了月底谁也说不准。
第一笔：学员还剩多少课时。 报名时充了几十节课，之后每上一次课扣一次，中间还有请假、调课、赠课、转班、退费。这些全散在前台的 Excel、老师的纸质点名表和微信聊天记录里。家长月底来问"我家孩子还剩几节"，前台翻半天答不上来，或者答一个数，家长一对账说不对——这类摩擦最伤口碑。
第二笔：这周课排给谁、谁来了。 排课靠微信群接龙，调课靠打个电话，签到靠老师顺手划一下。结果是谁缺勤没人追、老师上了几节课月底靠回忆算、教室撞车当天才发现。
第三笔：谁该续费了。 课时快用完是个信号，但这个信号只有敏感的课程顾问能捕捉到，人一忙就漏。等家长主动来说"我们上完这批先停一停"，再挽留就晚了。
这三笔账的共同点：数据不是没有，而是没有落在同一个地方，也没有自动滚动计算。用 Inkwell AI 构建器可以交付的，就是一套把这三件事串起来的学员课时台账——不是买一个行业软件，而是把机构自己的口径（课时怎么算、请假怎么算、有效期怎么定）写进系统里。
数据怎么建：四本台账，一本流水
先把"有哪些对象"定下来。这个场景的业务对象并不复杂，核心是四个：
一、学员档案。 一个学员一条记录：姓名、家长联系方式、报读的课程、负责的课程顾问、来源渠道、当前状态（在读 / 停课 / 结业 / 退费）。状态很重要，它是后面所有筛选和提醒的抓手——停课学员不该出现在续费清单里。
二、课程与课时套餐。 这是一本"商品目录"：课程名称、课型（一对一 / 小班 / 大班）、一节课折算多少课时、套餐包含多少课时、有效期多长。注意课时数、有效期这些由机构自己填，系统只负责按规则计算；把"一节课扣多少课时"和"有效期怎么算"这两条规则说清楚，比在表里堆字段更值钱。
三、排课与签到。 班级或一对一约课，一条记录对应一节课：日期时间、课程、授课老师、教室、应到学员。签到是这节课的事实凭证——谁来了、谁请假、谁缺勤。
四、课消流水。 这是整套台账的"账本"，也是全篇最关键的设计点：学员剩余课时不用人手填，而是从流水滚动算出来。 每发生一次有效课消，就写一条流水：哪个学员、扣多少课时、关联哪次签到、发生时间、操作人。剩余课时 = 累计购买（含赠课、转班带入） − 累计已消 − 已作废。这样一来：
- 家长问"还剩几节"，打开学员详情就能看到数字，还能点开每一笔扣减
- 前台手工改不了数字，只能通过"补录 / 冲销"留下痕迹
- 退费、转班时，账是平的，不用重新拿计算器对
顺带一提，课时数、金额这类数值字段建议用系统里专门的金额 / 数值控件，避免手工输入时的精度与归类问题；具体的数量与单价由业务自己填，系统只保证算得对、对得上。## 页面怎么用：从查一个人到管一个校区
数据建好之后，日常操作就落在几个页面上。这个场景不需要做很多页，做对几页就够用。
学员台账页（列表 + 筛选）。 所有学员一屏铺开，支持按状态、负责顾问、报读课程、剩余课时区间筛选。前台每天在这里找人是最高频的动作，所以列表要把"剩余课时"和"最后上课时间"直接列出来，而不是点进去才看见。
学员详情页（档案 + 三块内容）。 上半部分是档案和联系方式，下半部分并排三块：购课记录（买过什么套餐、什么时候买的、有效期）、课消流水（每次扣课时的时间和依据）、剩余课时小结。一屏看完，不用来回切页面——这就是它比 Excel 强的地方：不是多了字段，而是把散落的信息按一个人的维度聚起来了。
排课页（周视图）。 以周为单位铺开，一格一节课，能直接看出哪个时段空着、哪个老师排满了、哪个教室撞了。排课本质上是在几个约束之间找位置，把它做成可视化的一张表，比在 Excel 里挪格子要直观得多。
签到与课消页。 一节课对应一张签到单，老师勾选到课学员并保存，系统按规则自动生成课消流水、扣减课时。签到和课消最好是一步走完的动作：如果签到归签到、扣课时归前台手工扣，就又多了一次人手介入的机会，误差就回来了。
续费提醒页。 这是把"课时快用完"这个信号变成行动的一页：按剩余课时低于阈值、或有效期临近两条规则筛出清单，按顾问分组，谁负责谁跟进。顾问每天上班先看这一页，跟进动作就有据可依。
统计页（老师课时与班级情况）。 老师的课时量、班级的到课率、每个顾问名下拖了多久没跟进的学员。这些数字以前靠月底手工汇总，现在从流水里直接聚合——注意课时统计的口径要提前和机构定好（请假算不算教学量、调课算谁的），口径不一致，数字越自动越容易吵。
这几页搭配起来就是一套完整的闭环：学员进来 → 买课时套餐 → 排课 → 签到扣课时 → 剩余课时预警 → 续费或结业。
移动端：让家长、老师、前台各拿各的信息
培训机构的很多环节发生在教室门口和微信群里，所以移动端不是可选项。
家长查询（可选的做法）。 家长最关心两件事：还剩多少课时、下次什么时候上课。把这两件事放在手机上可查，能挡掉前台一大半的重复问答。如果再往前走一步，把请假申请也放到手机上，前台就不用在微信里翻"某某妈妈说今天不来"的消息了。
老师端。 老师上课当天在手机上完成签到、必要时发起调课，比课后回办公室补录靠谱得多。签到这个动作离现场越近，数据越真。
前台与顾问端。 招生时在手机上直接查学员、看余额、记跟进，不用等回工位开电脑。
这里的实现路径值得说明一句：在这套体系里，模块在电脑端构建完成后，移动端是伴随生成的，不是另做一套 App。也就是说排课页在电脑上是周视图看板，到了手机上会以适合手指操作的列表形态呈现；同一个学员台账，老师看到的是"我班上的学员"，前台看到的是"全部学员"，差别由权限决定，而不是维护两份数据。所以做这套系统时，不必一上来就把"要不要做 App"当成一个独立决策——先把页面和权限想清楚，移动端自然就跟着有了。## 上线前要定的几件事：定完再动手
课时台账最容易出问题的地方，不在页面做得好不好看，而在口径没定就上线。下面这几条是往上线前就该坐下来谈清楚的。
一、存量数据怎么搬进来。 机构一般都有一批在读学员和一本 Excel。搬的时候要注意：搬的不只是"学员+剩余课时"这一行数字，还要考虑这些余额和流水对不对得上。建议的做法是先把存量余额作为一笔"期初导入"写进流水，之后再发生的课消才有依据。系统的 Excel 导入能力可以把这张表一次性变成模块数据，但导入前先把表头对齐——列名不统一、日期格式混乱的表，导入成功率会明显低。
二、权限按角色切开。 至少三层：前台/教务看全部学员、老师只看自己带的班、顾问看自己名下的学员。有些机构还要加一层校区维度：多校区的机构不希望 A 校区的顾问看到 B 校区的学员名单。这套权限在平台的统一权限体系里配置，重点是不要让每个角色都能改剩余课时——数字一旦可以被随手改，可信度就没了。
三、课消与请假的规则。 请假到底扣不扣课时？临时缺勤和提前请假要不要区别对待？一节课按固定课时扣，还是按分钟折算？这些都是机构自己的生意逻辑，没有标准答案，但必须有唯一答案。系统层面它能被实现成"签到状态 → 自动决定是否生成课消流水"的一条规则，前提是这条规则先被人写清楚。
四、有效期怎么处理。 课程有有效期，过期了课时是作废、冻结，还是走一次延期审批？建议把延期做成一个审批动作留痕，免得事后家长有异议时说不清。
五、退费与转班怎么走。 这两个动作会同时影响课时余额和金额，属于敏感操作。建议接入平台的审批流：申请发起 → 负责人审批 → 审批通过后自动回写学员的套餐与余额状态。这样每一步都有谁批的、什么时候批的记录。
六、字段口径统一。 课程类型、来源渠道、请假原因这些下拉选项，用数据字典集中管起来。否则今天叫"体验课"、明天叫"试听"，年底一统计就发现数据分成了好几堆。
之后怎么延伸：从课时台账往外走一步
这套台账上线后，它天然是机构的中心数据源，可以按需往外延伸：
- 把续费提醒变成跟进任务。 预警清单上出现一个学员，就自动给负责顾问生成一条待办和日程，跟进结果回填。从"看到提醒"变成"有人负责"。
- 家长端再往前一步。 除了查余额和课表，还可以看孩子的上课记录与老师评价，把家长从"月底来查账"变成"随时能看到进展"。
- 多校区与组织架构。 校区、部门、老师归属用平台的组织骨架管理，报表按校区汇总，跨校区调学员也就有了归属依据。
- 收入与退费台账。 课消流水往前接一步就是收入确认，往后接一步是退费台账，和财务的应收应付能连起来。
- 转介绍与来源分析。 学员档案里的来源渠道是现成的，积累一段时间后就能看出哪个渠道来的学员留得久。
最后回到方法本身：这类系统不必一次做完。最务实的路径是先做学员台账 + 课消流水这两页，把"还剩多少课时"这件事做实；等前台用顺手了，再补排课、续费提醒和家长端。科目越少、规则越清楚，第一次上线就越稳。真正要花时间的不是拖控件，而是把机构自己那几条口径写下来——这件事，AI 替不了，但它能把你写下来的口径，变成一套从今天起自动算账的页面。