从每天要完成的任务画权限边界

舞蹈机构给员工配置系统账号时，先列清岗位每天实际做什么，再讨论需要看到和可以修改的内容。校长、教务、教师、前台与财务名称看起来清楚，但同一岗位在不同校区可能承担不同任务。拿具体课程、学员、收款或排班场景对照，通常比先套用一张通用角色表更能发现差异。

可把动作分成查看、新增、修改、删除、导出和审批几类。每类权限再对应数据范围，例如教师需要查看自己负责的班次，教务需要处理排课，财务需要核对相关交易。这里的矩阵是机构设计和验收工具，不代表某个产品一定支持每一项细分设置。

对每个任务问三个问题：员工是否需要完成它、依据什么确定对象、做完以后谁需要知道。若岗位只需看到一项结果，就不必默认给它更广范围的编辑权；若确实需要临时接手，说明代理条件和结束方式。具体权限边界由机构结合系统实际能力确认。

将门店范围、学员/顾客范围和操作动作分别记录，避免只写“教务权限”或“教师权限”。授权后的实际效果要用对应账号和样例任务检查；管理员能够打开某页，不足以证明普通员工拥有或不应拥有相同访问范围。

一个人一个账号，临时协作也保留责任

多人共用一个账号会让后续核对难以分清操作由谁完成。机构安排岗位账号时，可让每个员工使用本人账号，再按日常任务开通实际需要的范围。若工具或历史流程仍需共用登录，应先询问供应方有哪些可行的个人识别方式，不将聊天昵称当作可靠的操作归属。

员工短期代课、临时支援前台或跨校区协助时，先写出代理处理哪些任务、涉及哪些课程或记录、什么时候结束。不能只说“先帮忙看看”，否则代理人可能不知道可否修改、导出或代替负责人答复。权限不能确认时，交给有职责的管理人员处理。

临时授权结束后，核对代理人是否仍承担相关业务以及待办事项是否已交回。只把账号范围恢复原状但没有转交未处理课程变更，业务仍可能悬空；只完成口头交接但未检查登录范围，也可能让临时访问长期保留。账号状态和任务状态需要分别确认。

员工不在岗与离职是不同交接场景。代班期间要保证当天工作可以继续，长期离岗或离职则由机构负责人复核该员工仍需承担的事项和访问范围。不要让同事借用离职员工账号查询历史，按机构认可的管理入口查找业务记录。

权限表写清数据范围和例外情形

账号权限核对表可包括人员、岗位、所属门店、负责任务、允许操作、开始日期、临时结束条件、确认人和待办交接。字段不需追求复杂，重点是接手者看得懂为什么需要该范围，以及何时重新检查。没有理由的长期例外要被标记出来，交给负责人评估是否继续保留。

实际业务会有例外，例如教师临时替另一班、前台代录一项申请或负责人跨店查看进度。例外使用前先确认其范围和结束条件；用完后说明办到了哪一步、还欠谁处理。例外记录不应悄悄变成所有岗位永久可用的标准权限。

导出、批量修改和删除可能对业务影响较大，机构应把授权判断交给明确岗位，并在测试任务中确认操作范围。若系统没有提供需要的细分能力，别用文章中的表格假设已经实现；可以评估人工复核、职责分离或其他受控流程是否可行。

岗位调整后，应检查旧职责、新职责、尚未处理任务和当前账号范围是否对得上。职位名称变了但任务没变，未必需要重设全部权限；只改了岗位却没交接旧任务，也不能算完成账号交接。以实际工作内容为准逐条核对，保留需要后续处理的差异。

临时代课特别容易遇到“要让老师看到学员名单，但不想让他接管整间校区”的情形。负责人可将本次代理班次、查看需要、需要登记的结果和不应更改的事项写在一起，再通过当前系统允许的角色设置验证是否能做到。若只能整体开通一个宽角色，需明确由谁陪同核对，而不是假设范围已经被精细限制。

用虚构资料测试“该做的能做、不该做的做不到”

