多店经营里最容易被误认为“权限已经配好”的情形，是客服只能登录自己负责的店铺，却仍能导出全部店铺的客户名单。电商 CRM 的权限合规，不能只看角色名称或登录入口；还要分别核对员工能做什么、能看哪些数据、敏感操作如何受控，以及员工换岗或离职后权限是否及时变化。
角色权限回答的是“能做什么”，例如查看、编辑、删除、导出客户记录；数据范围回答的是“能对哪些对象做这些事”，例如仅能访问华东店客户，还是能查看所有店铺的数据。把两者混为一谈，是多店 CRM 权限配置中最常见的设计缺口。
一个账号即使被设为“客服”，也可能拥有全店铺客户的搜索权限；一个账号即使只能查看某店数据，也可能通过批量导出拿走大量客户信息。权限配置不能停留在角色名称上，必须分别验证操作权限与数据边界。
权限过宽会增加误操作和数据暴露风险；权限过窄则可能让客服无法处理售后、运营无法完成活动复盘，最后大家通过共享账号或线下传表绕过系统。有效配置应当让员工在明确的业务边界内完成工作，而不是以限制数量衡量安全程度。
我建议把权限目标写成可测试的句子。例如：“华东店客服可以查看本店订单关联客户的必要联系信息，可以登记服务记录，但不能批量导出客户资料，也不能修改其他店铺的客户标签。”这比“客服权限较低”更容易配置、复核和交接。
系统权限只是数据治理的一环。是否合规还取决于处理目的、数据类型、告知与授权、数据共享关系、保存期限、安全措施以及实际业务流程。配置了分店权限，不代表所有个人信息处理义务都已经履行；反过来，业务确有跨店服务需求，也不意味着必须机械地把数据完全隔离。
《中华人民共和国个人信息保护法》对个人信息处理者的安全保护义务、委托处理以及向其他处理者提供个人信息等情形作了规定。适用要求需要结合实际主体关系和处理场景判断。权限设置可以支持落实合理访问控制，但不能替代法律评估、制度建设或平台规则核验。
设想一家企业经营多个店铺，总部客服团队统一处理咨询，部分客服只负责某一店铺，另一些客服负责跨店售后。业务看起来相似，但两类员工的访问范围不同：前者需要看到本店相关订单和服务记录；后者可能需要在经授权的情况下查询多个店铺的数据。
如果系统只按“客服”建立一个角色，常见结果是所有客服获得同一套权限。为了让跨店客服工作，管理员把全局访问能力给了整个客服组；为了避免越权，店铺负责人又要求客服不要导出数据。结果可能出现“人人都能看，但没人知道谁需要看”的配置。
更稳妥的做法是把角色与数据范围拆开。例如，客服岗位可以有查看订单、登记服务记录等基础操作；再根据实际负责范围，将其数据限制在指定店铺或指定团队。跨店客服则单独定义授权条件，不因为少数人的特殊职责而放大所有客服的访问范围。
多店经营可能是同一经营主体管理多个店铺，也可能涉及不同经营主体、不同授权关系或外部服务团队。系统里显示的“店铺 A、店铺 B”只是业务标签，不必然说明数据法律关系、管理责任或共享依据相同。
因此，配置前应先问清楚：店铺由谁经营和管理？客户资料由谁决定处理目的和方式？总部团队是否代表店铺处理数据？第三方服务商是否接触数据？这些问题不能只靠 CRM 的组织架构解决，但会影响数据隔离、授权和管理流程的设计。
统一客户视图有利于识别重复咨询、连续售后和跨店服务；店铺隔离有利于缩小访问范围、减少无关人员接触客户信息。两者都不是绝对正确的答案，关键是业务是否确有共享需求、共享哪些字段、由谁访问、访问多久，以及是否有可核查的授权和操作记录。
如果业务只需要识别“该客户是否有未完成售后”，未必需要所有员工查看完整联系方式、历史订单和营销记录。可以先定义最少必要的信息，再确认系统是否支持按字段或业务对象限制。如果不支持字段级控制，就要评估能否通过角色、流程或数据处理方式降低暴露范围。
日常页面访问只是一个入口。客户导出、批量修改、共享链接、报表下载、API 接口、移动端、第三方应用授权和账号代登录，都可能形成额外的数据出口。只测试“客服看不到其他店铺的客户列表”，还不足以证明其他入口也受到了限制。
我会把权限检查拆成“页面内”和“页面外”两组。页面内关注搜索、查看、修改、删除和批量操作；页面外关注文件下载、接口授权、共享链接、应用连接、账号回收和历史文件存放。后者容易被忽略，却可能决定权限配置是否真正覆盖了数据流转路径。
“客服、运营、店长、管理员”是角色名称，不是完整权限方案。同一个客服角色可能负责单店咨询、跨店售后、投诉升级或夜班值守；岗位相同，数据范围和操作需要仍可能不同。
角色可以作为权限管理的起点，但不能成为唯一维度。至少要核对角色对应的菜单和操作、可访问的数据范围、敏感动作限制，以及是否有超出日常职责的临时授权。若系统无法细分，应该明确这项产品限制，再通过岗位分组、审批流程或替代控制补足。
店铺可见范围与导出权限通常是不同控制点。某用户可能只能在页面查看指定店铺，但拥有报表导出或接口查询能力；也可能能导出经过汇总的数据，却无法导出客户明细。不能仅凭“已按店铺隔离”推断导出路径也遵循相同边界。
测试时应使用受控账号，分别检查页面查询、筛选条件、分页、批量操作、导出、报表下载和接口调用。需要确认的不只是“按钮能不能点”，还包括导出的记录范围、字段内容、文件保存位置和后续共享方式。
只读权限可以减少误修改，却未必减少信息暴露。员工能够查看客户信息、截图、复制或下载时，数据仍可能离开系统。对于确需执行服务任务的岗位，机械地改为只读还会促使团队使用私人表格、共享账号或线下传递资料，带来新的风险。
合理的原则不是一味减少功能，而是让每类岗位获得完成任务所需的最小权限，并为高影响动作增加限制。查看权限本身也要按需要控制，不能因为没有编辑权就默认没有数据风险。
管理员通常可以改变角色、组织、数据范围或集成配置，影响面远大于普通业务账号。把管理员权限长期交给一个个人账号，既可能造成单点依赖，也容易让关键变更缺少复核。
企业可根据规模和系统能力考虑管理员账号分工、强认证、变更记录和定期复核。并非每家企业都需要复杂的双人审批，但至少要能回答：谁有权新增管理员？管理员离职或换岗时谁接手？权限变更是否留有记录？紧急情况下是否有可控的恢复路径？
“系统有日志”不是充分结论。日志可能只记录登录时间，不记录客户导出；可能显示操作人和时间，却没有数据范围；也可能存在保存期限、查询权限或日志导出能力限制。审计能力必须核实具体覆盖哪些事件、保留多久、由谁查看，以及记录是否能支持内部调查。
如果系统日志不覆盖某些重要操作，可以通过审批单、导出登记、集成平台记录或内部流程补充。但需要明确，人工登记的完整性和真实性需要另行管理，不能把“有一张登记表”当成技术日志的等价替代。
| 常见说法 | 实际需要核验 | 更稳妥的判断方式 |
|---|---|---|
| 客服只能看本店 | 搜索、报表、导出、接口是否也限制在本店范围 | 用测试账号从多个入口验证记录范围 |
| 员工没有编辑权 | 是否仍能查看、复制、截图或下载敏感信息 | 按任务需要同时评估查看范围与操作范围 |
| 管理员很少使用 | 管理员账号数量、日常使用情况及变更记录 | 定期核对有效账号，并明确紧急授权流程 |
| 离职账号已经停用 | API令牌、第三方授权、共享文件和下载副本是否仍有效 | 离职清单同时覆盖账号、连接和已导出数据 |
我不建议一开始就问“CRM 支持几级权限”，而会先画出店铺、团队、总部职能和外部服务方之间的关系。至少要区分三种模式：店铺各自管理、总部集中管理、总部统一运营但员工按店铺分工。
店铺各自管理时，默认目标通常是限制跨店访问；总部集中管理时，管理者可能需要汇总查看，但不意味着所有员工都应查看明细；统一运营但分工明确时，适合在共享服务岗位和店铺岗位之间设置不同数据范围。最终方案取决于业务必要性和数据关系，不应把“全部共享”或“全部隔离”当作通用答案。
为了让配置可执行，可以把需求整理为五类清单：用户与岗位、店铺与组织、数据对象、操作动作、例外授权。角色表仍有用，但要与这些清单相互对应，避免出现角色命名完整、实际边界模糊的情况。
一张可复核的权限矩阵，至少要写出谁、对什么数据、能执行什么动作。必要时再增加是否可导出、是否需要审批、是否需要留痕、授权有效期等字段。
| 岗位示例 | 建议核对的数据范围 | 日常动作示例 | 额外检查项 |
|---|---|---|---|
| 单店客服 | 负责店铺内与服务任务相关的记录 | 查询、登记服务记录、更新受限字段 | 跨店搜索、批量导出、敏感字段可见性 |
| 跨店售后支持 | 经授权的多个店铺或指定售后队列 | 查询售后状态、补充处理结果 | 授权范围、有效期限、是否能访问无关客户信息 |
| 店铺运营 | 负责店铺的活动、客户运营或汇总报表 | 查看活动数据、维护标签或执行运营动作 | 客户明细是否必要、报表能否下载、导出字段范围 |
| 财务人员 | 与结算、退款或对账任务相关的数据 | 查询核对信息、生成业务报表 | 是否需要客户联系信息、退款类操作是否分权 |
| 系统管理员 | 按系统维护职责确定，不默认开放全部业务数据 | 账号、角色、集成与基础配置管理 | 管理员变更、临时授权、日志覆盖和复核责任 |
表格中的权限只是设计示例，不是所有企业都适用的标准。每个岗位实际需要查看和处理什么，应由业务负责人确认；CRM 能否配置到所需粒度，则需要通过产品文档、后台实测或供应商确认。
查看一条订单记录与导出全部客户资料，影响范围不同；修改服务备注与批量删除客户，恢复难度也不同。配置时应识别影响面大、撤销成本高、容易绕过日常流程的操作，并结合系统能力设置额外控制。
重点核对客户信息导出、批量修改或删除、账号与权限管理、退款或订单关键字段变更、接口令牌管理，以及共享报表下载。若系统支持审批、二次确认、操作记录或按字段限制，可以评估是否启用；若不支持，则要判断能否通过岗位分工、人工复核或更严格的导出流程补足。
临时支援、促销高峰、投诉升级和系统排障，都会产生临时访问需求。若直接把临时任务变成长期角色，很容易造成权限逐年累积。建议记录授权原因、涉及店铺、允许操作、审批责任人和截止时间，并在任务完成后确认权限已撤回。
如果目标系统无法设置自动到期，可以在内部权限台账中设定复核日期，并由责任人主动回收。重点不是流程一定复杂，而是临时授权不能因为“以后可能还用得到”而无人负责。
下面使用一个明确标注的情景模拟，不代表真实客户数据或行业平均水平。假设一家电商企业经营四个店铺，拥有二十名客服、八名运营人员和两名系统管理员。客服中十六人固定服务单店，四人负责跨店售后；管理团队需要查看店铺经营汇总，但不一定需要查看所有客户明细。
这类结构的关键矛盾不是“要不要共享”，而是“哪些岗位因为什么任务需要跨店访问”。如果直接给全体客服开放四店数据，跨店服务需求虽然解决了，单店客服的访问范围却被扩大；如果完全隔离，跨店售后又可能无法及时确认历史服务。
在这个模拟场景中，可以先把工作拆成三种：单店日常客服、跨店售后支持、总部经营分析。单店客服只处理本店任务；跨店支持人员按售后队列访问获批店铺；经营分析人员优先查看汇总指标，确需查看明细时再说明业务原因。
如果跨店售后只需要知道历史问题是否已处理，可能无需开放完整营销标签和全部客户资料。把共享范围压缩到任务所需的信息，是比“给跨店人员一个全局管理员角色”更精细的设计思路。具体能否做到字段级控制，必须以实际 CRM 的功能为准。
建议准备不同角色的测试账号，建立正向和反向用例。正向用例验证员工能否完成本职任务；反向用例验证员工能否访问无关店铺、导出超范围数据、创建共享链接或调用未授权接口。仅检查菜单是否隐藏，不能替代数据结果验证。
下表仍为情景模拟，目的是展示如何记录测试，不是任何产品的实测结果。实际检查时，应写入测试时间、系统环境、账号角色、操作步骤、预期结果、实际结果和整改责任人。
| 测试场景 | 预期结果 | 常见失败信号 | 后续动作 |
|---|---|---|---|
| 单店客服搜索其他店铺客户 | 无法查看不负责店铺的记录，或仅显示被批准共享的必要信息 | 搜索结果出现其他店铺客户，或可通过更换筛选条件访问 | 重新核对数据范围、搜索权限和跨店归属配置 |
| 单店客服导出客户清单 | 导出功能不可用，或导出范围和字段符合岗位授权 | 可导出全量数据，或导出字段超过任务需要 | 核实独立导出权限、报表范围和替代流程 |
| 跨店售后人员查找历史工单 | 可访问授权店铺内与售后任务相关的信息 | 只能全局查看，无法按任务限制范围 | 评估队列分组、临时授权或人工协作等补偿方式 |
| 离职账号对应的接口令牌调用 | 账号停用后，相关授权按流程复核并撤销 | 旧令牌仍可请求数据，或无法确认令牌归属 | 盘点应用授权、令牌责任人和撤销机制 |
多店企业有时会把 CRM 客户数据、订单数据和经营报表连接起来分析。若采用数据分析平台，权限检查不能只停留在 CRM：还要核对数据如何进入分析环境、分析账号能看哪些表或字段、报表分享给谁，以及导出文件如何保存。
例如，企业可以将九数云作为经营数据分析环节的候选工具进行评估，但不应据此推断其具备某种 CRM 角色权限、字段级隔离或特定审计能力。接入前应以官方产品说明和实际测试为准，明确数据源授权、可同步字段、账号范围、报表分享和数据撤回流程。相关信息可从九数云官网核实。
数据分析平台的价值在于支持经营数据整理与分析，不能自动替代 CRM 内部的访问控制，也不能因为数据已经汇总就默认不存在个人信息或商业敏感信息。若报表只需店铺级汇总，优先评估是否可以使用汇总结果；若必须使用客户级明细，则应进一步核对必要性和授权边界。
店铺数量少、岗位分工简单时，不必一开始就建设复杂的审批体系，但要先明确每个账号的负责人、店铺范围和敏感操作。至少避免共享个人账号，避免所有业务人员共用管理员账号，并确认导出和第三方连接由谁管理。
如果 CRM 产品暂不支持细粒度范围控制，先限制实际接触敏感数据的人员，并通过流程管理高风险导出。要把产品限制记录下来，而不是把“暂时没法配置”误当作风险已经解决。
总部需要掌握经营情况，不代表管理者每次都需要查看客户级明细。可以先确认管理报表的决策需求，再判断汇总到店铺、活动或商品层级是否足够；只有业务目的确实要求明细时，再指定访问角色和审批责任。
同一岗位可能需要访问多个店铺，但仍可按区域、品牌线、业务单元或工作队列分组。设计时重点检查跨组调阅是否有业务理由，人员换岗后分组是否同步更新，以及报表是否通过共享链接暴露给更广泛的人群。
跨店团队的权限通常比单店岗位复杂。建议把常规任务与升级任务区分开：常规任务只访问固定队列；投诉升级、重大售后等特殊任务，再由授权人员临时扩大访问范围。若产品无法设置临时权限，至少应采用明确的名单、期限和复核机制。
共享团队也需要与店铺负责人约定数据使用边界。谁提出共享需求、谁确认必要性、谁批准范围、谁定期检查，都应有明确责任人。否则“总部统一运营”容易变成没有边界的全员可见。
每增加一个报表工具、服务商、应用或接口，都应重新绘制数据流向。需要核对数据源由谁授权、同步哪些对象与字段、外部账号能否下载、授权结束后如何撤回，以及相关文件是否会留存在个人设备或共享空间。
如果服务商代表企业处理个人信息，企业应按实际关系核对委托处理安排和安全管理要求；若属于向其他处理者提供信息或其他数据共享情形，应结合具体业务关系评估适用规则。此类判断不能仅凭软件名称、合同标题或接口连接方式得出。
以下是一种可根据团队规模调整的示意排期，不是行业标准。小团队可以在数天内完成，复杂组织可能需要更长时间。关键是每一步有负责人和可交付结果。
| 阶段 | 建议安排 | 交付结果 |
|---|---|---|
| 业务盘点 | 第1，2天 | 岗位、店铺关系、共享场景和数据对象清单 |
| 权限设计 | 第3天 | 岗位，数据范围，操作动作矩阵及例外授权规则 |
| 系统配置 | 第4，5天 | 测试环境或正式环境中的角色、范围和敏感操作设置 |
| 权限验收 | 第6天 | 正向与越权测试记录、问题清单和整改责任人 |
| 复测与交接 | 第7天 | 复测结果、权限负责人、后续复核时间和离职处理流程 |
如果无法按期完成，不应把未验证的权限配置直接标记为“已合规”。可以先限制高风险操作或缩小账号范围，并把未完成的测试列为待办，明确责任人和完成时间。
按店铺隔离适合团队分别运营、数据共享需求少，或店铺之间需要明确区分管理责任的场景。它可以减少无关员工访问其他店铺数据的机会，也更容易解释岗位的访问范围。
代价是跨店售后、客户重复识别和总部分析可能需要额外流程。若业务确有共享需要，应设计受控的共享入口，而不是让员工借用全局账号解决问题。需要确认 CRM 是否支持按店铺限制查询、导出和报表范围，并测试各入口是否一致。
总部集中查看适合需要统一运营、跨店服务或集团化经营分析的团队。汇总视图有助于减少多个系统间重复整理，但集中并不必然意味着所有总部人员都要接触客户明细。
可以把访问分成汇总指标、业务明细和客户级信息三层，分别确认哪些岗位需要什么粒度。若系统支持按报表、字段或数据集配置权限，可在实测后采用；若不支持，就要考虑数据处理替代方案或缩小账号范围。
角色模板适合岗位稳定、业务规则相对标准的团队，也便于新员工快速开通权限。但角色一旦与数据范围绑定得过于宽泛，模板复制会把历史问题带到更多店铺和人员身上。
更稳妥的方式是统一基础操作权限，再按店铺、团队或任务配置数据范围。每次复制角色前，检查模板是否包含管理员、导出、批量操作和跨店访问等高影响能力。模板需要定期复核，不能因为名字没有变化就默认内容仍然适用。
当 CRM 不支持临时授权、导出审批或字段级限制时，人工流程可以在短期内补足部分控制，例如规定敏感导出需负责人批准、记录用途和范围。但人工流程依赖人员执行，容易漏记、延迟或在业务高峰时被绕开。
因此，人工控制需要有明确表单或记录、审批责任人、复核频率和例外处理方式。随着业务复杂度增加，应重新评估系统能力、替代工具和流程成本。不要让临时补丁长期存在，却没有明确的风险接受人。
权限文章最容易出现的表达错误，是把建议写成法定义务，或把某个 CRM 的功能说成行业通用能力。讨论个人信息保护时，应区分法律条文的适用条件、企业内部制度要求和具体产品能够提供的控制手段。
涉及个人信息处理、委托处理、向其他处理者提供信息、数据安全措施等内容时，应以现行法规和企业实际业务关系为依据。平台账号与接口规则应查对应电商平台的官方规则；产品功能应查目标 CRM 的文档并实际验证。若业务涉及多个主体或复杂数据流，建议由法务、隐私或安全负责人参与确认。
权限需要跟随人员、店铺和业务变化。新店上线、组织调整、员工调岗、外包服务变化、系统集成增加或客户运营模式改变，都可能让旧配置失效。复核频率可以根据风险和业务变化确定，不需要机械套用某个固定周期。
对于高权限账号、客户信息导出权限、接口授权和外部应用连接，可设置更明确的复核责任。日常岗位权限则可结合入职、调岗和离职流程检查。复核记录至少应能说明检查范围、发现问题、处理结果和未解决事项。
停用 CRM 登录账号是重要动作，但还要检查账号关联的 API 令牌、第三方授权、共享报表、云端文件和业务交接资料。若员工曾使用个人邮箱或设备接收导出文件，账号停用并不会自动删除这些副本。
离职清单应根据企业实际工具链调整，并明确哪些工作由人力资源、业务负责人、系统管理员或安全负责人完成。重点不是把所有数据都做不现实的“远程清除”，而是识别仍有效的授权和可控的数据副本，及时撤回或按制度处理。
权限项目可以记录账号盘点完成率、跨店越权测试通过率、离职授权按期回收率、敏感导出审批留痕率和未关闭问题数量等指标。这些是企业内部管理指标，不是行业统一标准。统计时要定义分母、时间范围和通过条件，避免只报一个百分比却无法解释。
例如，“越权测试通过率”应说明测试了多少个角色、多少条路径，以及哪些路径算通过；“离职授权回收率”应明确统计账号、令牌和第三方连接中的哪些项目。指标的价值在于暴露遗漏和推动整改，不是制造一个看起来漂亮的合规分数。
多店 CRM 权限真正可用的标志，不是后台里出现了几个角色，也不是权限菜单全部填满，而是员工可以完成必要工作、无关数据受到合理限制、敏感操作有相应控制，并且配置变化可以追踪和复核。
下一步可以从一张权限矩阵开始：先列岗位、店铺、数据对象和操作动作，再挑选客服、运营、管理员等代表账号做正向与越权测试。发现系统能力不足时，明确缺口、风险和临时补偿措施，不要把未经验证的状态描述成已经合规。
最值得坚持的判断是：多店权限不是把所有店铺锁起来，也不是把所有数据集中起来，而是让每一次访问都能对应到明确的业务理由。当角色、数据范围、敏感动作和授权生命周期分别说得清、测得到、复核得了，权限配置才从后台设置变成真正可执行的经营边界。
我在给同时经营多个店铺的团队梳理 CRM 权限时，发现系统里已经有客服、运营、管理员等角色，但员工仍可能看到不该看的店铺数据。我不确定是角色设置不够细，还是还需要单独配置店铺范围。
两者都要配置：角色回答“能做什么”，数据范围回答“能看哪些店铺和记录”。只设角色不设范围，客服可能有了正确的操作权限，却仍能查看全部店铺的客户；只设店铺范围不设角色，则可能限制了数据，却没有限制导出或修改。建议先按实际业务确定店铺关系，再配置角色和数据范围。
例如，店铺客服只处理分配给自己的店铺，总部运营查看多个店铺的汇总数据，财务只查看履职所需的订单信息。具体能否按店铺、团队、个人或字段控制，要以 CRM 实际功能为准。
我不想只看后台显示的权限开关，就认定设置已经生效。尤其是搜索、批量导出和跨店切换这些入口，我担心员工可能通过不明显的操作路径看到其他店铺的客户信息。
不要只检查配置页面，最好用不同角色的测试账号走一遍真实操作路径。每个场景记录“预期结果”和“实际结果”，重点测试店铺切换、客户搜索、订单查看、批量查询、导出、共享链接及接口访问；系统不支持的测试项，也要明确标记为待核实。
可先做一张简化测试表： 测试角色目标店铺查看其他店铺导出客户 店铺客服可查看应拒绝按职责限制 总部运营按授权查看按授权决定单独核验 测试结果应留存账号、时间、操作路径和问题处理记录，避免只凭“权限已开启”判断配置有效。
我在整理员工权限时，发现“查看订单”和“导出客户”看起来都是数据访问，但影响可能很不一样。我想知道除了导出，还有哪些操作容易被普通角色默认开放，却需要结合岗位额外检查。
优先盘点可能造成大量数据外流、误改或难以恢复的操作，例如客户信息导出、批量修改或删除、账号与角色管理、接口授权，以及订单或售后信息的关键变更。它们不一定都要一律禁止，而应按岗位职责、业务流程和系统能力决定是否收紧、审批或留痕。
判断时可问三件事：操作影响多少记录，发生错误后能否恢复，事后能否查明是谁在何时操作。若 CRM 没有单独的导出审批或操作日志，可通过内部流程补充授权、复核和记录；不要把产品具备日志功能，直接等同于审计已经充分。
我原以为把员工权限按店铺分开，就基本完成了多店数据管理，但团队还有客户共享、外部服务商接入和员工调岗等情况。我不确定系统权限能覆盖到什么程度，哪些事项还需要结合业务流程另行确认。
权限设置是数据治理的一部分，不等于完成全部合规义务。应先梳理客户信息由谁收集、谁使用、是否在店铺或团队间共享，以及外部服务商是否能接触数据，再根据实际业务关系核对适用的法律要求、平台规则和企业制度；涉及具体法律结论时，应以现行规定及专业意见为准。
还要把权限管理放进员工生命周期：入职按职责授权，调岗时复核原有店铺和数据范围，离职时及时停用账号并检查关联账号、接口或共享权限。建议记录复核负责人、日期和处理结果，并在店铺、岗位或业务流程变化时重新检查，而不是只在上线当天确认一次。
读者评论
把角色权限和数据范围分开核对很实用，尤其是客服只能看本店页面、却能导出全店数据这种容易遗漏的情况。
文中没有把多店数据一概要求隔离，而是先看主体关系和实际业务需要，这个判断顺序比较稳妥。
离职停用账号不等于撤销所有访问，API令牌、第三方授权和已导出文件也纳入检查，值得作为交接清单的一部分。