项目速览 · 做了什么，交付到哪一步
原有问题是一个租户如何反复创建和管理多个外贸站点。进入多租户阶段后，需要进一步明确谁能管理客户、谁能操作站点、资源用完后由谁处理。我的角色是产品规划与原型设计，案例重点展示这些业务边界如何落到需求和页面中。
- 交付材料包括平台总后台、租户后台、站点客户端三份需求文档，以及总后台和部分租户功能原型。
- 本文聚焦职责划分、配额校验与服务开通，展示方案和交互层面的产出。
- 当前为 Prototype 原型阶段。需求已写入文档、页面已有原型，与真实系统完成开发和业务效果得到验证是不同阶段。
问题起点 · 平台不能一直替租户操作站点
单租户阶段，批量建站主要解决重复配置和发布的问题。多个租户共用平台后，继续由平台人员代操作每个站点，会把客户管理和日常内容运营混在一起。方案因此把租户开通、版本和服务权限放在平台总后台，把站点、成员和内容操作放回租户自己的工作空间。
- 平台管理租户生命周期、版本、配额和增值服务。
- 租户管理员管理本租户成员、站点、域名、语言和素材。
- 站点客户端面向访客展示已发布内容；租户间的数据隔离仍需在实际系统中验收。
职责示意 · 平台、租户与站点
决策一 · 在操作入口解释配额限制
站点数用完后，租户点击“创建站点”应该得到什么反馈？需求把额度检查放在进入创建页面之前。达到上限时，显示已用数量与上限，并提示升级；未达到上限时，才继续填写站点信息。这样可以提前解释阻断原因，避免用户填完表单才发现无法提交。
- 设计依据来自租户后台需求中的站点创建流程。顶部同时展示站点、存储、语言和域名用量，让限制有可查的依据。
- 类似规则分别落到上传素材、启用语言和绑定自定义域名的入口；一次操作被阻止时，需要说明具体是哪项额度不足。
- 交付结果是明确的检查时机、提示内容与下一步动作。真实系统是否能在多次同时操作时准确计数，仍需开发与测试验证。
决策二 · 自助建站与人工开通分开
租户可以在授权范围内管理站点，但首版升级、续期和增值服务开通仍由人工处理。租户后台的升级和续期按钮提示联系客服，增值服务由平台管理员在租户详情中开通。产品说明需要把这条边界写清楚，避免让租户以为点击后就能付款并立即获得权限。
- 版本允许使用某项服务，不等于租户已经开通；服务的开通状态决定对应配置入口是否出现。
- AI 客服未开通时，配置菜单隐藏，顶部服务区域说明未开通；开通后，租户再配置基础信息、开场白和知识库。
- 这套范围把在线购买留给后续版本。当前仍需人工受理和开通，不能宣称已形成自动购买、支付与续费流程。
决策三 · 到期影响后台，也影响访客
到期不能只在租户列表里换一个标签。平台需求把提醒、宽限期和锁定后的行为连起来描述。进入过期锁定状态后，租户后台不可登录，站点向访客显示维护页面；平台人员负责续期处理。
- 需求要求提前提醒，并允许配置宽限期，给租户和平台人员处理时间。
- 验收需要同时检查租户后台和访客网站，确认两处状态一致。只检查后台标签不足以证明规则生效。
- 锁定对访客访问有直接影响。提醒是否送达、续期后的恢复是否完整，以及租户能否理解这些后果，仍需在实际使用中验证。
交付证据 · 文档与原型分别说明什么
本案例依据已有需求文档和原型整理。公开页只保留通用业务规则与脱敏示意图，原始文件中的企业、客户、账号和内部链接不公开。
- 平台总后台需求 v1.2 记录租户创建、版本与配额、服务开通和到期管理；对应总后台原型用于展示这些页面与操作关系。
- 租户后台需求 v1.0 记录用量展示、超限提示、成员角色和服务配置；已有顶部信息区、域名配置和 AI 客服配置等局部原型。
- 站点客户端需求 v1.0 说明面向访客的站点范围，使租户后台的管理动作与对外展示对象有明确对应。
- 这些材料能说明方案已被具体化，不能单独证明租户隔离、线上任务执行或商业收益已经通过验收。
结果与限制 · 形成可评审的方案
这次工作的可展示结果，是把批量建站进一步整理成三层职责、四类资源额度，以及人工开通与租户自助操作的边界。讨论可以落到具体情境，例如额度用完、服务未开通、租户过期时，用户会看到什么、由谁接着处理。
- 尚未提供可公开核验的上线效果数据，因此不填写节省工时、转化提升或客户数量。
- 下一步先让真实运营人员完成创建站点、识别超限和申请开通等任务，记录卡点与是否需要协助。
- 开发验收再覆盖跨租户访问、额度同时占用、锁定与续期恢复等情况；有对应证据后再更新项目状态。