联系与试点
先把咨询路径和试点边界说清，再安排下一步对接。
Clawo 当前把公开咨询、试点评估和已开通后的支持路径分开处理。这个页面不承诺自助开通， 而是把试点 intake 固定成一个可执行路径：先在这里收口信息，再进入受邀开通说明页。
当前公开站点只收口咨询与试点说明，不把微信 service-account 当作有效公开入口。 如果后续开放新的对接渠道，会先在 clawo.net 明确说明，而不是在页面里默认假定它已经可用。
当前受理方式
先把对象、边界和前置条件对齐，再决定是否进入试点评估或已开通支持流程。
主站入口
clawo.net
统一 intake 路径
先在 /contact 收口场景，再进入 /register 的受邀开通说明
当前边界
不开放自助开通，也不把微信 service-account 作为公开咨询入口
支持路径
当前支持三条路径，不把不同阶段的问题混到同一个入口里。
公开咨询、试点 intake 和已开通后的支持使用不同入口。这样做的目的不是增加门槛，而是避免把售前判断、 试点排期和存量支持搅在一起，导致每一类问题都得重复补背景。
试点 intake
先完成试点信息收口，再进入受邀开通流程说明
不提供公开自助注册表单。先在这里准备场景、交付模式、责任人和前置条件，再进入受邀开通说明页，确保后续对接不走回头路。
交付确认
交付模式先收口，避免试点启动后再返工
如果你已经明确要推进试点，下一步应先确认是 SaaS、托管部署、私有化还是预装硬件，以及哪些模式当前不接受。
已开通路径
如果已经拿到账号或实例，不走公开咨询，直接回控制台和支持资料
适合已开通客户、试点团队和内部交付协作方。公开站点只负责说明入口，继续操作应回到登录页、文档或支持中心。
下一步
无论是咨询还是试点，下一步都先从范围和前置条件开始。
这里不承诺“点一下就开通”。当前阶段更重要的是先把对象、约束和成功标准收口， 这样后续的试点评估或交付准备才不会变成反复重做。
1. 先确认对象
先判断你是在评估平台商品、外贸助手方案，还是已经处于已开通后的支持阶段。
2. 收口试点范围
把要解决的问题、想验证的业务环节、涉及的角色和预期交付模式压缩成一个可讨论的最小范围。
3. 对齐前置条件
确认数据来源、网络环境、API 约束、部署位置和内部负责人，避免进入试点后才发现关键阻塞项。
4. 进入后续排期
范围和前置条件都明确后，再安排下一步的试点评估、交付准备或已开通客户支持动作。
需要准备什么
进入咨询或试点前，先把这几类信息准备好。
不要求你一次把所有细节都讲完整，但至少要能说明问题、场景、约束和负责人。 如果这些基本信息都没有，后续无论是平台商品还是外贸助手方案都会很难判断是否适合。
业务目标
你希望用 Clawo 缩短哪一段流程，例如部署落地、运行控制、获客调研或人工跟进准备。
目标商品或方案
请先说明你更偏向 OpenClaw 标准版、增强版，还是外贸助手；如果还不确定，也请说清楚主要判断依据。
交付模式偏好
直接说明你更接近 SaaS、托管部署、私有化或预装硬件，或列出哪些模式你当前不能接受。
团队与角色
谁负责业务判断，谁负责技术接入，谁会参与试点验收；没有 owner 的试点通常会拖慢很多。
环境与约束
包括网络环境、域名、服务器、合规要求、可用 API，以及是否只能在客户自有环境内运行。
成功标准
请提前定义你希望在试点里看到什么结果，例如完成一次交付、跑通一条获客链路，或验证控制面可用性。