千悦客服子账号管理，多门店多团队权限隔离

子账号管理解决的是不同员工以各自身份开展工作，权限隔离解决的是他们能看到和处理哪些数据。千悦已有成员、角色和客服分组相关能力，但多门店是否需要独立商户、共享组织或某种专属结构，不能只靠新建几个子账号决定。应先把门店之间能共享什么、不能共享什么说明白。

组织结构要映射到资料范围

总部有时需要汇总业务，门店员工只需要处理本店事项，跨店支援人员则有时获得有限的临时范围。客户、会话、附件、工单和报表都应分别检查，不能只隐藏菜单就认为已隔离。员工调岗时，应更新实际权限和未完成任务归属，而不仅是改变显示的门店名称。

从组织职责画出三种视角

门店接待人员需要处理本店任务，区域负责人有时需要协调多店资源，总部管理人员则有时关注整体服务情况。这是一种职责示例，实际组织结构可以不同。应先画清谁对哪些业务负责，再讨论系统的账号、角色、分组或租户设置如何承载。

统一品牌并不意味着所有资料都应全员共享，分成多个门店列表也不等于已经实现严格隔离。界面筛选主要帮助定位，权限控制决定谁能访问或操作，而不同租户通常还涉及更独立的业务边界。选型时应明确需要哪种效果。

跨门店支援怎样安排权限

客户在甲店咨询、后来到乙店服务时，两店是否能共享资料取决于企业规则和授权。若需要转交，应明确转交范围及负责人；若不允许共享，就应在各自范围内继续处理。不能仅因联系方式相同，就把所有门店的历史沟通向每位员工开放。

客户从甲店转到乙店

例如，客户原先向甲店咨询，后来希望由乙店提供服务。团队需要确认哪些信息应随任务交接，谁继续联系客户，以及乙店能否查看必要的历史说明。不能只把客户姓名复制到乙店列表，就假定原事项已经有人接手。

如果企业规则不允许直接共享完整历史，可以由有权限的人员整理必要摘要，或者采用明确授权的协作方式。这个业务场景强调业务交接与访问边界需要一起设计，而不是在方便与隔离之间随意切换。

对四类对象分别检查

还要检查搜索与详情入口。有时列表只展示本店内容，但其他路径有时仍能访问不相关记录。验收不能只停留在菜单或默认筛选结果，应使用不同身份实际操作，并确认拒绝结果清楚且一致。

员工调岗与门店变化是常见边界

员工从甲店转到乙店后，需要增加新岗位所需权限，同时检查旧门店权限是否仍应保留。未完成事项应明确交给谁，历史责任信息则不应因人员调动被抹去。临时支援结束时，也需要恢复约定范围。

门店新开、合并或停止运营时，应提前讨论客户资料、渠道账号和历史记录如何处理。不要只复制一个现有门店配置，再长期保留不必要的共享权限。组织结构变化应成为一次权限复查的触发点。

试点要包含跨店和越权情形

可以用两家测试门店和不同角色，分别完成正常接待、跨店协助、主管查看与无权访问。观察客户是否被重复建档、负责人是否明确、报表口径是否符合约定。若某项组织层级或隔离方式不在当前产品范围内，应据此调整方案，而不是用隐藏菜单代替。

多门店客服的目标，是让各门店有清楚的服务责任，同时让必要协作能够进行。选择千悦客服方案时，最终需要的是一份经过实际验证的数据范围与协作说明，而不只是“支持多账号”的概括。

先确定门店与团队之间的数据边界，再配置各自成员与服务分组。通过具体岗位任务验证可见范围和交接权限，让人员变化后职责依然清楚。