准备给茶室、棋牌室上管理系统，演示时开台、加点、结账都很顺，老板仍应多问一句：刚才用的是管理员，还是普通店员账号？如果只看负责人操作，很难判断员工日常使用时，哪些事能自己做，哪些事需要授权。本文只解决这个选型与交付问题，不评价某款产品已经具备哪些权限功能。

一、先列动作，不要只写“店员权限”

建议把接待开台、录入商品、查看本班订单列为日常动作候选；把临时改价、赠送时长、取消已消费项目列为需要单独讨论的动作。不是所有门店都要照同一张表设置，而是老板先决定谁负责什么，再请服务方逐项说明能否实现。

尤其要拆开“查看”和“修改”。店员为解释账单可能需要查看消费明细，但这不代表必须能调整原价；能给当前包间加点，也不意味着应当查看其他门店的数据。把允许范围写到岗位、门店和具体动作，比一句“给普通权限”更容易验收。

例如，假设门店约定接待员可以开台、加点，临时减价交给当班负责人。应把这条约定作为测试前提，而不是听到系统有“角色管理”就认定已经符合。该例是假设分工，不是产品功能说明或客户案例。

二、用普通账号走一遍正常工作

请服务方在授权演示或培训环境准备测试包间和测试账号，由店员按自己日常顺序操作：找到可用包间、开台、录入一项消费，再查看待结账明细。每一步记录能否完成，以及是否需要借用管理员账号。

如果正常录单也被拦住，先核对岗位配置，不要为了演示顺利直接把全部权限打开。反过来，能够开台也不代表交付结束，还要看操作对象是否限于门店约定范围。需要了解房间可用状态的，可以结合包间待清洁与可用核对指南检查，避免把房态问题误判成账号问题。

这一步的通过条件应是：约定允许的工作能由对应岗位独立完成，且无需共用负责人密码。实际系统是否满足、需要哪个模块，应写进交付记录，不能由本文代替验证。

三、再试一次不允许的改动

保持普通测试账号登录，选择刚才的模拟账单，尝试门店明确不允许的改价或取消操作。预期是被拦截，或进入门店认可的授权流程；不能只看按钮有没有隐藏，还应确认操作后账单确实没有被擅自改变。

随后由负责人演示正常授权路径。如果当前版本没有单次授权功能，就让服务方说明替代操作：例如是否需要负责人切换自己的账号完成，再退出。不要把“支持权限”自动理解成支持手机审批、金额阈值或远程授权，这些能力都需要另行核实。

授权结束后再回到普通账号，检查权限是否仍符合原约定。如果一次授权之后，后续账单也能任意改动，就需要重新核对授权范围。以上是验收设计，并非认定任何现用系统存在漏洞；只能在授权环境测试，不尝试绕过系统限制。

四、回查记录，才能把责任说清楚

对那次已获授权的模拟变更，要求演示如何找到订单、操作时间、操作者及变更前后内容；如有审批，还要看审批与执行能否对应。缺少哪项就如实记录，再判断是否满足门店管理需要，不把一行“操作成功”当成完整追溯证据。

交付记录可以固定为四项：测试前提、执行动作、预期结果、实际结果。实际结果未演示就写“未验证”，不要填写“默认支持”。同时明确记录由谁查看、能查多久、是否涉及额外模块或费用；没有正式资料时，不猜测保存期限和价格。

如果是已经发生的真实错账或争议，不应在原订单上反复试按钮。先保留现有记录，通过正式售后核对。本篇未取得具体版本手册或授权演示账号，未做功能实测。

五、店主常问的三个问题

小店只有两个人，还需要分账号吗？

建议仍按实际操作者区分账号，方便回查。权限可以简化，但别为了省一次登录，让所有变更都只显示同一个人。是否支持独立账号及数量限制，需要核对拟用版本。

老板不在店，员工急着改价怎么办？

先约定谁能接手、哪些事项必须等待、怎样告知顾客；再核实系统能否支持这套分工。不要预先承诺远程审批，也不要把老板密码留在前台当应急方案。

做完演示就能上线了吗？

还应把角色配置、操作交接和未验证项目写清楚。上线由谁配置、培训谁、异常找谁，需要在交付方案中明确。权限验收只是上线准备的一部分，并不保证系统适合所有业态。