每个商家一个预约界面。
客户询问空档、选择时段，然后直接进入结账——全部在你的网络内完成。预约视图已上线；在线支付环节 ⚠️ 仍在集成中，因此我们以线框图展示，而非已交付的界面。
示意图——真实产品截图即将推出。支付确认是概念图，不是已构建的界面。
对支付保持坦诚
预约架构已就绪，按日历的网关结构也已到位。在线支付通道仍在集成中 ⚠️ ——这与我们在 Marketplace 上坚持的透明度标准一致。我们为每项声明标注 已上线, 部分可用 或 Roadmap，让你始终清楚今天交付什么、接下来推出什么。
预约和支付不应该是两个用胶带粘在一起的系统。
大多数服务商家在纸质记事本、独立的预约应用和互不相通的支付链接之间疲于应付。Calendar 把这一切合并到一个流程中。
预约服务与活动
安排时段、课程和活动，并协调多个地点的可用性——一个单一的事实来源，而不是散落的记事本。
收取定金与服务费
收取定金以减少爽约，或收取全款服务费——每个日历都有自己的结账方式。 ⚠️ 支付通道集成中。
协调多地点的可用性
按商家的日历存在于同一个网络中，因此每家门店和每位专业人士都管理自己的日程，互不干扰。
从“你们有空档吗？”到确认预约——全程无需人工。
The space is the router：向助手提问的客户就是完成预约的客户，在一个从不离开你网络的连续流程中。
- ✓一个流程，而非三个应用 ——日历、结账和助手在一次对话中完成，而不是在记事本和支付工具之间重复录入。
- ✓按商家的日历 ——多商家是原生能力，因此每个本地商家或专业人士都在一个网络内运行自己的日程。
- ✓定金减少爽约 ——按预约收取定金的结构已就位；支付通道即将落地。
- ✓每次预约都是网络事件 ——已确认的预约流入网络的交易历史，而不是你无法查询的孤岛。
从注意到行动，全在一个网络里。
无需切换渠道，无需转交，没有“我稍后回电确认”。
注意
一个自己就能成交的日程——把可用性转化为收入的日历。
兴趣
你网络中的每个商家都在客户正在聊天的地方发布服务和活动日历，并带有各自的结账流程。
渴望
从“你们有空档吗？”到无需人工介入的确认预约——而且事件保留在网络的交易历史中。
行动
设置好你的日历，让预约自己落地。 ⚠️ 支付通道完成集成后，在线支付将闭环。
今天交付什么，还有什么在路上。
状态标记是精确的：警告意味着该能力在架构上真实存在，但尚未端到端上线。
| 特性 | 优势 | 收益 |
|---|---|---|
| 按商家的日历 ✅ | 多商家原生设计 | 每个本地商家或专业人士运行自己的 |
| 按日历的网关（结构） ✅ | 灵活的结账方式 | 每项服务都有自己的收费方式 |
| 在线支付——集成中 ⚠️ | 状态坦诚 | 一个公开、优先的 Roadmap 项目 |
设计上就坦诚
交易结构已经完成；剩下的只是支付处理器。我们会明确告诉你缺什么，而不是把 部分可用 的能力粉饰成 已上线。
与你网络的其余部分配合更佳。
Calendar 是一个可组合模块——它与商务以及最初受理请求的助手天然搭配。
