ConnectWiz + Estesoft Stella
已上线的集成Stella 仍然是你的 CRM，对话终于认得它。
我们那个不绑定厂商的 CRM 接口层，接入的第一家就是它：每一段会话里都带着来自 Estesoft Stella 的实时客户上下文，预约会写回 Stella 的日程表——另外还有一组白纸黑字的刻意拒绝，写明一个通讯产品永远不该碰什么。
CRM
它到底能做什么
实时上下文，绑定身份
这位客户的预约、报价、未结余额、备注和文件都会出现在会话上——AI 能读到的也只有这一位客户的，客户身份由会话本身解析得出，绝不靠猜 ID。
预约会写回原系统
在聊天里约好的时间会落到 Stella 的日程表里——厂商 API 装不下的细节，同步过程会明说它丢了什么，而不是悄悄丢掉。
AI 只读，永不写入
整个 CRM 接口层上的一条长期规则：读取绑定身份，写入留给人——一个可能把余额读错的 AI，就是把病人约错的廉价彩排。
迁移由你决定时机
一个可排队、可续跑的引擎，把预约、报价、销售、应收款和备注导入 ConnectWiz——跳过的记录会逐项报出来，数据归属只在最后一步才切换。
收款和订单也会写回去
在 ConnectWiz 里记一笔收款或建一张订单，可以同步到 Stella——需要所有者明确决定才会开放，并且和其他写入一样，要过同样的四道关卡和预演模式。
增量同步，不是镜像
变更轮询的存在是为了兜住漏掉的事件，不是为了给诊所的台账再存一份。分不清这两者，缓存就变成了数据库，所以我们把它写下来。
技术细节
写入路径：四道关卡加一次预演
每个操作默认都是关的
每一项写入出厂就是关闭状态，七个操作——备注、预约、取消、客户、报价、订单、收款——各有各的开关。这里的安全来自“不存在”：有一道关卡不通过，就根本没有写入对象可供调用。
归属权高于开关
逐操作开关之上还坐着数据归属：归你工作区所有的那一类数据，无论开关怎么设，都绝不会写出到 Stella。关卡的先后顺序是固定的，也写在文档里。
在真实代码路径上预演
空跑模式会构造出真实写入将要发送的那个载荷，只在传输这一步停下——走另一条代码路径的彩排什么都证明不了，所以我们没有那种模式。
写入会自证
每次写入之后，集成会把刚创建的内容读回来做比对。不一致会作为告警交给人处理——绝不自动纠正，因为厂商 API 没有幂等键，自动纠正并不安全。
迁移有正确的顺序
预约先导入——这是刻意安排，因为日程表是唯一能在整个租户范围内发现人的界面。每一行被跳过的记录都会按原因计数：不在时间窗内、结构不认识、缺联系方式。
AI 的读取有三重锁
AI 的 CRM 工具只对外声明你工作区确实拥有的动作，调用时再校验一次，客户则由会话本身解析得出——幻觉出来的选项，或者猜出来的 ID，走不到传输那一步就死了。
接入设置
连接方式
接入 Stella
填入你的 Stella 凭据；连接器会先对真实 API 做校验，通过之后才保存。
带着上下文工作
会话里会显示这位客户的 CRM 卡片；客服人员和 AI 都按事实作答，而不是凭记忆。
想迁移时再迁移
跑一次有人协助的迁移，把完整历史搬进来——在你切换归属之前，旧系统一直是权威数据源。
安全与保证
无聊但管用的保证
健康数据：永不读取
诊疗记录在 KVKK 下属于特殊类别数据。把它们读进客服界面，会让接触这些数据的人从诊所的医师扩大到整个团队——所以接口就在那里，我们白纸黑字地拒绝调用。
没有看不见的手
我们绝不替诊所关闭它的任务，绝不改动它的客户分群，绝不碰它的账务台账——每一条都是写在文档里的拒绝，因为从一个聊天窗口去自动化别人的业务流程，是这个产品代价最高的一类错误。
token 不进 URL
厂商提供了一个把凭据放进 URL 的 token 校验接口——日志和代理都看得见。我们从不调用它。凭据怎么传，是一个接口一个接口地定下来的。
删除：不提供
厂商针对客户、线索、账单和报价的删除接口，我们一个都没用——软删除还是硬删除没有验证过，而“删掉一份患者记录”不属于任何一个我们愿意承担的用户故事。
不加粉饰的细则
边界，写清楚
刻意为之的拒绝
诊疗记录永不读取、永不展示，厂商的生命周期标签永不覆盖，也不假装存在完整的双向镜像——每一条拒绝都是写在文档里的设计决定，不是功能缺口。
其他 CRM
这个接口层在设计上就不绑定厂商——Stella 是第一家，不是最后一家。你在用别的系统？告诉我们，这会影响排期。