电商AI客服如何实现主动促单？从意图识别到销售型Agent的架构设计

原创

CallFay云起未来

发布于 2026-09-07 18:14:19

970

摘要

传统电商客服系统主要解决“用户提出问题后如何快速回答”，典型场景包括商品参数、库存、物流、优惠和售后规则查询。

但在真实购物过程中，用户通常不会按照固定FAQ完成购买，而是经历“了解商品—比较商品—确认需求—消除顾虑—确认交易条件—下单”的连续决策过程。因此，当智能客服从被动问答进一步进入售前场景后，系统需要解决的新问题是：如何识别用户当前购买阶段，并在合适的节点执行商品推荐、信息补充、促单或人工接管。

从工程实现角度看，这类能力并不是简单增加几条“催单话术”，而是需要将多轮上下文、RAG知识检索、购买意向识别、Next Best Action、业务工具调用和人工路由组合成完整链路。当前腾讯云开发者社区关于智能客服Agent的实践也普遍将上下文管理、知识检索、业务API和人工接管作为完整客服智能体的重要组成部分。(腾讯云开发者)

一、为什么传统FAQ架构难以承担“促单”任务

传统客服机器人通常采用类似流程：

用户问题
   ↓
意图识别
   ↓
FAQ / 知识检索
   ↓
生成答案
   ↓
返回用户

对于标准问题，这种模式基本够用。

例如：

用户：今天能发货吗？
客服：可以。

用户：黑色有库存吗？
客服：有。

用户：支持退货吗？
客服：支持。

从问答准确性看，每一次交互都完成了任务。

但从销售过程看，系统实际上没有识别一个重要事实：

用户已经连续确认库存、物流和售后，购买阶段可能已经从“商品了解”进入“交易确认”。

因此，销售型客服Agent首先需要改变的是处理对象：

传统客服：
Query → Answer

销售型Agent：
Conversation → State → Decision → Action

后者关注的不只是“这一句话应该怎么回答”，而是“这一轮对话结束后，下一步应该做什么”。

二、第一层：建立购买阶段状态模型

要判断什么时候适合主动服务，可以先对用户购买阶段进行状态建模。

例如：

S0 浏览阶段
   ↓
S1 商品了解
   ↓
S2 商品比较
   ↓
S3 需求匹配
   ↓
S4 顾虑处理
   ↓
S5 交易确认
   ↓
S6 下单

假设出现下面一组连续对话：

用户：A和B有什么区别？
用户：第二款适合宿舍吗？
用户：我预算1000左右。
用户：那第二款今天有货吗？
用户：现在有没有优惠？

单独分析每句话，可以得到：

商品比较
商品推荐
预算约束
库存查询
优惠查询

但结合上下文，实际上可以得到更有业务价值的状态：

{
  "stage": "交易确认",
  "intent_level": "high",
  "product": "SKU-B",
  "scenario": "宿舍",
  "budget": "1000左右",
  "pending": "优惠信息"
}

此时系统的下一步动作，就不应该再回到基础商品介绍。

三、第二层：购买意向不能只依赖关键词评分

一个比较简单的实现方案，是给不同问题设置权重：

询问商品参数 +5
比较SKU      +10
提供预算      +15
询问库存      +15
询问物流      +15
询问优惠      +20
询问售后      +10

达到某个阈值以后，将用户标记为高意向。

这种规则可以用于早期系统，但容易出现误判。

例如：

用户：多少钱？
客服：999元。
用户：太贵了，不考虑了。

如果只统计“询价”，意向分数可能增加。

但“太贵了，不考虑”实际上已经出现明显退出信号。

因此更合理的方式是综合多个特征：

PurchaseIntent =
    CurrentIntent
  + ConversationContext
  + ProductFocus
  + DecisionStage
  + BehavioralSignal
  - NegativeSignal

意向值应该随着对话实时更新，而不是一次判断后固定不变。

四、第三层：识别“为什么还没有下单”

识别高意向以后，并不意味着系统应该立即发送促单话术。

还需要判断用户当前的Decision Blocker。

常见阻力可以抽象为：

PRICE          价格
PRODUCT_FIT    商品适配
COMPARISON     SKU选择
DELIVERY       物流时效
TRUST          商品/品牌信任
AFTER_SALES    售后风险
PROMOTION      优惠条件
UNKNOWN        暂无法判断

