一个真实的医疗美容案例研究:56天内生成1540次临床随访,联系患者前进行人工审核。Draft-first原则应用于对信任诊所的患者关系管理。
医疗美容治疗不会在当天结束。肉毒素需要两周后复查。微针在十天后见效。如果诊所提醒患者强化疗程有时间窗口,射频治疗周期的效果会更好。在纸面上,所有人都知道这一点。但在诊所日常运营中,遗忘总是获胜。患者满意地离开,日程继续推进,下次随访电话永远打不出去。
本文描述Nova House——一家墨西哥医疗美容诊所——如何在不陷入另一个极端(即将垃圾邮件伪装成关怀)的情况下,停止失去这些随访机会。解决方案并非魔法,而是一个建立在Odoo之上、规则清晰、每条消息发送前须经人工审批的系统。目前该系统在56天内已生成1540次随访,其中一半来自当天互动窗口,每次发送前均经过临床审核。
问题所在:诊疗之间失去的东西
美容诊所依赖长期临床关系。患者购买的不是单一服务,而是一系列关于皮肤、身体或健康的分阶段决策。商业后果很简单:如果诊所不陪伴这段时间,患者就会将这段关系转移给那些确实陪伴的人。
随访失败的原因在我们接触过的所有诊所中反复出现:
- 没有人在准确时间记得。 强化疗程没有操作性提醒,完全依赖有人手动录入。
- 群发渠道听起来像垃圾邮件。 通用的"别忘了你的治疗"邮件和不发邮件一样会损害关系。
- 日志存在医生脑子里。 当团队扩大时,这段记忆无法共享。
- 联系决定属于临床范畴,而非商业范畴。 不是每位患者都适合在同一天收到同样的消息。这是专业人员知道的事,而不是定时任务。
Nova House与Transgenia合作运营的系统,始于接受这四个事实,而不是否认它们。
案例核心论点:临床关系中的Draft-first
我们内部用于管理AI代理的相同层级结构,在此原封不动地应用于诊所语境:
系统提议。医生审批。日志记录。诊所学习。
Odoo中的自定义模块在每次治疗落入对应窗口时生成随访事件。每个事件初始状态为待审核;除非临床团队成员明确表示同意,否则不发送任何内容。这与我们的AI代理在写入Odoo之前必须遵守的规则相同,与内容代理在发布文章之前必须遵守的规则相同。在医疗美容领域,相同的协议保护最重要的东西:患者信任。
系统架构,无行业术语说明
该系统有三个组件,全部构建在Odoo内部,无需并行平台。
1. 按治疗类型设置规则
每种需要随访的治疗都有专属规则。撰写本文时共有十五条活跃规则,每条对应一种临床相关治疗:Botox、EMSCULP、Radiesse、Halo、BBL、Votiva、Morpheus、NCTF、Powershape、Hydrafacial、NovaCeroCed、Casmara、Microneedling、Sculptra和Emsella。规则是系统中临床知识的基本单元:它不存在于任何人的脑子里,而是存在于可编辑和可审计的Odoo记录中。
2. 联系窗口
每个事件属于特定的时间窗口。Nova House的三个窗口定义清晰:
- 十天前:建议强化日期前十天。
- 五天前:该日期前五天。
- 当天:与患者原始互动的当天。
在生成的1540个事件中观察到的分布如下:
| 窗口 | 事件数 | 占比 |
|---|---|---|
| 十天前 | 378 | 24.5% |
| 五天前 | 378 | 24.5% |
| 互动当天 | 784 | 50.9% |
| 合计 | 1540 | 100% |
当天窗口占据一半并非配置错误,而是对业务的一种解读:大多数事件在治疗当天生成,然后系统将其向前推进。
3. 事件状态
每个事件都有一个生命周期状态。在56天观察期内,分布如下:
| 状态 | 事件数 | 占比 | 解读 |
|---|---|---|---|
| 待审核 | 938 | 60.9% | 系统提议,人工尚未查看 |
| 临床团队审核中 | 289 | 18.8% | 人工已接手,尚未决定 |
| 已批准待联系 | 0 | 0% | 过渡状态;直接跳至发送 |
| 邮件已发送 | 58 | 3.8% | 已实际联系 |
| 已取消 | 248 | 16.1% | 明确的临床取消决定 |
| 需要关注 | 7 | 0.5% | 标记的技术事故 |
| 合计 | 1540 | 100% |
这些数字诚实地说明:系统提议的远多于发送的。这就是纪律所在。自动化不是决策者;临床团队才是。16%的取消率是好消息,而非坏消息:这些是明确的人工决定——"这位患者现在不需要这条消息"。没有这个系统,这个决定根本不会存在,因为随访根本不会摆上台面。
完整流程,逐步说明
一张流程图胜过千言万语。
flowchart LR
A[销售/问诊<br/>录入Odoo] -->|产品有规则| B[规则引擎<br/>15种治疗]
B -->|窗口10天/5天/当天| C[生成事件<br/>x_treatment_followup_event]
C -->|初始状态| D{待审核}
D -->|临床团队接手| E[审核中]
E -->|通过| F[邮件已发送<br/>至患者]
E -->|不通过| G[已取消<br/>附理由]
E -->|技术故障| H[需要关注]
F -->|患者日志| I[Odoo历史记录]
G --> I
H --> I
I -->|经验反馈| B
classDef propone fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#e2e8f0;
classDef humano fill:#052e16,stroke:#34d399,stroke-width:1px,color:#e2e8f0;
classDef registra fill:#3d1a00,stroke:#fbbf24,stroke-width:1px,color:#e2e8f0;
class A,B,C,D propone
class E,F,G,H humano
class I registra
图示:紫色方框代表系统提议的内容;绿色方框代表人工决定的内容;琥珀色方框代表诊所记录的内容。没有任何事件在未经人工决定的情况下从紫色跳转到绿色。
可观察到的运营效益
以下内容不涉及营收数字或四舍五入的ROI。这些是因为系统存在而存在的可验证机制。
系统化覆盖。 临床权重最高的十五种治疗各有专属规则。在系统出现之前,随访覆盖率取决于团队的记忆。现在有一个列表,可编辑,可审计。
具有人工决策的漏斗。 临床团队在单一列表中看到所有提议的随访,按建议日期排序。联系决定是明确的:批准、取消或保留审核中。与患者的对话永远不会自行触发。
按患者可追溯。 每个事件与原始销售、所用治疗、建议日期、随访负责人、已发送邮件(如有)及Odoo中的发送状态相关联。当患者回诊时,历史记录在单一视图中呈现,而非分散在三个文件夹中。
零冷营销。 这个区别至关重要。该系统不发送推广信息。它向正确的人在其治疗周期的正确时刻发送个性化临床随访。我们对内部代理团队应用的"零虚构"纪律,在此转化为"每条消息背后必须有患者档案"。
可审计的日志。 完整记录可由任何授权人员从Odoo查询。如果诊所明天想了解为何某位患者未被联系,答案在记录中,而非在丢失的WhatsApp对话里。
真正积累的学习曲线。 每次取消都有理由。每次发送都有日期。三个月后,临床团队可以读取以前只存在于直觉中的模式:哪些治疗产生最多假阳性,哪个窗口对某种治疗效果最好,在周期的哪个时间点某类患者倾向于继续或放弃。
其他诊所可以借鉴的经验
Nova House的经验可以复制。如果您的诊所、药房或门诊正在考虑类似系统,以下是六个具体步骤:
- 列出临床上需要随访的治疗清单。 不是商业清单,是临床清单。它比看起来要短;Nova House只有十五种。
- 按治疗设置联系窗口。 不要采用单一全局窗口。十天、五天和零天是三种不同的节奏,服务于三种不同的决策。
- 在编写任何代码之前建模生命周期状态。 待审核、审核中、已批准、已发送、已取消、有问题。这套词汇是系统的一半。
- 将人工关卡置于核心。 未经临床团队成员批准,任何内容都不应发送给患者。这个纪律不是可选的,它就是系统本身。
- 将日志保存在销售记录所在的同一位置。 Nova House使用Odoo。也可以是其他ERP,但不能是单独的电子表格。可追溯性在技术切换中丢失。
- 与发送量一样重视取消量。 好的随访系统不是最大化发送量,而是最大化明确的临床决策量。
结语:从直觉关怀到系统化关怀
在美容诊所中,"运营关怀"是一个真实的概念。它是在正确时间向正确的人发送正确的信息。在这样的系统出现之前,这种关怀取决于团队周一早晨的状态。有了系统之后,仍然取决于团队,但每天都有一份等待他们的清单,日期已经计算好,临床窗口已经建议,人工关卡完好无损。
诊所不是将关系交给软件。软件将诊所用于记住谁需要被联系以及原因的时间还给了诊所。患者收到真正的随访,而非伪装的推广。诊所逐次积累,一份明天可以阅读的日志。
如果您的诊所正在考虑构建类似的系统,对话从[email protected]开始。我们带来系统和协议。您带来临床实践。
关于准确性和隐私的说明
本文发布的数据(1540个事件、56天、按状态和窗口的分布、十五条活跃规则)于2026年7月8日直接从Nova House的Odoo实例读取。没有任何数字经过四舍五入或估算。没有读取或引用任何患者姓名、电子邮件、地址或个人数据;仅使用聚合数据。本文经Nova House商业授权使用其名称发布。
案例可验证参考:
- 客户:Nova House,RFC
GDO1702205GA,网站https://nova-house.mx。 - Odoo自定义模型:
x_treatment_followup_event,以x_treatment_followup_rule作为治疗目录。 - 系统中观察到的第一个事件日期:2026-05-08。
- 撰写本文时系统中观察到的最后一个事件日期:2026-07-03。