资源模型
房间、设备、人——像现实那样交叉
“有空”是一个三方问题：执业人员、房间和设备必须同时空着。多数预约工具只建模一个维度，然后祈祷；这一套建模的是它们的交集。
角色与容器
一条预约按角色占住多个资源——房间、设备、执业人员——而容器关系意味着：被占用房间里的设备同样不可用，哪怕没人单独预订过那台设备。
是约束，不是规则
防重叠写在存储层，是一条排他约束——两个并发请求不可能都赢，因为第二次写入会被物理拒绝。规则引擎给的是承诺，约束给的是保证。
容量是一份一份的
八个座位的课程是八份，不是一个计数器——所以“只剩一个”说的是某一份具体的名额，退款也不会把账算乱。
适配资格，单独判断
“这个房间能不能做这项服务”有它自己的矩阵，和占用情况分开——所以空着但不合适的资源不会被给出去，原因也查得到。
日历同步
你的日历，从可约时段里扣掉
预约推出去
预约会作为事件出现在 Google、Outlook 或 Apple 日历里——取消时一并消失。执业人员手机上的日历，不会比预约簿慢上一天。
忙碌时间拉回来
外部事件会从可约时段里扣掉——你个人的 Google 日历上周四 15:00 已经排了牙医，AI 就绝不会把这个时段给出去。
每个来源各自的角色与方向
每个接入的来源都有自己的设置——只读、只写、双向，或只取忙碌时间——这样诊所的共享日历和私人日历可以扮演不同角色，互不打架。
提醒与运维
后续跟进，自动完成
提醒真的会响
按你设定的提前量给客户发确认和提醒——走邮件，也可以加上短信——新预约还会通知员工。“回头再跟一下”不再靠记性。
历史记录可以迁进来
从别的 CRM 搬过来？迁移引擎会把你现有的预约历史导进同一本台账——预约簿不会一上来就失忆。
不加粉饰的细则
在你据此做计划之前先说清楚
暂时还没有独立的预约链接
自助预约目前只在网站聊天挂件里——还没有那种可以直接用邮件发出去的 Calendly 式公开预约页。如果这正是你的主要打法，告诉我们，这会影响路线图。
外部 CRM 装得下的更少
预约写出到已接入的 CRM 时，设备和耗材明细可能保不住——厂商 API 没有开放这些维度，同步过程会明说它丢了什么，而不是悄悄丢掉。
台账始终是我们的
无论接入哪些日历和 CRM，预约台账始终是 ConnectWiz 自己的表——外部系统是数据来源和镜像，永远不是主数据。这是一个设计立场，我们把它写出来。