例如用户连续询问：

“后面还有活动吗？”
“现在是最低价吗？”
“还有其他优惠券吗？”

当前阻力更可能是PRICE/PROMOTION。

而另一位用户连续询问：

“老人能用吗？”
“操作复杂吗？”
“字体能调大吗？”

主要阻力则可能是PRODUCT_FIT。

如果第二类用户不断收到优惠信息，虽然系统在“主动营销”，实际上并没有解决影响购买的问题。

所以主动促单的前提应该是：

先识别阻力 → 再决定动作

而不是：

识别高意向 → 立即催单

五、第四层：通过Next Best Action决定下一步动作

在购买阶段和决策阻力确定后，可以增加Next Best Action模块。

例如定义：

ANSWER             回答当前问题
ASK                 补充询问需求
COMPARE             对比商品
RECOMMEND           推荐商品
EXPLAIN_PROMOTION   解释优惠
EXPLAIN_POLICY      解释售后规则
CHECK_INVENTORY     查询库存
CHECK_DELIVERY      查询物流时效
TRANSFER            转人工
WAIT                暂不主动推进

完整处理链路可以设计为：

用户消息
   ↓
意图识别
   ↓
上下文读取
   ↓
购买阶段判断
   ↓
成交阻力识别
   ↓
Next Best Action
   ↓
RAG / 商品库 / 业务API
   ↓
规则与风险校验
   ↓
生成回复
   ↓
继续AI处理 / 转人工

这种架构的核心并不是让大模型自由决定如何“卖货”，而是在可控动作集合中进行决策。

腾讯云公开的电商客服Agent实践同样强调，Agent与传统聊天窗口的重要区别之一，是在授权范围内调用商品、订单等业务接口执行任务。(腾讯云开发者)

六、第五层：促单必须建立在真实商品知识上

AI客服越主动，对知识准确性的要求越高。

普通FAQ回答错误一次，可能只是一次咨询体验问题。

但如果AI主动推荐错误SKU、错误优惠或不存在的服务，可能直接进入交易和售后链路。

因此，商品事实不建议完全依赖模型参数记忆。

可以设计：

             ┌→ 商品知识库
             ├→ SKU数据库
用户问题 → Agent ┼→ 库存接口
             ├→ 优惠规则
             ├→ 物流接口
             └→ 售后规则

例如用户说：

“我主要出差办公，A和B哪个更合适？”

Agent负责理解：

需求 = 出差办公
任务 = SKU比较

RAG或商品数据库负责提供：

A重量
B重量
尺寸
接口
续航
兼容性
其他真实规格

最后再根据检索结果生成推荐。

这种“模型负责理解、业务数据负责事实”的分工，可以降低无依据推荐的风险。腾讯云公开的智能客服产品与社区实践也将LLM、RAG、工作流/API调用和多轮上下文作为复杂客服场景的重要组成部分。(腾讯云)

七、从被动问答到主动促单，还需要Tool Calling

如果Agent只能生成文字，它的主动服务能力仍然有限。

真实电商流程可能需要调用多个业务工具：

商品搜索
SKU查询
库存查询
优惠查询
订单查询
物流查询
会员权益
售后系统
人工坐席

例如：

用户：黑色今天能发吗？

理想流程不是让大模型根据知识库猜测，而是：

识别SKU
  ↓
调用库存接口
  ↓
查询发货规则
  ↓
获得真实结果
  ↓
生成回答

因此，销售型Agent实际上是：

LLM
+ RAG
+ Dialogue State
+ Business API
+ Workflow
+ Human Handoff

而不只是一个更大的语言模型。

八、“会挽单”也应该采用同一套判断机制

除了售前促单，另一类场景是用户已经加购或产生购买意向，但最终没有继续。

此时不应该默认：

未付款 → 发优惠券

而应该先判断流失原因。

例如：

价格问题 → 检查真实优惠
物流问题 → 查询实际时效
SKU犹豫 → 重新比较商品
售后担忧 → 解释对应政策
明确放弃 → 停止触达

因此，挽单本质上仍然是：

状态识别
  ↓
阻力判断
  ↓
动作选择

而不是简单增加触达频率。

九、AI越主动，权限控制越重要

从自动回答升级到业务执行后，风险边界也必须同步建立。

例如用户提出：

“再便宜50元我就买。”

