同一位学员，关联不同业务记录
可把客户、商机、课程与报名分别建模，用稳定标识建立关联。报名记录保留对应身份、价格和权益，避免以后修改产品规则时，历史报名失去依据。
招生、报名和学员服务涉及多个岗位。已有项目把票种权益、签到、学分和权限等规则放进定制系统。
业务问题
招生、报名、权益、签到与财务核销涉及多个岗位，业务规则复杂，团队需要反复核对信息。
CASE STUDY / 商学教育与企业培训把招生、报名与学员服务，
把招生、报名与学员服务，
放进同一套系统。
将复杂的客户跟进、课程报名、票种权益、签到和学分规则做进业务系统，支持不同岗位围绕同一套记录工作。
服务方式业务规则梳理 · CRM 定制 · 多端开发项目背景
某面向企业经营者的培训机构，开展课程招生、学员服务与持续运营。
01 / PROJECT STORY
培训业务的规则，远不止一张报名表。
02 / PROJECT STORY
先明确业务事实，再设计不同岗位的操作。
服务范围包含业务规则梳理、CRM 定制与多端开发。系统需要让客户跟进、课程报名和后续服务能够相互核对。
现场判断
把业务事实与操作规则统一，明确不同岗位的工作入口与数据权限。
提供的服务
定制管理后台、学员端及销售相关功能，建设客户与商机、课程报名、票券、签到、学分和权限体系。
03 / PROJECT STORY
技术方案解读
结合学员数据模型、关系约束和权限控制的公开设计，说明同类培训系统怎样处理复杂规则。
票券和权益按规则处理
票种、转让、退费等规则需由业务先确认，再做进系统。可用明确状态表示已报名、待使用和已核销，并对重复操作做一致性检查，减少一张票被重复处理的风险。
销售、运营与财务各有入口
按岗位配置可查看的记录与可执行的操作，涉及价格调整、核销等动作在服务端检查权限。操作记录说明谁在何时改变了什么，便于业务核对。
参课记录与学分相互关联
可将签到和参课记录关联到实际课程，再按确认的规则处理学分。财务核销与教学记录保持各自口径，不能用一次签到直接替代所有权益或收款确认。
04 / PROJECT STORY
一位学员，从意向到参课的记录。
下面使用虚构学员和课程说明业务关系，具体票种与权益由机构规则决定。
销售跟进
示例学员 A 的课程意向进入客户记录，销售保留跟进情况。
确认报名
按示例课程和票种确认报名，将当次价格与适用权益保留在记录中。
到课核验
运营按有效报名核验票券并记录签到，重复提交需要检查原记录。
后续服务
参课、学分和核销信息各有依据，相关岗位按权限继续处理学员服务。
虚构业务示例，仅用于解释处理思路，不包含真实客户数据，不代表已交付的全部功能。
05 / PROJECT STORY
哪些核对可以交给系统。
下面比较行业常见处理方式与设计建议，不把建议中的细节默认认定为全部已交付。
| 业务环节 | 常见处理方式 | 方案设计建议 |
|---|---|---|
| 跨岗位核对 | 销售、运营和财务分别维护表格 | 通过关联记录查到同一笔报名的身份与权益 |
| 规则变更 | 修改规则后难以解释历史价格 | 当次报名保留适用规则和价格依据 |
| 票券处理 | 靠人工判断是否已核销 | 检查票券状态与重复操作，保留处理记录 |
06 / PROJECT STORY
规则梳理与多端验证，一起推进。
同类项目可以用正常流程和例外样本共同验证，避免只测试一次顺利报名。
- 01
核对业务规则
把身份、价格、票种和权益规则写清，收集改报、重复报名等实际例外。
- 02
确定记录与权限
设计客户到参课的关联关系，明确各岗位能看什么、改什么和需要谁确认。
- 03
多端联调
管理端、学员端与销售相关入口共同验证报名和签到，核对同一条业务记录。
- 04
验证例外与交接
以业务样本检查核销、权限与重复操作，再交接规则说明及日常使用方法。
07 / PROJECT STORY
复杂业务系统，需要检查例外。
验收重点包括历史规则、重复操作与岗位权限，报名成功只是其中一步。
历史报名能否解释清楚
核对不同身份和票种的价格与权益，新规则不能无说明地改变历史记录。
重复操作会不会产生重复事实
用重复报名、重复签到和重复核销样本检查一致性，异常处理有明确反馈。
权限是否在服务端生效
验证不同岗位和不同记录的访问限制，不能只隐藏按钮却允许越权操作。
业务与财务口径能否核对
区分报名、到课和收款事实，确认报表各自统计范围。本案例不公布未经确认的成交提升数字。
08 / PROJECT STORY
各岗位围绕同一套业务记录开展工作。
已有交付让客户跟进、报名、票券和学员服务有共同记录可查，减少交接歧义。更多效果数据需在真实使用中统计。
项目价值
报名身份、价格与权益有记录可查，各岗位围绕同一套事实工作，减少跨表核对与交接歧义。
09 / PROJECT STORY
公开数据与权限设计参考
以下资料用于解释设计原则，不表示采用对应厂商产品，也不表示与厂商合作。
- Salesforce 学员数据与教育应用模型
参考学员、报名和学习进程的统一关联。
- PostgreSQL 数据约束设计
参考稳定标识、关联完整性和重复数据约束。
- OWASP 业务授权设计
参考默认拒绝和每次请求的权限验证。
RELATED / 相关能力
把同类问题，接着往下做。
