Overview · SaaS 化不是多加几个后台
这个项目的核心变化，不是把单租户页面复制给更多客户，而是重新划分产品边界：先把一个租户批量创建和管理多个站点做顺，再让平台总后台管理租户生命周期，让租户后台管理自己的成员、配额和站点。只有当租户能够在隔离的权限和配额内自助经营，单站点工具才真正具备 SaaS 化的基础。案例只保留通用的产品结构和判断过程，隐去公司名称、客户资料、真实链接和内部数据。
Starting point · 先把单租户的批量建站做顺
最初的业务问题发生在单个租户内部：运营人员需要反复创建、配置和发布多个外贸独立站。如果每个站点都单独操作，模板、域名、语言、内容和发布状态很容易失控。因此先把站点管理抽象成可批量执行的流程：选择站点、部署前校验、批量执行、查看进度和结果，失败任务还能从后台继续处理。
- 批量操作解决的是一个租户内部的交付效率问题，不等于已经完成 SaaS 化
- 站点配置需要复用模板、主题皮肤、多语言和内容规则，避免每个站点重新搭建
- 部署前先提示配额、配置或域名问题，并保留失败原因，避免批量操作变成批量返工
SaaS leap · 从平台代操作到租户自助经营
SaaS 化的关键转折，是把“平台团队帮每个客户建站”改成“平台提供能力，租户自己完成建站”。平台总后台负责创建和维护租户、配置版本和增值服务；租户管理员进入自己的工作空间后，可以创建成员、管理多个站点，并按授权配额批量建站。平台不再需要为每个租户重复执行同一套站点操作。
- 每个租户有独立的用户、站点、内容、询盘、素材和操作记录边界
- 租户管理员只能操作本租户资源，平台总后台可以查看和管理租户级状态
- 租户自助创建站点时，系统先检查版本权限、站点数量、域名、存储和语言等配额
- 配额不足时停止创建并提示升级或购买增值服务，而不是让租户先创建再人工补救
Platform architecture · 总后台、租户后台、站点管理三层职责
- 平台总后台：管理租户创建、启用、到期、锁定、版本、配额、增值服务、订单和全局运营数据；平台账号与租户账号分开管理
- 租户后台：管理本租户成员与角色、套餐使用情况、站点列表、域名、语言、图库、产品、文章、询盘和 AI 客服配置
- 站点管理：在租户边界内完成单站点配置，或选择多个站点批量创建、编辑、校验、部署和查看结果
- 权限与日志：记录谁在什么租户、什么站点执行了什么操作，为后续审计和问题回溯留下依据
Tenant self-service · 每个租户都可以自己批量建站
租户管理员进入租户后台后，可以从可用模板和主题中选择站点方案，填写必要的站点信息，再一次性创建或部署多个站点。流程中的校验、进度、失败原因和后台任务都归属于当前租户；平台总后台只需要维护规则和资源，不需要代替租户操作每一个站点。
- 创建前：选择模板、语言、域名和目标站点，系统检查可用配额和必填配置
- 执行中：显示批量任务进度，允许离开页面后从租户后台继续查看
- 完成后：按站点返回成功、失败和待处理状态，并保留失败原因
- 后续运营：租户可以继续在自己的图库、内容、询盘和统计模块中管理这些站点
Commercial boundary · 版本、配额和增值服务成为产品边界
为了让多租户模式可以被管理，版本不只是价格标签，而是租户能够使用哪些能力的边界。总后台可以配置不同版本的站点数、存储空间、语言数、自定义域名和功能权限；租户后台实时展示使用量，超过配额时给出清晰的阻断和升级路径。
- 基础配额：站点数量、域名数量、存储空间和可用语言数量
- 功能权限：页面装修、多语言、SEO、AI 客服、询盘分析、产品与文章管理等模块按版本开放
- 增值服务：AI 客服、营销或其他扩展能力可以独立开通，不必修改租户核心数据
- 到期处理：租户到期后锁定登录或进入维护状态，并由总后台统一处理续期和恢复
Reusable capabilities · 单租户功能如何变成平台服务
- 模板与皮肤分离：模板负责页面结构，皮肤负责视觉主题，多个租户可以复用同一套产品能力
- 多语言配置复用：PC 与移动端共用站点配置，语言内容和翻译规则按租户、站点和页面维护
- 统一图库：图片搜索、ALT、引用次数、翻译图、压缩和地址规则集中治理，避免每个站点各自维护
- 询盘 AI 与统计：询盘先保存再异步分析，按规则决定推送；统计按站点、部门和负责人查看去重后的询盘量
- 内容生产：TDK、产品详情、文章和素材生产能力沉淀为租户可以重复使用的工作流
Prototype evidence · 用原型验证 SaaS 关键路径
- 总后台原型：验证租户列表、创建租户、租户详情、版本与配额、增值服务、到期状态、成员和操作日志
- 租户后台原型：验证套餐与到期提示、站点管理、域名、语言、图库、成员、产品、文章、询盘和 AI 客服入口
- 批量部署原型：验证站点选择、部署前校验、执行进度、失败原因和后台继续执行
- 询盘 AI 分析原型：验证意图标签、星级与原因、推送状态、人工放行和人工标注
- 统一图库与统计看板原型：验证素材治理、站点/部门双视图、筛选联动、角色权限和去重口径
Product thinking · 这次产品化真正解决了什么
- 把单租户内部的批量建站能力上移为平台能力，再下沉为租户可以自助使用的产品能力
- 把“客户、站点、成员、版本、配额和增值服务”从页面概念变成可管理的产品对象
- 用权限隔离和配额校验保护平台边界，用租户自助操作降低平台团队的重复交付成本
- 不把 AI 结果直接当作最终判断，保留人工纠正、重新推送和标注回流
- 不追求一次性覆盖所有营销能力，先让租户从创建站点到运营获客形成可理解、可操作、可复盘的闭环
Reflection · 公开展示的边界
这个案例展示的是从单租户工具到多租户 SaaS 的产品规划、业务抽象和原型验证方法，不代表某个客户网站的公开复刻，也不声称已经完成全部开发或取得具体商业结果。原始 Axure 文件、公司名称、客户数据、内部链接和未获授权的页面细节不放入公开作品；当前案例状态保持为 Prototype。
Next step · 仍需验证
- 用真实运营人员验证租户自助批量建站是否能覆盖从创建、配置到发布的完整流程
- 验证总后台的租户生命周期、版本配额、到期锁定和增值服务是否能被清晰执行
- 确认多个租户、多站点、多语言和移动端配置下的数据隔离与维护成本
- 补齐后端接口、权限、计费和上线状态后，再决定是否将案例状态从 Prototype 更新为更高阶段