店铺一多，环境名称就不只是备注，而是团队识别账号、分配权限和执行交接的索引。标签体系设计得好，成员看到名称就能判断平台、站点、店铺状态和负责人；设计得差，误登和交接遗漏会不断发生。

标签体系先解决四个问题

第一，当前环境属于哪个平台和站点。第二，它对应哪个店铺和主体。第三，当前由谁负责、处于什么状态。第四，成员能否根据标签判断是否可以操作。

标签不需要塞进所有信息，但必须包含团队日常识别所需的核心信息，详细资料放在店铺台账或环境详情中。

推荐采用分层命名

基础名称可以使用平台、站点、店铺编号三个字段，例如 AMZ-US-S001、TEMU-US-S003、OZON-RU-S002。店铺名称可能变化，店铺编号应尽量稳定。

状态标签单独维护，例如新注册、试运营、正常运营、待交接、暂停、待关闭。不要把状态直接写死在长期名称里，否则店铺状态变化后，团队容易出现旧名称和新状态不一致。

负责人和风险等级也建议使用独立字段，例如负责人、备份负责人、普通、重点、待审计。这样可以筛选和统计，不必每次从一长串名称里猜。

标签字段怎么分

身份字段：平台、站点、店铺编号、主体编号。

环境字段：环境编号、网络区域、设备类型、创建时间。

管理字段：负责人、备份负责人、所属团队、权限组。

状态字段：注册中、试运营、正常、交接中、暂停、关闭。

风险字段：普通、重点关注、发生异常、待复核。

身份字段应保持稳定，状态和风险字段允许更新。把这两类字段混在一起，后期改状态时容易破坏历史识别。

标签和资料、权限要保持关联

只给浏览器环境打标签还不够。账号资料、成员权限、变更记录、交接记录和异常记录也要能对应同一个店铺编号。否则团队虽然知道环境名称，却不知道它对应哪个邮箱、哪个负责人和哪组权限。

飞跨浏览器这类工具可以按店铺分组管理环境和成员访问范围。实际使用时仍建议把店铺编号作为主索引，让环境、资料和权限围绕同一编号建立关系。

新店创建和店铺关闭时怎么处理

新店创建时，先申请店铺编号，再创建环境和资料记录，最后分配负责人和权限。不要先让员工随意创建环境，后面再补名称。

店铺转交时保留原店铺编号，修改负责人、状态和权限，不建议为了换人而重新创建一套含义不明的新名称。

店铺关闭时，状态改为待关闭或已关闭，归档资料、回收权限、停用环境，并保留历史变更记录。已关闭编号不要立即复用，否则历史记录会混在一起。

常见错误

• 用负责人姓名作为唯一标签，换人后全部失效
• 只写平台和国家，不写店铺编号
• 同一店铺在不同工具里使用不同编号
• 把测试、备用、新店等模糊词当作正式名称
• 关闭店铺后立即复用原编号
• 名称修改没有同步通知权限和资料负责人

检查清单

• 平台、站点和店铺编号有固定格式
• 状态、负责人和风险等级使用独立字段
• 环境、资料、权限和变更记录能对应同一店铺编号
• 新店创建前先分配编号
• 换人只更新负责人，不随意重建历史编号
• 关闭店铺后完成归档和权限回收
• 标签规则有文档并向新成员说明

FAQ

Q：标签怎么起？

可以采用平台、站点、店铺编号三段式，例如 AMZ-US-S001。店铺名称和负责人可以作为单独字段维护，避免名称变化影响历史记录。

Q：店铺多了标签会不会不够用？

三段式加状态、负责人和风险字段，通常能覆盖多店铺团队的日常管理。关键是统一规则，并让环境、资料和权限使用同一店铺编号。飞跨浏览器支持按店铺分组管理环境，适合承接这类标签体系。

Q：店铺换负责人后要不要换标签？

通常不需要。店铺编号和平台站点保持稳定，只更新负责人、备份负责人、权限和状态，并留下交接记录。