# 通知发错了？一键撤回——立刻智能体推送通知升级

来源: https://www.likelic.com/blog/notification-recall-and-attachments.html

自动通知最大的价值，是：

**不用等人手工转发。**

但自动化程度越高，也会带来一个新的问题：

**如果通知写错了怎么办？**

比如业务系统一次生成了几十个客户群的合同到期提醒。

刚提交出去，就发现：

价格写错了。

或者客户其实昨天已经续约。

又或者运营人员选错了目标客户。

这时候，通知可能还没有全部发出去。

一部分已经投递。

另外一部分还在等待发送窗口、限速排队或者任务调度。

以前遇到这种情况，通常只能：

看着错误消息继续发。

等全部发完。

再重新发一条：

> 抱歉，上一条通知有误，请以本条为准。

对于内部群还好。

但如果面对的是客户群，就很容易出现：

客户困惑。

客服重复解释。

甚至直接影响企业专业形象。

所以这次立刻智能体对推送通知能力做了一次非常重要的升级：

**通知支持撤回了。**

更准确地说：

**还没有真正投递出去的通知，现在可以及时拦下来。**

一条通知发往几十个群，也可以整条撤回
------------------

通过立刻智能体推送通知 API，一条业务通知可能并不是只发往一个群。

例如：

一条合同到期通知。

可能同时匹配 20 个客户群。

一条内部运营提醒。

可能同时推送到多个业务部门群。

以前任务一旦提交，后续只能等待系统继续执行。

现在，企业可以直接针对：

**这一条完整通知任务**

执行撤回。

不需要：

逐个找群。

逐个取消。

逐个确认。

一条通知无论对应多少个待发送群，都可以按照同一个通知任务统一处理。

这对于批量推送场景尤其重要。

因为真正发生错误的时候，最宝贵的往往就是：

**那几十秒钟或者几分钟的止损时间。**

撤回不是“删除已经发出去的聊天消息”
------------------

这里需要特别说明。

通知撤回并不等于：

**把已经出现在客户群里的消息远程删除。**

如果某个群已经成功收到通知，那么这条消息已经进入实际聊天渠道。

这部分不会因为后续撤回任务而消失。

撤回真正控制的是：

**这条通知剩余尚未完成的投递。**

可以简单理解成：

已经发送成功

→ 保留原结果

  

还在等待发送

→ 撤回后停止发送

  

正在发送

→ 以实际最终投递结果为准

所以这项能力更接近：

**紧急停止后续投递。**

而不是对历史消息做远程删除。

这个区别非常重要。

因为它决定了什么时候撤回最有价值：

**越早发现，越早止损。**

开放 API 可以撤，控制台也可以撤
------------------

这项能力不是只给开发者使用。

如果企业自己的业务系统通过开放 API 创建通知，也可以通过接口对通知执行撤回。

适合：

ERP。

TMS。

货代系统。

订单系统。

合同系统。

或者企业自己开发的内部平台。

业务系统检测到数据变化之后，可以程序化地决定：

这条通知是否应该继续发送。

另一方面，运营人员也可以直接在立刻智能体后台处理。

比如运营在通知列表里发现：

目标选错了。

文案不对。

价格写错。

或者客户状态刚刚发生变化。

可以直接点击：

**撤回**

及时终止后续投递。

所以这次升级同时覆盖两个操作入口：

**开放 API**

和：

**管理控制台。**

开发人员可以做自动化。

运营人员也保留人工止损能力。

场景一：续约价格写错了，发现以后立刻撤回
--------------------

这是最典型的场景。

比如系统批量生成合同续约通知：

> 您的服务将在 10 月 15 日到期，本次续约价格为 8,000 元，请及时确认。

通知提交后才发现：

正确价格应该是：

> 5,000 元。

如果这条通知要发送到几十个客户群，那么越晚处理，影响范围越大。

现在可以直接撤回原通知。

已经收到的客户群，需要根据实际情况再进行人工说明。

但尚未投递的客户群，就不会继续收到错误版本。

运营人员修改正确价格之后，再重新创建一条新的通知。

整个过程从：

**“错误消息只能继续扩散”**

变成：

**“发现问题以后可以马上截断”。**

场景二：客户已经续约，但提醒还在排队
------------------

还有一种错误并不是文案写错。

而是：

**业务状态已经变了。**

比如企业设置了：

合同到期前 3 天自动提醒。

系统上午生成通知。

但客户中午已经完成续约。

原来的提醒因为设置了发送窗口，计划下午 3 点才真正推送。

如果没有撤回机制，下午客户还是会收到：

> 您的合同即将到期，请及时续约。

客户第一反应很可能是：

> 我不是已经续了吗？

这类通知虽然不算严重错误，但会明显降低客户对系统和服务的信任感。

现在业务系统在识别到：

**续约已完成**

之后，就可以主动撤回尚未发送的提醒。

客户不需要再收到一条已经失效的消息。

这也是自动通知真正进入业务闭环之后，非常重要的一步：

**业务状态变化，通知状态也应该跟着变化。**

场景三：运营发现发错群了，直接止损
-----------------

人工操作同样会犯错。

比如运营原本应该发送给：

客户 A 的服务群。

结果配置时选成了：

客户 B。

或者一次批量选择的时候，多勾了几个不相关的群。

如果通知还处于：

排期。

限速等待。

或者尚未实际投递。

运营人员就可以在后台直接撤回。

后续还没有收到消息的群，将不再继续发送。

对于运营人员来说，这个功能其实很像一个：

**“紧急停止按钮”。**

平时不一定经常用。

但真正出错的时候，非常重要。

撤回以后，系统会发生什么？
-------------

