全文速览：把交接拆成员工离职和团队扩张两个场景分别走完：离职者当天彻底失去访问权、公司不必逐个改密码，新人按角色拿到最小够用的权限，每个店铺的运行环境在交接中保持不变，全程可追溯。一次完整交接通常半天内能收尾。

交接前，先把这五样东西盘点清楚

交接出事，多数是因为还没弄清”现在是什么状态”就开始动。在做任何撤权或加人之前，先把下面五样盘点成一张清单。

盘点不清就开始交接，几乎必然漏项——最常见的就是漏掉某个共享邮箱、或某个还绑在离职员工手机上的验证器。

交接前要先确认一件事：账号控制权在不在公司手里

开始任何交接之前，先确认一个前提：店铺账号的最终控制权，是不是握在公司的主账号/主体名下，而不是挂在某个员工的个人账号下面。

这一条决定了交接的难度。如果账号一直由员工个人持有密码、个人管理，那交接本质上是把对方手里的东西要回来，风险高、容易扯皮；如果账号从一开始就由公司主体集中管理、员工只是被授予访问权，那交接就只是调整一下谁有权访问，干净利落。

确认控制权归属之后，再往下走分场景的步骤。

员工离职时，按这个顺序交接

离职交接的顺序不能乱，撤权要在最前面。下面每一步都给出操作、怎么验证、以及最容易出错的地方。

第一步：立即撤掉这名员工的访问权限

操作：在权限管理里关闭该员工的登录、移除其角色，而不是只改密码。

验证：让对方（或你自己用其账号）尝试登录，确认确实进不去。

易错：员工离职后最该处理的不是密码，是访问权限和登录态——只改密码、不撤权限或不清登录态，对方照样可能从浏览器残留的登录状态进去。

第二步：处理密码与登录态

操作：如果密码在使用期间对该员工可见过，逐一更换涉及的账号密码；同时清掉其设备上残留的登录态（Cookie）。

验证：确认旧登录态已失效，新密码只有公司掌握。

易错：漏掉浏览器里”记住的登录”。这一步最耗时，而它耗时的根源是”密码曾经被员工看到过”。以飞跨为例，它采用密码对操作者不可见的模式——员工打开店铺时密码由系统自动填入，看不到也复制不走，所以离职时不需要逐个更换该员工碰过的所有账号密码，账号控制权始终在公司主账号手里，这一步可以直接省掉大半。

第三步：把店铺重新指派给接手人

操作：将该员工负责的店铺，重新指派给接手的同事，或先收回到主账号再分配。

验证：接手人能正常打开店铺、正常操作。

易错：接手时把运行环境也一起换掉（换了设备、换了 IP）。这是交接环节最隐蔽的坑——见下一节。

第四步：解绑并重新设置 2FA

操作：解除该员工手机上绑定的二步验证器，把验证重新绑定到接手人或由系统统一管理。

验证：接手人能正常收到并填入验证码。

易错：2FA 还绑在离职员工的手机上。这会导致一个尴尬局面——人走了，验证码还发到他手机，接手人登不进去。

第五步：解除共享账号的授权

操作：撤销该员工对共享邮箱、共享收款账号等的访问授权。

验证：确认其无法再调用这些共享资源。

易错：只盯着店铺账号，忘了共享类账号也是一条访问路径。

第六步：把整个交接过程记录下来

操作：记录交接了哪些店铺、谁接手、什么时间完成、撤了谁的什么权限。

验证：这些记录事后可查。

易错：全程口头交接、无任何记录。一旦交接后某个账号出问题，没有记录就只能靠互相回忆，说不清是谁、哪一步出的问题。

团队加新人时，怎么给权限才不过界

扩张时出事，几乎都是权限给多了、给乱了。给新人权限有一个正确顺序。

给新人权限的正确顺序是先定角色、再放人进来，而不是先给全部权限、之后再慢慢回收。 先想清楚这个岗位该能做什么、不该碰什么，把权限边界定好，新人进来直接套这个边界。

• 最小权限：运营只给运营相关权限，不给店铺转让、财务、二步验证管理这类高危权限。
• 限制登录时间段：如果工具支持，把新人的可登录时间限定在工作时段，非工作时间无法操作任何店铺，从源头减少私下操作或误操作。
• 共享账号按需精确授权：需要用到共享邮箱或收款账号时，精确授权给指定的人，而不是直接把密码给出去。
• 环境独立：新人负责的店铺要有独立的运行环境，不要和老员工的店铺挤在同一个 IP 或同一个浏览器环境里，否则等于人为制造关联。

交接时最容易出事的四个地方

这四个坑，每一个都见过有人栽进去。

