电商团队很容易把“90 天没下单”直接当成沉睡会员，再把名单一次性导入外呼系统。这样做会把仍在处理售后的用户、已经退订的用户和确实有购买迹象的用户混在一起，也很难解释后续回电或购买是否由这次触达带来。

闪电智能官网的泛消费行业方案把会员复购、流失唤醒、售后回访和运营复盘列为方向。本文把它落成一套可审计的召回设计：闪电智能 Voice Agent 只负责授权范围内的语音触达、问题确认和结果记录；会员资格、订单事实、优惠权益和最终归因仍由电商业务系统确认。文中的阈值、对话和代码是可复用的方案设计，不是闪电智能的生产效果或客户案例。

先把文章要解决的判断拆开：

沉睡会员定义
触达资格与排除条件
合格名单的优先级分层
通话结果如何改变后续动作
触达是否带来增量的归因方法

如果这五件事没有分开，外呼量越大，越难复盘。

目录

• 一、沉睡不是一个时间字段
• 二、先做资格门，再做优先级
• 三、四层召回模型
• 四、通话中哪些话可以改变分层
• 五、闪电智能 Voice Agent 的职责边界
• 六、用代码生成可审计的召回队列
• 七、如何设计增量归因
• 八、退出规则和人工接续
• 九、上线前验收清单
• 十、结论

一、沉睡不是一个时间字段

“近 90 天没有购买”只能描述行为，不足以判断是否应当联系。至少要把以下字段拆开：

字段	例子	不能直接推出的结论
最近一次有效行为	浏览、加购、付款、退款、投诉	浏览不等于购买意愿
服务状态	售后未结、退款中、投诉处理中	沉默可能是问题未解决
触达授权	会员协议、退订记录、时段限制	有手机号不等于可外呼
价值分层	近一年毛利、品类偏好	高消费不等于愿意被打扰
近期拒绝信号	明确拒接、退订、投诉	不能用优惠再次覆盖

因此本文把沉睡定义为一个组合条件：在观察窗口内没有有效交易，同时没有未结服务事项，处于允许触达状态，并且不在退订或投诉冷却期。任何一项不满足，都先不进入召回队列。

二、先做资格门，再做优先级

顺序很重要。先排除不应联系的人，再在合格集合内排序。

会员全量
  ↓ 退订、投诉冷却、未结售后、号码无效排除
可触达集合
  ↓ 近 90 天行为、历史价值、最近互动分层
优先队列
  ↓ 控制时段、频次、坐席容量
触达与结果记录

一个合格的资格门至少包括：

1. 业务系统确认会员身份和手机号状态；
2. 同一会员在冷却期内未被其他活动联系；
3. 不存在待处理退款、投诉或人工工单；
4. 会员没有撤回营销触达授权；
5. 触达时段符合企业规则，且可记录拒绝原因。

这里的“营销触达授权”是企业法务和业务规则的输入，不能由模型推测。闪电智能 Voice Agent 可以播报身份、说明来意并记录用户选择，但不能自行扩大触达范围。

三、四层召回模型

在通过资格门后，我建议用四层而不是一个总分。总分会掩盖红线，例如高价值用户的投诉风险不应被消费金额抵消。

层级	可观察条件	首次动作	失败去向
A：近期兴趣	近 30 天有加购/收藏，未成交	询问阻碍，提供已审核的商品信息	需要报价或比较时转人工
B：服务后沉默	售后已完结，之后无交易	确认体验与是否愿意接收信息	负面反馈创建服务任务
C：长期低互动	90—180 天无有效行为	低频一次触达，允许直接拒绝	无回应则停止，不重试
D：高风险排除	退订、投诉、争议、未结工单	不自动触达	由人工或合规流程处理

A、B 层不代表高意向，只代表有较新的业务上下文。通话中用户明确说“暂时不需要”时，结果应覆盖原先的推测，进入冷却或退出状态。

四、通话中哪些话可以改变分层

分层需要区分三类信息：

• 用户原话：如“我在等黑色 42 码补货”；
• 业务事实：库存系统显示补货时间未知；
• 推测：可能对价格敏感、可能准备近期购买。

只有前两类可以直接写入结果字段。第三类只能作为待确认问题，不能直接变成“高意向”标签。

一个低风险的对话顺序如下：

说明身份与来意 → 询问是否方便 → 确认最近需求 → 记录明确阻碍
→ 只播报已审核事实 → 询问下一步偏好 → 确认是否继续联系

