Commerce
WooCommerce 与 WordPress
WooCommerce——双向，且有治理
一键配对、深度商品导入、真正的写回——都在你自己选定的字段级归属之下，每个操作都有演练模式，冲突也有一本看得见的台账。完整说明见 Commerce 页面。
完整页面Google 与 Meta 购物数据源
一份按 Google 规范生成、带令牌保护的商品数据源（Meta Commerce Manager 读的是同一份），让你的广告商品目录保持同步——路上不用过应用审核，也不用手工重传。
Shopify 即将
底子是真的——Shopify 的客户身份已经能联合到联系人上，目前 Shopify 店铺通过 API 和 Webhook 接入。像 WooCommerce 那样的原生双向同步在路线图上，这个徽章会在它上线那天翻转，不会提前。
完整页面客服与工单
Zendesk——给正在搬家的团队用的一座桥
Pull：客服回复收回来
一个 Zendesk 触发器把客服评论送回 ConnectWiz 的会话——用共享密钥加固，并带回环保护，两套系统绝不会把一条评论无限弹来弹去。
不加粉饰的适用范围
它是一座工单桥——创建、回复，两个方向都能单独开关——不是 Zendesk 帮助中心、宏或 SLA 的导入工具。团队用它逐步迁移，迁完就关掉。
CRM
Estesoft Stella——你的 CRM，在会话里就看得见
这是我们与厂商无关的 CRM 接口上的第一家：用 Stella 的诊所保留原来的 CRM，同时多出一层真正懂它的会话层。
实时上下文，绑定身份
来自 Stella 的预约、报价、余额、备注和文档都会浮现在会话里——AI 只能读取眼前这位客户的，绝不靠猜某个 ID。
预约会写回原系统
在聊天里定下的预约会落进 Stella 的日程本——厂商 API 带不动的那些细节，同步会明说丢了什么，而不是悄悄丢掉。
刻意为之的拒绝
诊疗记录从不读取、也不展示，厂商自己的生命周期标签从不覆盖，也不假装做了完整的双向镜像——这些边界是写下来的设计决定。
Estesoft Stella——完整页面 · 在用别的 CRM？这个接口在设计上就与厂商无关—— 告诉我们你在用哪个。等你准备好彻底离开旧系统时， 迁移引擎 ——见下方，它会把你的历史一并搬进来。
营销与服务商
自带服务商——这是我们的一贯主张
Push：你自己的 OneSignal
访客网页推送跑在你自己域名下的推送应用上——因为网页推送本来就是这么运作的，假装不是这样，第一天就会出问题。
预约推出去，忙碌时间拉回来
预约会推送到 Google、Microsoft 365 和 Apple/CalDAV 日历，取消时随之消失；外部的忙碌时间从可约时间里扣除，所以不管是人还是 AI，哪一扇门都给不出一个已经被占的时段。详见 Booking 页面。
每个来源各自的方向
每本日历扮演你指派的角色——只读、只写、双向，或者只看忙碌时间——所以诊所的共享日历和医师的私人日历能共存，不会互相覆盖。
广告与合规
会话、广告平台与监管机构之间的那套管道
Meta Conversions API
赢下的商机会回报给最初带来这场对话的广告——作为一次带各渠道正确身份匹配的购买事件——再加上来自你 CRM 漏斗的线索质量信号。你的数据集，你的令牌，默认关闭；任何事件出门前都要过四道闸门（同意也在其中），还有一块健康面板显示发出了什么、拒掉了什么，以及为什么。
完整页面这一节的诚实规则
广告和合规类集成只会在同意闸门之后触发，每一次被拒的事件都带原因记录在案。如果一个号码无法有把握地匹配上，就不去猜——配错身份，花的是别人的隐私。
迁移
离开旧 CRM，历史一起带走。
一台真正的迁移引擎
对于已支持的源系统：联系人、预约历史、报价、销售订单、应收和备注，都通过一台带队列、可断点续传的引擎导入——由我们团队陪着跑，因为换 CRM 这件事值得配一个操作员，而不是一个按钮。
跳过了什么，都点名说
引擎拒绝凭空编造数值——缺币种或缺日期的记录会被跳过并计数，所以“迁移完成”里绝不会藏着还留在旧系统里的记录。
归属权最后才翻转
数据归属权在最后一步才转移，等导入自己证明了自己之后——在你决定改变之前，旧系统一直是权威。
同一份 OpenAPI 契约
整个平台由一份 OpenAPI 3 文档定义——我们的网页面板和手机 App 也是从这份契约生成类型的。没有影子接口，文档也不会跑偏。
带范围的 Commerce API 密钥
由租户签发、权限范围写明的密钥——商品目录读、订单读、订单写——让你自己的店面或 App 跑在我们的商品目录和订单引擎上。
出站：流程来调你
REST 步骤会在你在画布上画出的那个时刻调用你的系统。那种“订阅一切”的通用 Webhook 事件流还没做——写在这里，省得你在销售电话里才发现。