系统可能识别为高意向+价格阻力。

但这并不意味着AI可以直接承诺降价。

可以增加权限判断：

if action.requires_authorization:
    transfer_to_human()

elif knowledge_confidence < threshold:
    transfer_to_human()

elif risk_level == "high":
    transfer_to_human()

else:
    execute_action()

以下场景通常需要重点设置人工兜底：

特殊价格
额外优惠
异常订单
复杂退款
赔偿协商
投诉争议
规则冲突
低置信度回答

因此，人机协同并不是AI能力不足后的补救方案，而应该直接作为Agent架构的一部分。腾讯云开发者社区的相关实践也将低置信度、复杂问题、情绪升级、重复失败和业务关键问题作为人工接管的重要判断因素。(腾讯云开发者)

十、多平台电商还需要统一会话层

对于同时经营多个电商渠道的商家，还存在另一个工程问题：

不同平台分别部署客服逻辑，会产生知识重复维护、会话分散以及人工后台频繁切换等问题。

因此可以增加统一接入层：

平台A ─┐
平台B ─┤
平台C ─┼→ 会话接入层
平台D ─┤       ↓
平台E ─┘  上下文/意图识别
               ↓
          AI Agent
        ↙      ↓      ↘
      RAG    业务API   人工坐席

这样商品知识、意图模型、路由规则和人工接管机制可以尽可能统一维护。

实际产品中，例如CallFay母语AI将多平台消息聚合、商品知识学习和AI自动接待放在同一客服链路中，可以作为这一类架构的实现思路之一；但具体促单效果仍然需要基于商家的真实历史会话和成交数据进行验证。(腾讯云开发者)

十一、上线前不要只测试“回答准不准”

如果系统目标包含销售辅助，仅测试FAQ准确率是不够的。

建议构建多轮测试集：

Case 1：商品了解
Case 2：两个SKU连续比较
Case 3：明确预算后的商品推荐
Case 4：价格敏感用户
Case 5：物流时效敏感用户
Case 6：高意向但未成交
Case 7：需要人工权限
Case 8：明确拒绝购买

例如：

A和B有什么区别？
↓
我主要放宿舍。
↓
预算1000左右。
↓
那第二款是不是更适合？
↓
今天买什么时候发？
↓
现在还有优惠吗？

重点检查：

上下文有没有丢失
购买阶段有没有发生变化
阻力识别是否正确
推荐依据是否来自真实商品知识
Next Best Action是否合理
需要人工时有没有及时转接

这比单独询问几十个FAQ，更接近真实业务。

十二、上线后的评估指标也需要调整

传统客服指标主要包括：

首次响应时间
自动回复率
AI独立解决率
转人工率

进入销售场景后，可以增加：

购买阶段识别准确率
高意向识别准确率
多轮上下文保持率
商品推荐继续咨询率
高意向用户转人工率
询单→下单转化
挽单后的继续购买情况
知识库未命中率
异常推荐率
越权操作率

这里尤其需要避免一个误区：

AI自动解决率越高 ≠ 销售效果越好

如果为了降低转人工率，让AI继续处理本应由人工完成的价格授权、复杂售后或高风险问题，自动化数据可能变好，但业务结果未必改善。

总结

AI客服从“自动回复”走向“主动促单”，技术上的核心变化不是增加更多营销话术，而是增加决策能力。

可以将整个链路概括为：

用户输入
   ↓
理解当前意图
   ↓
维护多轮上下文
   ↓
判断购买阶段
   ↓
识别成交阻力
   ↓
选择Next Best Action
   ↓
调用RAG / 商品数据 / 业务API
   ↓
权限与风险校验
   ↓
继续AI服务 or 人工接管

因此，“AI客服能否主动促单”并不是一个单独的生成式AI问题。

它实际上涉及会话状态管理、知识检索、意向判断、工具调用、权限控制和人机协同等多个模块。

只有先保证商品知识准确、业务权限可控、上下文连续，再让Agent判断什么时候推荐、什么时候补充信息、什么时候停止以及什么时候转人工，主动服务才有可能真正进入生产环境，而不是变成另一种形式的自动营销话术。

原创声明：本文系作者授权腾讯云开发者社区发表，未经许可，不得转载。

如有侵权，请联系 cloudcommunity@tencent.com 删除。

人工智能

媒体AI