摘要

口腔服务反馈的质量，取决于何时提问、问什么，以及能否识别反馈对应的服务场景。把所有问题集中到离店后的长问卷，容易失去预约、到店和沟通等环节的细节。体验家 XMPlus 提供 App、Web/H5 等嵌入式问卷能力，结合业务场景接入、全局免打扰和发送 ID 换卷机制，帮助口腔机构构建持续维护的反馈采集链路。本文重点说明业务上下文、触发条件、展示策略和配置更新如何协作，让每一条反馈更容易进入后续分析。

一、患者反馈为什么需要贴近服务触点

患者预约完成后，最容易评价的是预约是否顺畅；完成一次就诊后，能够评价的是到店引导、沟通与服务过程；离店后再进行随访，则可以了解信息是否清晰、联系是否便利。

这些问题对应不同时间和不同场景。如果统一发送“您对本次服务是否满意”，机构可能得到一个分数，却很难判断问题发生在哪里。对于需要多次到诊的服务，连续发送相同问卷又会增加患者负担。

体验家问卷收集 SDK 的应用，应从触点设计开始：在患者完成相应服务动作后，用适合当前场景的短问卷收集反馈，并保留后续分析需要的上下文。问卷展示是最后一步，业务事件和场景定义才是采集链路的起点。

二、技术链路：业务端提供场景，体验家组织反馈

一个可维护的嵌入式采集方案，可以拆成四个环节：

业务状态确认 → 场景与身份参数准备 → 问卷展示及免打扰判断 → 回答与上下文关联。

业务端需要判断患者是否真正完成预约、是否到达可评价的服务节点。SDK 的接入不能替代预约系统判断业务结果，也不能仅凭点击“提交”就认定预约成功。

口腔机构可以按以下方式设计上下文，实际参数名称与接入方式以所使用端的接口文档为准。

这些是实施设计建议，并非所有 SDK 自动产生的字段。机构应先定义分析需要的信息，再由业务系统提供能够准确回传的参数。

体验家支持在反馈收集过程中回传客户唯一标识，并可通过后续数据关联补充属性。采集时保留清晰的场景和记录关系，能够减少分析阶段反复追查“这条反馈到底来自哪里”的工作。

三、不同数字触点，选择不同展示方式

体验家的 App 嵌入支持弹窗和页面内置，支持单选、多选、文本、表情评价、打分评价及 NPS 等题型。Web/H5 页面嵌入提供弹窗、按钮和页面内置三种显示样式。

口腔机构可以根据实际渠道安排采集方式：

这些是可以按业务条件实施的场景，并非对某家口腔机构现有系统的描述。没有 App 的机构，可以围绕实际使用的 Web/H5 或其他适配渠道设计反馈入口。

展示形式也应服务于业务过程。预约尚未完成时，应优先保障预约；患者阅读服务信息时，可以保留自愿打开的反馈入口；需要即时了解某个已完成动作时，再设置相应邀请。

体验家将问卷嵌入到服务页面，价值在于缩短场景与反馈之间的距离。是否采用弹窗，仍应结合业务状态、患者操作和机构实际接入条件决定。

四、全局免打扰：统筹多个问卷与渠道

同一患者可能在预约页、App 和后续服务页面遇到不同问卷。若各个触点独立发送，短时间内可能重复邀请评价。

体验家的全局免打扰可以针对单问卷的多个渠道，或多个问卷及其渠道配置规则。在规则周期内，同一用户发生规定的弹出、显示、关闭或提交等行为后，可以限制其他相关问卷再次弹出，具体行为按所选规则设置。

对口腔机构而言，可以先把预约评价、到店评价和离店后服务评价纳入统一的邀请策略，再根据反馈目的决定周期与适用渠道。例如，某一轮体验监测结束后，是否需要暂缓其他常规邀请，应由机构确定。

频控能够发挥作用的前提，是相关渠道能够按接入方案正确识别同一用户。跨端标识不一致，就可能无法达到预期的联动效果。因此，验收不仅要看弹窗是否展示，还要检查同一用户在不同渠道的免打扰结果，以及关闭和提交行为是否按规则处理。

对需要多次到诊的患者，机构还应区分“同一次服务中的重复邀请”和“后续服务中有必要的新反馈”。规则周期应与监测目标配合，而不是机械套用统一时长。

五、发送 ID：让换卷与新增触点各归其位

口腔机构可能先上线预约反馈，随后调整问题表达、更新评价问卷。如果每次更换问卷都要求业务端修改埋点，会增加维护成本。

体验家的发送管理提供页面嵌入能力，可将发送 ID 嵌入原有接入位置，用其替代原先的问卷 ID 与渠道 ID。完成相应接入后，可以在体验家内更换问卷，而不必更换原有问卷埋点。

这一机制把稳定的业务触点与可调整的问卷配置分开：业务端负责让正确场景到达采集入口，体验家负责该入口对应的问卷管理。

需要区分两种更新：原有触点换用另一份问卷，可以利用已接入的发送 ID 机制；新增触点、增加业务判断或回传新的上下文字段，仍需业务端评估开发和接入工作。不能把换卷能力扩展为所有变化都无需开发。

六、应用设计：预约反馈如何进入改善链路

以一家提供线上预约的口腔机构为例，可以先在预约成功页面设置一份短问卷，询问预约整体感受，并对不满意的回答进一步收集原因。

业务端在确认预约成功后，提供场景和必要的记录关联信息；体验家按已配置的展示与免打扰规则收集回答。分析时，机构可以按门店、渠道或初复诊群体观察预约体验差异，并检查开放反馈中的时间选择、信息填写和确认说明等问题。

如果评论集中在“预约后不知道下一步做什么”，机构可以先调整确认页面的说明，再在后续同一触点观察反馈。若提出新的原因选项，需要记录问卷版本变化，避免把不同问法产生的差异直接解释为体验改善。

这是一个实施设计示例。它体现了体验家 SDK 的完整价值：把采集位置、业务上下文、问卷配置和后续分析连接起来，让反馈成为能够持续使用的数据。

七、上线验收：不仅验证能否弹出

建议围绕四类情况验收：业务动作未完成时是否误触发，反馈是否携带正确场景，跨渠道免打扰是否符合规则，发送 ID 换卷后原有入口是否按预期工作。

上线后，还应区分问卷展示、关闭、提交和有效回答；分析回收情况时，结合渠道与患者群体检查覆盖范围。回收更多回答只是采集结果，是否帮助改善服务，还需要看问题能否被定位和处理。

体验家问卷收集 SDK 帮助口腔机构把患者声音放回服务现场。当正确的问题出现在正确的触点，并携带可分析的上下文，机构才能从“收集意见”进一步走向“改进服务”。

FAQ

口腔机构没有 App，能使用体验家嵌入式问卷吗？

可以评估实际拥有的 Web/H5 页面。体验家提供相应的页面嵌入方式，具体接入条件需要结合机构渠道和接口文档确认。

SDK 会自动知道预约是否成功吗？

业务系统需要判断并提供相应场景。页面点击与预约成功不是同一个业务状态，触发设计应以实际结果为依据。

更换问卷后需要重新修改埋点吗？

完成发送 ID 机制接入后，可在原有触点更换问卷。新增场景或参数属于另一类变化，仍需业务端配合。

上一篇

下一篇