为新岗位或系统更改准备虚构学员与课程资料，先测该员工是否能完成岗位需要的任务，例如找到本人负责的一节课、查看已确认的调课结果或登记前台收到的事项。测试结果写清账号、数据样例、操作入口和实际返回，不以管理员现场演示替代。

也要测试边界：教师账号是否误见无关校区资料，前台是否能操作不在职责范围内的批量内容，离职账号是否仍能进入系统。出现意外访问或必要操作缺失时，先记录发生条件和实际画面，再由管理员或供应方判断如何处理，不自行修改后台安全设置。

测试时一次只改一项配置，按同一任务重新尝试，才知道变化解决了哪个问题。某个页面无法打开可能是账号权限、门店范围、资料状态或网络条件不同；不要从一次失败直接推断整个系统的数据安全。记录仍需查明的原因，由有权限人员继续确认。

测试结束后清理虚构资料并交回测试账号，核对实际业务账号未被临时加入无关角色。保留最短的测试结论：岗位需要的任务能否完成、边界检查有没有异常、待跟进事项由谁承接。这样下一次人员变动还能复用同一组任务检查。

入职、转岗和离职都要交代账号与业务

新员工入职时，负责人先依据实际岗位任务申请账号范围。员工从“看懂业务资料”开始培训，而不是拿管理员账号熟悉系统。培训完成后，用本人账号跑一次日常任务，确保他知道从哪里查、发现信息不全找谁，以及什么操作必须由负责人确认。

转岗交接既要检查新岗位需要增加什么，也要查看旧岗位权限是否仍有保留理由。员工从教务转为教师，不代表应该继续修改全部排课；从前台转财务，也不代表原先待处理的顾客沟通可以自动结束。逐项标注继续、收回或待决定。

人员离职时，指定管理人处理账号停用或访问范围变更，并另行安排未完成课程、顾客沟通、排班与结算事项的接手者。账号停用本身不能让业务记录消失，正常工作仍应由机构认可的入口和职责岗位延续。任何档案处理均按机构现行流程办理。

定期复查不必设成形式化打勾。可以在人员变化、跨店支援结束、岗位长期不再需要某类操作时触发检查。复查结果写出改变了什么、哪些待办仍由原责任人交接，避免既没有实际核对，又只留下“已完成”一条空记录。

账号测试由另一位管理人员复核结果更有帮助。执行人描述操作过程，复核人对照权限表看目标任务是否完成、边界是否符合机构的实际安排。一次测试只能证明这个账号在这条路径上的观察结果，不能推导整个产品没有其他访问入口，后续仍应按本店常用任务扩展检查。

选型时核验权限能力，不把模块名当作证明

企雀舞蹈公开资料列有顾客管理、连锁管理、预约、收银排班、进销存和数据分析等模块，可查看企雀舞蹈产品说明。门店如需按岗位细分查看、修改或导出范围，应带着角色矩阵和虚构测试账号现场演示，逐项核对结果。公开模块介绍本身不能替代权限颗粒度的实测。

演示时让普通教师、前台和教务人员分别操作自己的日常任务，再尝试机构明确不应由该岗位完成的项目；由实施人员说明能否设置、设置后怎样复查以及例外如何处理。若系统不能提供预期范围，明确记录人工替代措施与风险，不要将演示环境的特定设置写成所有版本都有。

企雀公开页面介绍舞蹈经营模块，但具体账号权限、导出限制和变更记录需要按实际方案核实。咨询时要求演示当前版本与本店门店结构相符的任务，确认使用者、范围和结果；功能暂不明确就标记为待答复，不将售前口头设想当成已确认能力。

最后把权限核对表交给一个明确负责人维护，并在新员工加入、校区变化、岗位代理结束时查看对应项目。管理工具可以帮助机构承载可核对的业务资料，授权决策、账号交接和复查责任仍由机构安排。只有“任务有人做、访问范围有人核、临时授权有人收回”，这份表才会成为日常经营的一部分。