客户表达不满之后，企业往往并不缺数据：通话转录里有投诉原因，CSAT 里有满意度评分，CRM 里有客户价值。真正拖慢响应的是这些信号散落在不同系统中，需要人工筛选、判断优先级，再逐封起草挽留邮件。
Amazon Quick 中的客户留存工作流提供了另一种组织方式：用无代码流程汇集通话转录和 CSAT 数据，识别有流失风险的客户，通过自定义 MCP Action 计算挽留优先级，再生成个性化挽留信。这里的关键并不是单独使用一次大模型，而是把“发现、排序、生成、审核”串成一条可重复执行的流水线。
一条可落地的留存流水线
可以把整个流程拆成四个节点：
- 读取客户信号：输入通话转录、CSAT 分数、客户标识，以及业务允许使用的客户价值字段。
- 判断流失风险：从转录中识别取消意图、重复投诉、问题未解决等信号，并结合低 CSAT 分数形成结构化结果。
- 调用自定义 MCP Action 排序：将风险、客户价值和问题严重程度转成可解释的挽留优先级。
- 生成并审核挽留信：根据客户遇到的具体问题生成草稿，经客服或客户成功团队确认后发送。
建议让节点之间传递结构化对象，而不是不断转交大段自然语言。例如，中间结果可以约定为：
{
"customer_id": "C-1042",
"csat": 2,
"signals": {
"cancel_intent": true,
"unresolved_issue": true,
"repeat_contact": 2
},
"customer_value": 0.8,
"summary": "客户连续两次联系支持团队，账单争议仍未解决，并明确提到取消服务。"
}
结构化输出有两个好处：评分动作不必重新理解整段通话，运营团队也能检查某位客户为何被排在前面。对于自动化留存流程，可解释性往往比复杂但不可追踪的评分更有价值。
MCP Action 负责把“高风险”变成“先处理谁”
只判断客户有风险还不够。客服团队的处理能力有限，因此流程需要回答一个更实际的问题：今天应该先联系谁？
自定义 MCP Action 可以承载这类企业专属逻辑。例如，评分可同时考虑：
- 是否明确表达取消意图；
- 问题是否尚未解决；
- 是否多次联系支持团队；
- CSAT 是否明显偏低；
- 客户价值或合同重要性。
下面是一个可以直接运行并改造的最小评分服务。它演示的是业务评分逻辑；实际接入 Amazon Quick 时，需要按照所配置的自定义 MCP Action 契约封装工具名称、鉴权方式和请求格式。
先安装依赖：
python -m venv .venv
source .venv/bin/activate
pip install flask
保存为 retention_action.py：
from flask import Flask, jsonify, request
app = Flask(__name__)
def clamp(value, minimum=0.0, maximum=100.0):
return max(minimum, min(maximum, value))
@app.post("/score-retention")
def score_retention():
data = request.get_json(force=True)
signals = data.get("signals", {})
csat = float(data.get("csat", 5))
customer_value = float(data.get("customer_value", 0.0))
repeat_contact = int(signals.get("repeat_contact", 0))
score = 0.0
reasons = []
if signals.get("cancel_intent"):
score += 35
reasons.append("客户表达了取消意图")
if signals.get("unresolved_issue"):
score += 25
reasons.append("问题尚未解决")
if repeat_contact > 1:
score += min(15, (repeat_contact - 1) * 5)
reasons.append("客户重复联系支持团队")
if csat <= 2:
score += 15
reasons.append("CSAT 较低")
elif csat == 3:
score += 8
score += clamp(customer_value, 0, 1) * 10
score = round(clamp(score), 1)
if score >= 75:
priority = "critical"
response_sla_minutes = 30
elif score >= 50:
priority = "high"
response_sla_minutes = 120
elif score >= 25:
priority = "medium"
response_sla_minutes = 480
else:
priority = "low"
response_sla_minutes = 1440
return jsonify({
"customer_id": data.get("customer_id"),
"retention_score": score,
"priority": priority,
"response_sla_minutes": response_sla_minutes,
"reasons": reasons
})
if __name__ == "__main__":
app.run(host="0.0.0.0", port=8080, debug=False)
启动并测试：
python retention_action.py
curl -s http://localhost:8080/score-retention \
-H 'Content-Type: application/json' \
-d '{
"customer_id": "C-1042",
"csat": 2,
"customer_value": 0.8,
"signals": {
"cancel_intent": true,
"unresolved_issue": true,
"repeat_contact": 2
}
}'
该请求会返回分数、优先级、建议响应时限和评分原因。生产环境中还应补上身份认证、输入校验、审计日志、超时与重试策略，并避免在日志中写入完整通话内容或其他敏感信息。
评分权重也不应该一经设定就长期不变。可以定期比较“高分客户是否真的流失”以及“采取挽留措施后是否留下”，据此校准阈值。否则，工作流可能只是在更快地放大一套未经验证的规则。
个性化挽留信要受事实约束
生成挽留信时，提示词需要明确限定可用事实，避免模型虚构退款、折扣、服务承诺或问题解决状态。可以在 Quick 的生成步骤中采用类似下面的模板，并按实际字段名称调整：
你是客户成功团队的邮件助手。请根据输入数据起草一封简洁、真诚的客户挽留信。
必须遵守：
1. 只使用输入中明确提供的事实。
2. 不得承诺未提供的退款、折扣、赔偿或解决时间。
3. 明确复述客户的核心问题，但不要复制敏感通话原文。
4. 给出一个清晰的下一步行动。
5. 如果缺少可执行方案，输出“需要人工补充方案”，不要自行编造。
输入：
- 客户称呼：{{customer_name}}
- 问题摘要：{{summary}}
- 优先级：{{priority}}
- 可提供方案：{{approved_offer}}
- 负责人：{{owner_name}}
输出：
- 邮件主题
- 邮件正文
- 需要人工确认的事项
这里应坚持“生成草稿，而不是直接发送”。尤其当信件涉及退款、合同变更、监管投诉或高价值客户时，人工审批节点不能省略。自动化适合减少资料整理和初稿撰写时间，不适合替代授权决策。
从试点走向生产的检查清单
这类流程可以把原本按天计算的响应周期压缩到分钟级，但上线速度不应以牺牲治理为代价。实施时可以逐项检查：
- 数据最小化：只向评分和生成节点提供完成任务所需的字段。
- 访问控制：限制谁能查看转录、修改评分规则和批准挽留方案。
- 评分透明度：保存分数、原因、规则版本和人工处理结果。
- 人工兜底：高优先级、低置信度或涉及财务承诺的案例必须转人工。
- 效果衡量：同时跟踪首次响应时间、人工处理量、实际留存率、误报率和客户投诉。
- 失败策略：MCP Action 超时或返回异常时，不要悄悄丢弃客户，应进入待人工处理队列。
更稳妥的采用方式，是先选择一个产品线或客服队列进行只读试点：系统给出风险和优先级建议，但不自动联系客户。验证评分与人工判断大体一致后，再开放信件草稿生成，最后才考虑对低风险、低承诺场景提高自动化程度。
Amazon Quick 在这个场景中的价值，是把散落的数据、企业评分逻辑和生成式能力编排为一条可观察的业务流程。真正决定效果的，则是清晰的数据契约、可解释的优先级规则，以及在关键承诺前保留人工判断。