一条通知执行撤回以后，不同目标群可能处于不同状态。

### 已经发送成功的群

不受影响。

因为消息已经真正发送到对应聊天渠道。

系统不会把它当作“未发送”。

### 还没有发送的群

不再继续投递。

例如：

等待发送窗口。

等待 QQ 群限速恢复。

等待任务调度。

等待其他发送条件。

这些尚未真正执行的目标，会被终止。

### 正在发送中的群

以最终实际结果为准。

因为撤回动作发生时，某个投递任务可能已经交给实际渠道处理。

这个时候无法简单假设：

一定成功。

或者一定失败。

最终仍然要以投递结果为准。

所以撤回之后，系统仍然需要保留实际发送状态。

撤回不是“悄悄改数据”，全过程可以追溯
-------------------

对于企业系统来说，只允许撤回还不够。

还需要知道：

**是谁撤的？为什么撤？什么时候撤的？**

所以通知撤回会保留相应操作记录。

例如：

1.  撤回人
2.  撤回时间
3.  撤回来源
4.  撤回原因

其中“来源”可以用于区分：

是通过控制台人工操作。

还是业务系统通过开放 API 发起。

这样以后复盘某条通知时，可以看到完整过程：

什么时候创建。

原本要发给哪些群。

哪些已经成功。

哪些还没发送。

什么时候被撤回。

是谁操作。

为什么撤回。

这对于：

运营复盘。

异常排查。

开发调试。

内部审计。

都会更加清晰。

这次升级不只是“能撤回”

除了通知撤回，这一版还有另外一个非常实用的升级：

通知可以带图片和文件了。

过去系统通知最常见的形式是：

文字。

比如：

> 您的续约合同已生成，请及时确认。

但真实业务里，很多通知其实不可能只靠一句文字说清楚。

例如：

合同续约，需要附件。

费用提醒，需要账单。

业务异常，可能需要截图。

某个业务页面，还希望客户直接点击进入。

所以现在一条通知除了文字以外，还可以进一步携带：

**图片**

**文件**

以及：

**链接卡片**

让通知从单纯“告诉客户一件事”，变成：

**把处理这件事需要的资料一起送过去。**

续约提醒，可以直接带合同
------------

比如系统生成一条：

> 【合同续约提醒】

> 您当前合同即将到期，请查收最新续约合同。

过去员工看到这条通知以后，可能还要再做一步：

找合同。

下载。

打开 QQ 或企微。

再手工上传一次。

现在通知本身就可以关联合同文件。

系统发送通知时，一起将对应资料带出去。

这样：

**提醒**

和：

**需要处理的资料**

就不再是两件分开的事情。

费用提醒，可以直接带账单图片
--------------

再比如财务系统生成客户账单之后。

通知内容可以是：

> 【费用确认】

> 本票费用已生成，请及时确认。

同时附上一张：

**账单图片**

或者对应 PDF / 文件。

客户看到通知之后，就可以直接查看相关资料。

不需要客服再补一句：

> 等一下，我把账单发你。

对于大量重复性的客户服务场景，这种差别其实非常明显。

还可以带业务页面链接卡片
------------

有些通知真正希望客户做的动作，不只是“看消息”。

而是：

打开某个页面。

确认某项业务。

查看订单。

查看费用。

填写资料。

这时候可以在通知中带相应的：

**链接卡片。**

比如：

> 【续约提醒】

> 您的服务即将到期，请点击下方链接查看续约方案。

客户看到后，可以直接进入对应页面。

让通知从：

**信息**

继续变成：

**业务入口。**

企微群和 QQ 群，附件表现方式会有所不同
---------------------

由于不同聊天平台本身的能力不同，同一条带附件的通知，在企微和 QQ 中的最终表现方式也会有所区别。

### 企业微信群

如果渠道本身支持相应消息类型，可以直接看到：

真实图片。

真实文件。

链接卡片。

整体体验更接近原生富媒体消息。

### QQ 群

对于附件内容，可以通过：

**带下载链接的文字消息**

进行呈现。

也就是说，即使底层渠道展示形式不同，用户仍然能够获得完整信息。

核心原则不是强行让两个渠道“长得完全一样”。

而是：

**同一条业务通知，在两个渠道里都不能缺关键内容。**

一条通知最多可以带 3 个附件
---------------

为了兼顾实际业务需求和消息可控性，一条通知可以附带多个附件。

例如：

续约通知同时附带：

1.  续约合同
2.  新报价单
3.  服务说明

这类常见业务组合可以一次发送完成。

推送通知开始从“自动发送”走向“可控发送”
---------------------

如果回头看之前的推送通知 API，它解决的第一阶段问题是：

**业务系统里的重要信息，怎么自动送到企微群和 QQ 群？**

这一版继续解决的是：

**自动送出去以后，怎么让这个过程更加可控？**

以前关注的是：

发不发得出去。

现在还要继续关注：

发错了能不能停。

重复了会不会多发。

附件能不能一起送。

实际结果能不能追踪。

谁修改过任务能不能查。

这说明推送通知开始从一个简单的：

**“系统自动发消息”**

逐渐变成：

**“完整的业务通知管理能力”。**

发得出去，也收得回来；发得了文字，也发得了合同
-----------------------

自动化从来不应该只是：

**让系统做得更快。**

更重要的是：

**出错的时候，也要有办法控制。**

这次推送通知升级之后，一条通知开始具备更完整的生命周期。

可以创建。

可以发送。

可以查询结果。

也可以在尚未全部投递之前撤回。

同时通知内容也从：

纯文字。

扩展到：

图片。

文件。

链接卡片。

于是，业务系统和客户群之间的这条自动化链路，又往前走了一步。