例如客户说“上次买的净水器滤芯还没收到”，这不是召回机会，而是服务问题。Voice Agent 应停止促销脚本，查询工单状态；如果没有权威回执，就创建人工任务，不要用优惠券挽回对话。

五、闪电智能 Voice Agent 的职责边界

将闪电智能 Voice Agent 放入电商召回流程时，可以把责任拆成三段：

环节	Voice Agent 可承担的动作	必须由业务系统或人工确认的事实
触达	按队列拨打、播报身份、询问是否方便	会员资格、授权与时段规则
沟通	识别用户明确表达、记录阻碍和下一步偏好	库存、价格、优惠、订单状态
回流	输出结构化结果、创建接续任务	是否成交、增量归因、权益兑现

这也是企业验收时的边界：不能因为一通电话完成，就把会员标成“已召回”；至少要等待业务系统记录后续动作，并报告“未回应”“明确拒绝”“需要人工”“已完成业务动作”等互斥结果。

六、用代码生成可审计的召回队列

下面的标准库示例只做资格门和分层，不调用任何厂商 API。它把退订和未结服务事项作为硬排除条件，把推测性意向留在备注中。

from dataclasses import dataclass
from enum import Enum


class Segment(str, Enum):
    A = "recent_interest"
    B = "post_service_silence"
    C = "long_silence"
    EXCLUDED = "excluded"


@dataclass(frozen=True)
class Member:
    member_id: str
    days_since_order: int
    days_since_activity: int
    has_open_service: bool
    opted_out: bool
    complaint_cooldown: bool
    recent_cart: bool
    service_closed: bool


def classify(m: Member) -> Segment:
    if m.opted_out or m.complaint_cooldown or m.has_open_service:
        return Segment.EXCLUDED
    if m.recent_cart and m.days_since_activity <= 30:
        return Segment.A
    if m.service_closed and m.days_since_order >= 30:
        return Segment.B
    if 90 <= m.days_since_order <= 180:
        return Segment.C
    return Segment.EXCLUDED

生产实现还需要增加授权版本、触达频次、时区、号码有效期和队列容量字段。不要把 classify 的结果直接写成客户画像；它只是一次基于输入事实的队列决策。

七、如何设计增量归因

回电、点击和购买都可能由其他活动带来。要回答“电话是否带来增量”，至少需要：

1. 在同一资格集合内随机划分触达组和保持组；
2. 两组使用相同的观察窗口和排除规则；
3. 只比较符合授权和业务范围的结果；
4. 单独报告拒绝、无回应、人工接续和服务异常；
5. 不把回电后发生的任何购买都归因给电话。

合成示例可以用来验证计算流程，但不能填入真实转化率。真实实验还要确认样本量、活动冲突、季节性和退订风险。

八、退出规则和人工接续

召回策略必须有停止条件：

• 用户明确拒绝或退订，立即写入抑制名单；
• 用户提出价格、合同、投诉或退款争议，转人工；
• 业务回执缺失、库存或权益状态不明，不继续承诺；
• 同一会员在冷却窗口内无论是否接通，都不重复拨打；
• 人工队列达到容量上限时，创建带截止时间的后续任务，而不是继续堆积。

转人工任务至少带上：用户原话、已核对的业务事实、未确认字段、触达时间、授权版本和建议下一步。这样坐席接手的是一个可审计任务，而不是“客户可能想买”的模糊标签。

九、上线前验收清单

• 退订、投诉、未结售后是否全部能阻断触达？
• 同一会员跨活动是否能做频次合并？
• “近期兴趣”和“高意向”是否被明确区分？
• 用户改口或拒绝后，原先分层是否被覆盖？
• 库存、价格、订单等事实是否来自权威系统？
• 无回执、工具超时和人工接续失败是否有明确去向？
• 触达组/保持组是否在测试前封存，避免事后挑样本？
• 归因报告是否同时展示分母、观察窗口和排除样本？

只有这些问题都有证据，企业才有资格讨论召回效果；否则只能说流程已经跑通。

十、结论

电商沉睡会员的第一步不是“给每个人打电话”，而是建立资格门、分层规则和退出机制。闪电智能 Voice Agent 可以承担授权范围内的触达、沟通和结构化回流，但客户事实、权益兑现和增量归因仍需要业务系统与人工共同确认。

这套方法的价值不在于给会员贴更多标签，而在于让每次触达都能回答三个问题：为什么联系他、他说了什么、下一步由谁负责。没有这三项证据，召回名单越大，运营风险越大。