停售前存量加仓申请范围归属：该谁接更清楚

这个案例来自 金融服务 场景。

金融产品进入停售窗口时，
最容易让前线头疼的不是“全面停售”这种一刀切场景，
而是那批卡在边界上的申请：

客户是老持有人
申请在停售前发起
资料在停售后才补齐
系统里一部分状态留在旧口径，一部分已经切到新口径

这时候最难回答的一句就是：

“这笔到底算不算还能按旧口径受理？”

如果没有清楚的归属判断和生效边界，
前线最容易和客户一起陷进拉扯里。

为什么停售窗口最容易出现“边界单”

这家机构代销一款固收类产品。
某次因为额度用尽和产品调整，
总部要求在某天 18:00 后停止新增认购和加仓。

问题在于，停售前后自然会出现一批边界申请：

客户 17:40 提交加仓意向
18:10 才补齐确认材料
客户经理 18:20 才录入系统

客户会觉得：

我明明是停售前发起的

后台则会看到：

正式受理节点已经落在停售后

如果没有结构化判断，
每一笔边界单都可能变成一次临时争论。

旧流程为什么总在边界期最容易打架

1. “发起时间”和“正式受理时间”经常不是同一个节点

客户和前线常按发起时间理解，
后台和运营常按资料齐备或入系统时间理解。

2. 存量客户与新客户口径可能不同

某些产品会允许：

存量客户继续小额加仓

但不允许：

新客户新开仓

如果范围归属不清，现场就很容易混。

3. 停售窗口里常伴随临时通知

总部通知、区域解释、系统拦截时间，
不一定完全同步，
更容易让前线误判。

改造前的旧流程简图

flowchart TB
    A[产品进入停售窗口] --> B[客户在边界时间提交加仓申请]
    B --> C[前线 后台和运营按不同节点理解规则]
    C --> D[申请到底算旧口径还是新口径反复争论]
    D --> E[客户体验和合规边界同时承压]

派宝怎么把“这笔到底归哪条线”先说清楚

派宝做的不是替机构决定产品是否停售，
而是把边界申请当前应归属到哪套规则链先判断清楚。

1. 先判断当前对象是否属于允许加仓的范围

系统会先看：

是否为存量持有人
当前产品和客户关系
是否命中特定例外范围

2. 再判断关键时间点

派宝会继续拉清：

客户发起时间
资料齐备时间
系统录入时间
正式受理时间

3. 再做归属与优先级判断

真正关键的，不是知道时间很多，
而是明确：

当前按旧口径受理
当前已进入新口径拦截
当前属于灰区，需升级确认

4. 最后把当前解释口径同步给前线

这样客户经理拿到的不是一句“先等等看”，
而是一份能向客户说明的判定依据。

改造后的新流程

flowchart TB
    A[客户加仓申请 产品停售通知和关键时间戳进入系统] --> B[适用范围命中校验能力<br/>判断客户是否属于允许加仓的对象范围]
    B --> C[变更窗口判断能力<br/>识别关键发起 受理和截止节点]
    C --> D[范围归属判定能力<br/>明确当前申请归属旧口径还是新口径]
    D --> E[规则优先级裁定能力<br/>处理临时通知与原规则冲突]
    E --> F[减少停售边界单争议]

上线后的变化

连续运行一段时间后，团队最明显的感受不是边界申请消失了，
而是那类最容易扯皮的“停售前后卡线单”，终于更少再靠项目经理或运营临场拍板。

几个变化特别明显：

客户经理更快知道哪些单子还能推、哪些该及时止损
后台和运营对边界单的处理口径更一致
存量客户与新客户的适用边界更清楚
合规团队不必对每张边界单都做临时解释

项目复盘结果

以 4 次停售窗口、1,480 笔边界加仓申请为样本，项目复盘结果如下：

对比项	改造前	改造后
停售边界单处理口径不一致的情况	较高	下降约 58%
前线人工确认边界单可否受理耗时	很长	缩短约 47%
客户因边界期说法反复产生的不满	较多	明显下降
运营临时升级确认的边界单数量	较多	明显减少
停售窗口当天的应急沟通压力	偏高	明显缓和

这个案例的价值

这套做法在金融产品治理里站得住，不是因为它消灭了边界单，
而是因为它抓住了一个特别现实的问题：
真正消耗团队的，往往不是明确停售，而是那些卡在旧规则和新规则之间的申请。