• 只改密码、不撤权限、不清登录态。员工的访问权和浏览器里的登录态还在，改了密码也挡不住他从已登录状态继续进。

• 接手时连运行环境一起换了。每个店铺本该运行在自己独立的隔离环境里——独立 IP 加独立浏览器容器，这套独立隔离是它不被平台关联的基础。交接时如果给接手人换了设备、换了 IP，平台会看到这个店铺的网络和设备信号突然变化，反而可能触发风控甚至关联判定。正确做法是交接”谁有权访问”，而不是店铺运行的环境本身。

• 2FA 还绑在离职员工手机上。账号交出去了，验证码还发往前员工的手机，接手人登不进、前员工反而还能收到验证信息。

• 全程口头交接、没有记录。交接完一旦出问题，查不到是谁在什么时候动了什么，责任和原因都说不清。

把交接变成一套常设机制

最好的交接，是平时就把机制搭好，离职和扩张时只是按既定规则调整，而不是每次临时救火。一套为多店铺团队设计的工具，能把上面这些步骤固化成常设能力。

以飞跨为例：

• 角色与分权：预设运营员工、运营组长、超级管理员、财务管理、IT 管理五种角色，权限边界已经划好；不匹配实际分工时可以完全自定义，精确到每个功能模块的开关。扩张加人时，套角色即可，不用每次手动配。
• 临时接手：需要让客服或外部人员临时处理某个店铺时，临时授权窗口可设 1 到 96 小时，到期自动撤销，授权方不用记着事后收权，被授权人也拿不到密码。
• 可追溯：控制台日志记录开店、加成员、改权限、续费等组织级操作，操作人和时间都有记录；店铺日志则记录单个店铺的登录和授权变更。出问题时直接查日志定位，不靠回忆。
• 环境不变：每个店铺始终运行在自己的独立 IP 设备加独立容器里，也就是它的双层隔离机制；交接换的是访问权限，不是运行环境，所以不会引起关联信号突变。

把这些做成常设规则之后，再遇到离职或扩张，交接就从”一堆容易漏的动作”变成”按规则走一遍”。

常见问题

员工离职或团队扩张时，多店铺权限怎么交接才不出事？

按场景分开处理。离职：先撤访问权限和清登录态（不是只改密码）、把店铺指派给接手人、解绑 2FA、撤销共享账号授权、全程留痕。扩张：先定角色再放人进来、坚持最小权限、限制登录时间段、新人店铺环境独立。两个场景的共同底线是——交接的是”谁有权访问”，每个店铺的运行环境保持不变，并且全程有记录可查。

员工离职，到底要不要把所有账号密码改一遍？

取决于密码在使用期间有没有对员工可见。如果员工能看到、能复制密码，那相关账号都得改一遍，否则他离职后仍掌握密码。如果用的是密码对操作者不可见的管理方式（密码由系统自动填入、员工看不到），离职时只需撤掉其访问权限，不必逐个改密码。

交接店铺时，可以直接把运行环境、设备也一起换给新人吗？

不建议。每个店铺的独立 IP 和独立浏览器环境是它不被关联的基础，交接时如果突然换了设备或 IP，平台会看到信号突变，可能触发风控。正确做法是保留店铺原有的运行环境，只调整谁有权限访问它。

临时找外包或客服帮忙处理店铺，怎么给权限最安全？

用有时效的临时授权，而不是把密码直接发给对方。比如飞跨的临时授权可以设 1 到 96 小时，到期自动失效，授权期间对方只能访问指定店铺、拿不到账号密码，排查或处理完成后权限自动收回，不存在”忘了收权限”的情况。

离职员工走之前动了账号、删了东西，怎么查是谁干的？

靠操作日志。如果系统记录了每个组织级操作（开店、改权限、加成员等）和每个店铺的登录、授权变更，包含操作人和时间，就能直接定位到是谁在什么时候做的。如果平时没有留痕机制，事后基本查不清——这也是为什么”全程留痕”要作为交接的固定一步。

团队几个人轮流登同一个店，2FA 验证码怎么管？

不要靠在微信群里转发验证码——那等于把账号验证信息对外扩散。更稳妥的做法是用支持自动填充验证码的工具，验证码由系统识别并填入，不经过人手传递；员工离职时，解绑其验证绑定即可，不影响其他人。

新人入职，最容易给多、给错的权限是哪些？

最常给多的是店铺转让、财务（充值、查交易明细）、二步验证管理这三类高危权限。运营岗位通常只需要登录店铺、日常操作的权限，上面这三类应该留给管理员或财务角色。按最小权限原则，先给最少的，不够再加，比先给全再回收安全得多。