一个新客户签约了，销售很开心，客户成功开始准备 onboarding，产品团队也希望客户尽快用起来。
但很快就出现一个小问题：
“客户的访问入口谁来创建？”
是工程师？客户成功？运维？还是某个懂 DNS 的同事？
如果每次都要发工单、等排期、人工配置，客户体验就会被一个看起来很小的入口问题拖慢。
快速答案
如果你的 SaaS 产品需要给客户创建专属入口，例如：
acme.yourplatform.comclient-a.example.comtenant123.app.example.com
那么最好不要让这个流程长期依赖手工 DNS 修改。
更好的方式是把 tenant entry 当作一个可管理对象：
- 创建入口；
- 绑定目标；
- 记录客户归属；
- 设置状态；
- 支持 API 自动化；
- 支持后续禁用、替换和归档。
PushUlink 可以帮助团队通过 Console 和 OpenAPI 创建、统计、替换和下线托管子域名转发入口。
为什么客户入口不应该只存在于 DNS 里
DNS 负责解析，但业务团队需要知道更多东西。
例如：
- 这个入口属于哪个客户？
- 客户是否还在使用？
- 目标地址是什么？
- 最近有没有访问？
- 谁创建的？
- 谁修改过？
- 客户取消服务后怎么下线？
这些问题，单靠 DNS 记录很难回答。
常见混乱场景
场景一：销售催上线
客户已经付款，希望今天就开始使用。客户成功找到工程师说：
“能不能帮忙建一个客户入口？”
工程师正在处理别的需求，只能回复：
“晚点看。”
客户等待，内部催促，最后一个简单入口变成了跨团队协调。
场景二：客户改名或迁移
客户公司名称变了，或者你们的应用路径换了。
旧入口要不要保留？新入口怎么指向？旧入口访问有没有人看？
如果没有台账，这些问题很难回答。
场景三：客户流失后入口还在线
客户已经停止合作，但入口仍然存在。几个月后安全同事做检查，发现一堆没人认领的 tenant subdomain。
这不是单纯的整洁问题，也会带来运维和安全风险。
一个更健康的开通流程
建议把客户入口开通拆成几个步骤：
- 客户创建或签约；
- 系统生成 tenant 标识；
- 创建子域名入口；
- 绑定目标应用地址；
- 写入客户归属信息；
- 返回给客户成功或产品系统；
- 后续访问、修改、下线都留痕。
这套流程不需要一开始很复杂，但最好从第一天就有结构。
API 自动化适合什么时候用？
如果你每个月只新增一两个客户，Console 手动创建也可以。
如果你有下面情况，就应该考虑 OpenAPI：
- 新客户开通频率高；
- 产品注册后自动生成入口；
- 客户成功不想每次找工程师；
- 多环境、多地区入口需要统一规则；
- 需要把入口状态同步到内部系统。
API 的价值不是炫技，而是把重复流程变成稳定流程。
PushUlink 在这里解决什么
PushUlink 可以把客户入口从“某条 DNS 记录”变成“可管理的 tenant entry”。
它可以帮助你：
- 通过 Console 创建客户入口；
- 通过 OpenAPI 自动创建；
- 标记入口所属客户；
- 替换目标地址；
- 查看访问统计；
- 保留操作日志；
- 客户离开后禁用或下线入口。
这样客户入口就不再靠记忆维护。
常见问题
这是不是自定义域名管理？
有重叠，但不完全一样。自定义域名通常关注客户自己的域名接入。这里讨论的是平台自己提供和管理的 tenant subdomain 或业务入口。
小团队也需要吗？
如果客户入口很少，可以先用简单台账。但只要你开始频繁创建、修改、下线，就需要更结构化的工具。
客户成功可以操作吗？
可以，但建议配合权限边界。比如客户成功可以创建和查看入口，但不能修改全局配置。
最容易被忽略的是什么？
下线流程。很多团队只关注创建入口，却忘了客户离开后如何清理。
最后
客户 onboarding 的目标是让客户尽快拿到可用入口，而不是让内部团队互相等待。
把客户入口变成一个可自动化、可追踪、可下线的对象，会让 SaaS 团队的开通流程更轻。
