美洽满意度评价怎么自动触发？
要自动触发美洽的满意度评价，通常有四条主线路：在管理后台通过“会话结束/工单关闭后自动弹评”配置；在前端或移动端通过 SDK 在会话结束时主动调用评价接口；在后端监听会话状态变更（Webhook/回调）然后调用发送评价消息；或在业务事件（如订单完成、退款处理）发生后由后端定时或即时触发评价请求。关键在于选对触发时机、设置合理的延时与频率限制，并确保消息渠道（客服会话、公众号模板消息、推送）和埋点/存储都能正确接收与记录评价结果。
用一句话把问题拆开：满意度评价可以什么时候、怎么发出？
想象你是餐厅经理：客人离开时，你可以立刻问“今天满意吗？”，也可以等他回去半小时发条短信，或者等后台发现订单已完成再推一条评价邀请。美洽里也一样——评价的触发既可以由平台配置自动弹出，也可以由你的代码或后端事件主动发起，消息送达的形式（会话消息、公众号模板、App推送）和时机决定了用户是否愿意去打分。
三类触发方式（概念化）
- 平台自动规则：通过美洽管理后台配置“结束会话后自动弹出评价”或类似规则。
- 前端/SDK 主动触发：在 Web/APP 会话结束处调用 SDK 的方法让评价面板出现。
- 后端/事件触发（API/Webhook）：后端监听订单/工单/会话状态，用 API 发送评价消息或通过 Webhook 推送到美洽触发。
为什么有这么多方式？选择依据是什么？
不同业务对时机和体验有不同要求。若你追求“高响应率且与会话紧密关联”，用平台自动弹出或 SDK 触发最好；若你想把评价和订单/售后流程绑定（例如收货后 48 小时发），就更倾向后端事件驱动。还有资源和权限考量：不想改代码就用后台配置；想自定义文案/采样逻辑就走 API。
常见场景与推荐触发策略
- 即时会话满意度：会话关闭后 0–30 秒弹出，使用平台或 SDK。
- 订单/售后满意度：订单确认收货后 24–72 小时由后端调用 API 触发评价。
- 电话或工单转写后：工单状态变更为“已完成”时触发。
- 抽样评价：为了避免打扰，可通过后端按比例抽样后调用评价接口。
一步步实现：从最简单到更复杂的做法
第一步：用管理后台快速开启（最省力）
多数企业会先检查美洽管理后台有没有“满意度/评价”相关的开关或自动化规则模块。一般流程是：
- 在“自动化/设置/满意度”里打开“会话结束后弹评”或类似选项；
- 设置弹出延时（立即、10s、1min 等）；
- 配置评价模板（文案、星级或文字评价）；
- 打开是否仅对访客、仅对关闭工单、或仅对移动端触发的条件；
- 保存并测试一个会话结束流程，观察是否弹出并记录结果。
第二步：前端/SDK 主动触发（可控性强）
如果你能修改前端代码，SDK 触发允许在精确的用户行为点出现弹窗（例如用户点击“结束会话”后）。伪代码流程看起来像这样：
// 伪代码示例（SDK 接口名示例化）
sdk.onChatEnd(function(sessionId){
sdk.openSatisfactionPanel(sessionId, {
template: 'star+comment',
delay: 2000
});
});
这种方式的优点是能把评价时机同 UI 行为绑定，缺点是需要改前端并兼顾不同平台的 SDK 行为。
第三步：后端事件驱动 + API（最灵活）
后端触发适用于把评价和业务事件（订单、退款、服务完成）绑定的场景。关键是：
- 监听业务事件（消息队列 / 数据库状态 / 第三方回调）；
- 满足触发条件后调用美洽的“发送消息/邀请评价”接口（或调用客服会话消息接口发送一个包含评价链接/卡片的消息）；
- 记录发送记录，处理回调（用户评价时美洽回调你的 webhook）。
伪代码：
// 后端伪代码
if (order.status == 'DELIVERED' && daysSinceDelivery >= 2 && !alreadyAsked(order.user)) {
callMeiqiaApi.sendSatisfactionInvite(userId, {
mode: 'chatMessage', // 或 'miniProgram', 'templateMsg'
templateId: 'tpl_123',
variables: {orderId: order.id}
});
markAsked(order.user);
}
触发策略细节与注意点（这是决定成功率的关键）
- 合适的延时：太快，用户可能还在忙；太慢，用户遗忘或离线。常见延时：即时弹窗 0–30 秒；订单类 24–72 小时。
- 频率控制/采样：避免频繁骚扰同一用户，常用做法是同一用户 7 天内只问一次，或按 10% 抽样。
- 分渠道文案优化：公众号模板、聊天消息或 App 推送对文案和交互的支持不同，需分别设计。
- 多语言与本地化：根据用户语言环境呈现本地化文案。
- 后备方案和兜底：若用户未在消息中完成评价，可通过邮件/短信二次邀请（注意隐私与频次）。
- 合规与隐私：收集评价可能涉及个人数据，确保数据存储和展现符合法规与平台条款。
评价样式与数据结构（典型字段）
不同企业会选择星级、评分或 NPS 类问题。典型数据字段包括：
- sessionId / ticketId / orderId
- userId / visitorId / openId
- score（数值或枚举）
- comment（文本）
- tags（可选，客服可选标签）
- timestamp
| 触发类型 | 优点 | 缺点 |
| 平台自动规则 | 省力、上线快 | 定制化有限 |
| 前端/SDK触发 | 时机精准、体验好 | 需改前端、多端维护 |
| 后端事件触发/API | 最灵活，可与业务深度绑定 | 需要后端开发与稳定的回调处理 |
具体实现示例（分渠道）
Web 聊天场景（用 SDK）
- 在会话结束事件点调用 SDK 的“打开评价面板”接口；
- 如果用户未操作，2 分钟后发一条会话消息带评价按钮；
- 评价回填后，调用后端 API 存储并触发告警（若低分）。
微信公众号 / 小程序 场景
- 利用公众号模板消息或小程序卡片发送评价邀请；
- 若用户在客服会话中，优先用会话内卡片，能提高填写率；
- 注意模板消息有发送限制与订阅规则。
App 场景（推送 + 原生弹窗）
- 可在 App 内使用本地弹窗（触达率高），或在用户打开 App 时弹出；
- 若离线，使用推送作为补救，但推送打开率较低。
常见问题与排查清单（别慌，按步骤来）
- 未弹出评价：确认是否开启了平台自动弹评或 SDK 调用被执行；检查是否有权限或配置误设（仅对游客/已登录用户触发）。
- 用户看不到评价按钮：可能是渠道不支持该类型消息，或模板 ID 配置错误，检查消息类型和变量。
- 回调未收到评价数据：查看 webhook 地址是否正确、验证签名是否通过、服务器是否可达。
- 重复触发：检查频率控制逻辑，是否多处业务都触发了“发评价”的代码。
- 低完成率：优化文案、缩短表单、调整触发时机、改用更友好的交互形式。
实战小贴士（经验流）
- 先小规模试验：在真实用户群中做 A/B 测试（时机、文案、渠道），再全量推广。
- 主动跟进低分用户：把低分自动转为工单或触发客服回访，避免流失或差评扩散。
- 把评价变成改进环路：把评价数据和客服话术/产品数据打通，形成闭环改进。
- 日志与监控：记录每一次评价邀请的发送时间、渠道、结果，以便分析漏斗。
技术样例（伪 API 流程图解）
这里用伪接口描绘典型后端触发流程：事件 -> 后端判断 -> 调用美洽发送评价消息 -> 用户评价 -> 美洽回调你的 webhook -> 你存储并触发后续动作。
// 触发示例（伪代码）
onOrderDelivered(order) {
if (shouldAsk(order.user)) {
meiqia.sendSatisfactionInvite({
userId: order.userId,
mode: 'chat', // 或 'template'
templateVars: {orderNo: order.id}
});
db.recordInvite(order.id, now());
}
}
onMeiqiaWebhook(payload) {
if (payload.type == 'satisfaction_submitted') {
db.saveSatisfaction(payload.data);
if (payload.data.score <= 2) escalateToAgent(payload.data);
}
}
衡量效果：指标与分析
- 发送率：邀请被成功送达的比率；
- 完成率：收到评价占发送邀请的比率；
- 平均分/分布：满意度的核心指标；
- 响应时间：从邀请到评价的平均耗时；
- 转化率差异：不同触发时机/文案带来的结果差异（A/B 测试指标）。
容易忽略但很重要的细节
- 跨渠道身份识别：同一用户在公众号/网站/APP 的 visitorId 可能不同，合并口径影响数据准确性。
- 界面层级问题：在 Web 上如果评价 UI 被其它 modal/iframe 覆盖，会导致看不到或无法点击。
- 本地化时间：注意触发时间以用户时区为准，免得半夜打扰。
- 系统退路：评价发送失败时要有重试机制并记录失败原因。
最终一句话（像和同事聊完想到的）
搞自动触发评价，不是把按钮塞进去就完事，而是要把“什么时候问”“怎么问”“对谁问”“如果回答差怎么处理”这四个问题串起来：选对触发方式（后台规则、SDK、后端事件），设置合理的节律与兜底，再把数据埋点与告警做好，才能既拿到高质量反馈，又不伤用户体验。好，写到这儿，我还想起一个场景没提到——多语言的 A/B 文案测试，改天再细聊。