本公开涉及信息处理技术领域，具体而言，涉及一种基于智能语音呼叫的物流信息处理方法、基于智能语音呼叫的物流信息处理装置、计算机可读存储介质以及电子设备。
背景技术：
随着互联网技术的高速发展，人们已经习惯于网上购物，与之相随的物流配送也得到了前所未有的发展机遇。但是，在物流配送过程中存在诸多问题，一定程度上影响了网上购物的进一步发展。
例如，随着物流业务量的快速增长，在物流配送过程中，当配送人员通过人工联系用户的方式与用户进行沟通确认以完成配送时，人力和时间成本较高，从而降低了配送人员的效率和质量。
基于此，提出一种新的物流信息处理方法是非常必要的。
需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。
技术实现要素：
本公开的目的在于提供一种基于智能语音呼叫的物流信息处理方法、基于智能语音呼叫的物流信息处理装置、计算机可读存储介质以及电子设备，以解决现有技术中通过人工呼叫的方式完成物流配送时存在呼叫的处理效率较低，导致运作成本较高的问题。
根据本公开的第一方面，提供一种基于智能语音呼叫的物流信息处理方法，包括：
当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；
将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；
生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。
在本公开的一种示例性实施例中，所述配置规则包括符合智能语音呼叫触发条件的物流信息类型和物流调度区域信息；
所述当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫，包括：
预设所述配置规则的优先级，并根据所述优先级对所述异常物流信息中的物流信息类型进行校验；
校验通过后，当所述异常物流信息中的物流调度区域信息与所述配置规则中的所述物流调度区域信息匹配时，向所述目标用户发起智能语音呼叫。
在本公开的一种示例性实施例中，所述向所述目标用户发起智能语音呼叫，包括：
调用数据字典配置的时间间隔，并在所述时间间隔后向所述目标用户发起智能语音呼叫。
在本公开的一种示例性实施例中，所述将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图，包括：
将所述目标用户对所述智能语音呼叫的响应结果发送至消息队列；
拉取所述消息队列以对所述响应结果进行解析，得到预设格式的响应数据；
根据数据库中的数据映射关系确定与所述响应数据对应的所述目标用户的交互意图。
在本公开的一种示例性实施例中，所述生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理，包括：
当所述交互意图为积极交互意图时，生成对应于所述积极交互意图的处理请求，响应所述处理请求以对所述异常物流信息进行修正；
当所述交互意图为消极交互意图时，生成对应于所述消极交互意图的审核请求，响应所述审核请求并根据审核结果对所述异常物流信息进行修正。
在本公开的一种示例性实施例中，根据审核结果对所述异常物流信息进行修正前，所述方法还包括：
将所述目标用户对所述智能语音呼叫的响应结果进行过滤，以根据所述审核结果对所述异常物流信息进行修正。
在本公开的一种示例性实施例中，所述方法还包括：
当所述异常物流信息不满足预设的配置规则时，生成对应于所述异常物流信息的审核请求，响应所述审核请求并根据审核结果对所述异常物流信息进行修正。
根据本公开的第二方面，提供一种基于智能语音呼叫的物流信息处理装置，包括：
呼叫触发模块，用于当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；
意图确定模块，用于将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；
信息处理模块，用于生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。
根据本公开的第三方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述任意一项所述的方法。
根据本公开的第四方面，提供一种电子设备，包括：处理器；以及存储器，用于存储所述处理器的可执行指令；其中，所述处理器配置为经由执行所述可执行指令来执行上述任意一项所述的方法。
本公开示例性实施例可以具有以下部分或全部有益效果：
在本公开示例实施方式所提供的基于智能语音呼叫的物流信息处理方法中，通过当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。一方面，通过对异常物流信息触发智能语音呼叫，可以快速获取目标用户的响应结果，与人工呼叫方式相比提高了呼叫的处理效率，进而减少了运作成本；另一方面，根据目标用户的响应结果及时对该异常物流信息进行处理，可以提升用户体验；再一方面，基于目标用户的不同交互意图采取对应的处理方式，可以灵活的应对各种异常物流场景，进一步提高物流运营效率。
应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其它的附图。
图1示出了可以应用本公开实施例的一种物流信息处理方法及装置的示例性系统架构的示意图；
图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图；
图3示意性示出了根据本公开的一个实施例的物流信息处理方法的流程图；
图4示意性示出了根据本公开的一个实施例的发起智能语音呼叫的流程图；
图5示意性示出了根据本公开的另一个实施例的发起智能语音呼叫的流程图；
图6示意性示出了根据本公开的一个实施例的确定目标用户交互意图的流程图；
图7示意性示出了根据本公开的一个实施例的现有的协商再投逻辑的流程图；
图8示意性示出了根据本公开的一个实施例的异常物流信息处理的流程图；
图9示意性示出了根据本公开的一个具体实施例的异常物流信息处理的流程图；
图10示意性示出了根据本公开的一个实施例的物流信息处理装置的框图。
具体实施方式
现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。
此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。
图1示出了可以应用本公开实施例的一种物流信息处理方法及装置的示例性应用环境的系统架构的示意图。
如图1所示，系统架构100可以包括终端设备101、102、103中的一个或多个，网络104和服务器105。网络104用以在终端设备101、102、103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。终端设备101、102、103可以是具有显示屏的各种电子设备，包括但不限于台式计算机、便携式计算机、智能手机和平板电脑等等。在一种实施例应用场景中，终端设备101可以为物流配送终端，并安装有物流配送客户端，配送人员通过物流配送客户端与揽派后台进行交互。终端设备102可以为终端管理工作台，在工作台界面上可以配置规则表。终端设备102可以为商家工作台，用于对异常物流信息进行审核。应该理解，图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端设备、网络和服务器。比如服务器105可以是多个服务器组成的服务器集群等
本公开实施例所提供的物流信息处理方法一般由服务器105执行，相应地，物流信息处理装置一般设置于服务器105中。但本领域技术人员容易理解的是，本公开实施例所提供的物流信息处理方法也可以由终端设备101、102、103执行，相应的，物流信息处理装置也可以设置于终端设备101、102、103中，本示例性实施例中对此不做特殊限定。
图2示出了适于用来实现本公开实施例的电子设备的计算机系统的结构示意图。
需要说明的是，图2示出的电子设备的计算机系统200仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。
如图2所示，计算机系统200包括中央处理单元(cpu)201，其可以根据存储在只读存储器(rom)202中的程序或者从存储部分208加载到随机访问存储器(ram)203中的程序而执行各种适当的动作和处理。在ram203中，还存储有系统操作所需的各种程序和数据。cpu201、rom202以及ram203通过总线204彼此相连。输入/输出(i/o)接口205也连接至总线204。
以下部件连接至i/o接口205：包括键盘、鼠标等的输入部分206；包括诸如阴极射线管(crt)、液晶显示器(lcd)等以及扬声器等的输出部分207；包括硬盘等的存储部分208；以及包括诸如lan卡、调制解调器等的网络接口卡的通信部分209。通信部分209经由诸如因特网的网络执行通信处理。驱动器210也根据需要连接至i/o接口205。可拆卸介质211，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器210上，以便于从其上读出的计算机程序根据需要被安装入存储部分208。
特别地，根据本公开的实施例，下文参考流程图描述的过程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分209从网络上被下载和安装，和/或从可拆卸介质211被安装。在该计算机程序被中央处理单元(cpu)201执行时，执行本申请的方法和装置中限定的各种功能。
作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的电子设备中所包含的；也可以是单独存在，而未装配入该电子设备中。上述计算机可读介质承载有一个或者多个程序，当上述一个或者多个程序被一个该电子设备执行时，使得该电子设备实现如下述实施例中所述的方法。例如，所述的电子设备可以实现如图3至图9所示的各个步骤等。
需要说明的是，本公开所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(ram)、只读存储器(rom)、可擦式可编程只读存储器(eprom或闪存)、光纤、便携式紧凑磁盘只读存储器(cd-rom)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本公开中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、rf等等，或者上述的任意合适的组合。
以下对本公开实施例的技术方案进行详细阐述：
例如，随着物流业务量的快速增长，在物流配送过程中，当配送人员通过人工联系用户的方式与用户进行沟通确认以完成配送时，人力和时间成本较高，从而降低了配送人员的效率和质量。
在物流配送行业快速发展的同时，注重客户体验显得尤为重要。在物流配送过程中仍存在诸多问题，例如，基于对配送人员绩效提成的规则，可能会催生出刷单、私自替客户退单等非规范操作。其中，重要的是如何及时、准确的获取客户对运单反馈的真实感受，如客户又想要已经退货的运单的特殊场景，目前，配送人员可以通过人工呼叫的方式向客户进行确认，是否需要配送该运单。
利用该方式使得客户确认运单时，由于物流配送业务量大，导致人力和时间成本较高；而且，配送结果很大程度上取决于配送人员是否向客户进行确认，因此，也就无法防止刷单、私自替客户退单等非规范操作；由于是通过人工呼叫的方式向客户进行配送，无法24小时内及时解决客户问题，客户体验较差。
基于上述一个或多个问题，本示例实施方式提供了一种基于智能语音呼叫的物流信息处理方法，该方法可以应用于上述服务器105，也可以应用于上述终端设备101、102、103中的一个或多个，本示例性实施例中对此不做特殊限定。参考图3所示，该物流信息处理方法可以包括以下步骤s310至步骤s330：
步骤s310.当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；
步骤s320.将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；
步骤s330.生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。
在本公开示例实施方式所提供的基于智能语音呼叫的物流信息处理方法中，通过当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。一方面，通过对异常物流信息触发智能语音呼叫，可以快速获取目标用户的响应结果，与人工呼叫方式相比提高了呼叫的处理效率，进而减少了运作成本；另一方面，根据目标用户的响应结果及时对该异常物流信息进行处理，可以提升用户体验；再一方面，基于目标用户的不同交互意图采取对应的处理方式，可以灵活的应对各种异常物流场景，进一步提高物流运营效率。
下面，对于本示例实施方式的上述步骤进行更加详细的说明。
在步骤s310中，当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫。
物流信息是指反映物流中各种活动内容的知识、资料、图像、数据、文件的总称。按作用层次对物流信息进行分类时，可以将物流信息分为基础信息、作业信息、协调控制信息和决策支持信息。其中，基础信息是物流活动的基础，如物品基本信息、货位基本信息等；作业信息是物流作业过程中发生的信息，具有动态性，如库存信息、到货信息等；协调控制信息是指物流活动的调度信息和计划信息；决策支持信息是指能对物流计划、决策、战略具有影响或有关的统计信息或有关的宏观信息，如科技、产品、法律等方面的信息。
本公开示例实施方式适用的场景以物流配送场景为例，对应的，其中物流信息可以是配送信息，如运单的配送状态。一种示例实施方式中，异常物流信息可以是指无法正常、按时完成配送的运单，如客户拒收该运单、配送时连续三天联系不到客户等情形。当物流信息异常时，配送人员需要将该运单进行协商再投，以确认客户是否接收该运单。
本示例中，将配送异常的运单进行协商再投时，为了对配送人员的工作进行减负，可以向目标用户发起智能语音呼叫，该目标用户即为接收该运单的客户。其中，智能语音呼叫可以是ai(artificialintelligence，人工智能)外呼，ai外呼是指通过ai语音机器人实现自动化批量呼叫设定名单中号码的过程，ai语音机器人可以通过语音识别以及自然语义理解等技术，实现准确听懂并理解客户意图，完成与客户的自动语音交互过程。ai外呼可以应用于产品推广、客户关怀以及售后客服等服务领域，ai语音机器人可批量快速完成海量电话的外呼工作，通过替代配送人员人工呼叫客户的方式，可以提升配送人员的工作效率和质量。
在向客户发起ai外呼前，可以先判断该运单是否满足预设的配置规则，该配置规则可以包括符合ai外呼触发条件的物流信息类型、呼叫原因类型和物流调度区域信息。示例性的，物流信息类型可以是运单类型，如可以将生鲜类运单、医药类运单配置为可以触发ai外呼的运单。呼叫原因类型即发起协商再投的原因，可以包括客户原因：如连续三天无法联系到客户、客户误购、客户超三天无法收货、开箱验货拒收、要求拒收、客户未购买过等；也可以包括公司原因：如外包装破损/污渍、运营原因等；还可以包括其他原因：如订单拦截、客户拒付运费/代税费等。物流调度区域信息可以是可以触发ai外呼的物流配送站点，为了灵活配置，也可以将可以触发ai外呼的物流配送站点添加至白名单中，即位于白名单中的物流配送站点才可以触发ai外呼。
将配送异常的运单进行协商再投时，参考图4所示，可以根据步骤s410至步骤s430触发向目标用户发起的智能语音呼叫：
步骤s410.预设所述配置规则的优先级，并根据所述优先级对所述异常物流信息中的物流信息类型进行校验。
对于可以触发ai外呼的配置规则，还可以为该配置规则中的物流信息类型设置优先级等级，并根据优先级等级依次对异常运单中的物流信息类型进行校验，第一次校验通过时即完成校验。例如，满足ai外呼的运单类型可以包括生鲜类运单、水果类运单，可以获取异常运单的waybill_sign(运单标志)，由waybill_sign标位信息可知该异常订单的运单类型。如为草莓运单时，草莓既是水果类又是生鲜类，此时，可以为生鲜类和水果类设置优先级等级，当生鲜类优先级较高时，匹配优先级高的运单类型。具体的，可以配置生鲜类的waybill_sign中第54位为2，通过校验草莓运单的waybill_sign中第54位是否为2，若为2时，说明草莓符合生鲜类，此时可以直接触发ai外呼，无需再判断草莓是否属于水果类；若不为2时，跳过该运单类型，对下一等级的运单类型进行校验。通过设置规则优先级，防止一个运单符合配置规则中的多个规则，可以快速进行去重，进而节省物流配送的时间成本。
步骤s420.校验通过后，当所述异常物流信息中的呼叫原因类型、物流调度区域信息与所述配置规则中的所述呼叫原因类型、所述物流调度区域信息均匹配时，向所述目标用户发起智能语音呼叫。
异常运单的运单类型校验通过后，当该异常运单发起协商再投的原因满足配置规则中的ai外呼原因，且该异常运单的配送站点位于配置规则中的站点白名单时，可以向接收该异常运单的客户发起ai外呼。
一种示例实施方式中，在一天内将同一客户的多个运单均发起协商再投时，如不进行去重处理，则需要多次向客户发起ai外呼，容易对该客户造成困扰，降低客户体验，甚至导致客户投诉和封号。因此，在向客户发起ai外呼前，可以通过增加kv(key-value，键-值)缓存对客户进行去重处理。例如，当天向该客户发起第一次ai外呼时，可以将该客户的标识存储到支持列表的kv型数据库中，该数据库实际上是一kv缓存。对应的存储该客户标识的方式可以是：将该客户的联系方式即电话号码作为kv型数据库中的key，以其他字段作为值，以列表形式追加到该key对应的value中。示例性的，key-value的形式可以是xszt[1111]，表示对于需要协商再投的异常运单，接收该异常订单的客户的电话号码为1111，value的形式可以是xszt[1111].call1，表示电话号码1111已经被呼叫过1次。可以理解的是，对于符合ai外呼的电话号码，可以通过查询kv型数据库中是否缓存有对应的key，若有，表示该客户当天已经被呼叫过，不再触发第二次ai外呼；若没有，表示该客户当天没有被呼叫过，可以触发ai外呼，并在ai外呼结束后，将对应的key写入缓存。通过增加kv缓存，可以确保每个key不会被重复存储，避免在一天内向同一客户触发多次ai外呼，在改善客户体验的同时，节省了与客户沟通的时间成本，进而提升了配送人员的工作效率和工作质量。
另一种示例实施方式中，当异常运单满足预设的配置规则时，还可以设置触发ai外呼的时间点，如可以调用数据字典配置的时间间隔，并在该时间间隔后向目标用户发起智能语音呼叫。具体的，可以通过数据字典接口调用青龙基础资料数据字典配置的时间间隔，如时间间隔为30分钟时，可以在30分钟后将该异常订单推送至ai系统进行外呼操作。
一种具体实施例中，参考图5所示，示意性给出了触发ai外呼的交互流程，该流程可以包括步骤s501至步骤s505：
步骤s501.配置规则表，并同步至后台。首先，可以在终端管理工作台的工作台界面上配置规则表，以配置可以触发ai外呼的运单。具体的，可以根据运单类型配置对应的waybill_sign标位信息并生成规则表。其中，运单类型可以包括cod(cashondelivery，货到付款)类型，3c产品(指计算机、通信和消费类电子产品)类型，生鲜类型，水果类型，冷链类型，医药类型等。另外，规则表中也包含ai外呼原因类型，如可以包括客户原因：如连续三天无法联系到客户、客户误购、客户超三天无法收货、开箱验货拒收、要求拒收、客户未购买过等；也可以包括公司原因：如外包装破损/污渍、运营原因等；还可以包括其他原因：如订单拦截、客户拒付运费/代税费等。规则表中还包含营业部白名单，位于白名单中的物流配送站点可以触发ai外呼。对应的，也可以对规则表中的规则状态进行配置，规则状态可以是启用状态，也可以是停用状态。需要说明的是，规则表中不同的运单类型、外呼原因以及配送站点分别对应不同的id(身份标识号码)。其次，可以将规则表同步至揽派后台，以使揽派后台保存该规则表；
步骤s502.上传运单号和协商再投原因。本示例中，当配送人员配送生鲜类型的运单且客户拒收该运单时，配送人员可以通过物流配送客户端将该运单的运单号和协商再投原因id上传至揽派后台。其中，揽派后台仅对首次发起协商再投的运单进行规则校验；
步骤s503.匹配配置规则表。可以根据该运单的运单类型进行判断，并根据该运单的运单号确定物流配送站点id是否位于营业部白名单中，以及根据该运单的协商再投原因匹配规则表中的协商再投原因以校验配置规则表；
步骤s504.手机号自然日去重，首次发起外呼。
步骤s505.命中规则，推ai外呼。当该运单满足配置规则时，可以根据业务配置数据字典在预设时间间隔后推ai外呼。
在其他示例中，若该运单不满足配置规则时，可以将该运单的运单号、运单类型编码和名称、协商再投原因上传至揽派后台，以备后续报表使用。对于cod类型的运单，也可以将代收货款额度等上传揽派后台。
在步骤s320中，将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图。
向目标用户发起ai外呼后，可以接收该目标用户对ai外呼的响应结果。参考图6所示，基于该响应结果，可以根据步骤s610至步骤s630确定目标用户的交互意图：
步骤s610.将所述目标用户对所述智能语音呼叫的响应结果发送至消息队列。
消息队列可以作为应用程序之间传递的信息载体。消息队列技术是分布式应用间交换信息的一种技术，消息队列可驻留在内存或磁盘上，队列存储消息直到它们被应用程序读走。通过消息队列，应用程序可以独立地执行而不需要知道彼此的位置。本公开实施例中的消息队列可采用开源消息队列，具体可以采用例如消息中间件实现，该消息中间件可以采用jmq一种消息中间件系统)中间件，当物流配送业务量大时，也可以采用kafka(一种高吞吐量的分布式发布订阅消息系统)中间件，即将客户对智能语音呼叫的响应结果发送到kafka分布式队列进行消息传递和分发，然后从所述队列中拉取消息进行分析处理，本示例中对此不作限定。
步骤s620.拉取所述消息队列以对所述响应结果进行解析，得到预设格式的响应数据。
一种示例实施方式中，优选的可以将客户对ai外呼的响应结果发送至jmq消息队列，揽派后台可以采用mq(messagequeue，消息队列)消息处理服务器拉取该jmq消息队列，如mq消息处理服务器可以批量拉取该jmq消息队列以对响应结果进行解析，得到预设格式的响应数据。
本示例中，客户对ai外呼的响应结果可以包括6种情形：
情形一：客户对ai外呼的响应结果是客户未接通时，解析该响应结果得到的响应数据可以是callresult＝2/3&reasoncode≠11。其中，2和3均可以表示已向该客户发起ai外呼，客户没有接听。具体的，在ai外呼过程中，若通信连接正常但是客户没有接听时，可以将本次ai外呼的响应结果赋值为2；若由于客户关机或者欠费等原因客户没有接听时，可以将本次ai外呼的响应结果赋值为3。另外，若客户已退订物流配送过程中的ai外呼业务时，可以将客户未接通的原因赋值为11，客户退订该业务时，需要将客户的联系方式进行标记，如将客户的电话号码加入ai外呼黑名单，以防止对该客户推ai外呼。因此，对于字段reasoncode≠11，可以表示是该客户未退订该业务。
情形二：客户对ai外呼的响应结果是客户接通后挂断时，解析该响应结果得到的响应数据可以是callresult＝1&phonekey为空。可以理解的是，若客户接听时，可以将本次ai外呼的响应结果赋值为1，同时，可以将客户未选择任何服务直接挂断配置为phonekey为空。
情形三：客户对ai外呼的响应结果是客户要求拒收时，解析该响应结果得到的响应数据可以是callresult＝1&phonekey＝2。类似的，若客户接听时，可以将本次ai外呼的响应结果赋值为1，同时，可以将客户选择“拒收”服务配置为phonekey＝2，即客户接听后可以通过按键2选择拒收该运单。
情形四：客户对ai外呼的响应结果是客户触发无效按键时，解析该响应结果得到的响应数据可以是callresult＝1&phonekey＝-1。类似的，若客户接听时，可以将本次ai外呼的响应结果赋值为1，同时，可以将客户触发无效按键配置为phonekey＝-1。
情形五：客户对ai外呼的响应结果是客户退订ai外呼服务时，又可以包含两种情形：
1、若客户首次退订ai外呼服务时，解析该响应结果得到的响应数据可以是callresult＝1&phonekey＝#。类似的，若客户接听时，可以将本次ai外呼的响应结果赋值为1，同时，可以将客户选择“退订”服务配置为phonekey＝#，即客户接听后可以通过按键#选择退订ai外呼服务。
2、若客户已退订ai外呼服务且该客户的联系方式已进入ai外呼黑名单时，解析该响应结果得到的响应数据可以是callresult＝2&reasoncode＝11，即客户已退订ai外呼业务，进而客户无法接通此次ai外呼。
情形六：客户对ai外呼的响应结果是客户要求再派时，解析该响应结果得到的响应数据可以是callresult＝1&phonekey＝1。类似的，若客户接听时，可以将本次ai外呼的响应结果赋值为1，同时，可以将客户选择“再派”服务配置为phonekey＝1，即客户接听后可以通过按键1选择再次派送该运单。
步骤s630.根据数据库中的数据映射关系确定与所述响应数据对应的所述目标用户的交互意图。
基于上述6种情形，可以将预先配置好的各种响应数据进行存储，如可以存储在redis数据库中，也可以存储在mysql数据库中。其中，redis数据库是一个key-value存储系统，存储在redis数据库中时，可以包括：响应数据和客户的交互意图形成的键值对(key-value)，其中键(key)为响应数据，值(value)为客户的交互意图。通过解析客户的响应结果获得响应数据后，可以根据该响应数据，进行数据库查询，如可以在redis数据库中查询存储有键为响应数据的键值对，根据该键值对获取客户的交互意图。示例性的，当响应数据为callresult＝1&phonekey为空时，说明客户接听并挂断了ai呼叫，可以确定客户的交互意图为拒收或暂时不接收该运单。
在步骤s330中，生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。
对于物流配送过程中的异常物流信息如无法按时完成配送的运单，参考图7所示，示意性的给出了现有的协商再投逻辑，可以将该异常运单推送至商家，以审核是否需要对该异常订单进行再投处理。具体的，可以参考步骤s701至步骤s710：
步骤s701.调运单拒收待审(即协商再投)接口。对于异常订单，揽派后台可以通过向运单系统调运单拒收待审接口给商家工作台推送拒收待审任务；
步骤s702.发起协商再投，全程跟踪。此时，运单系统的处理节点为【发起协商再投】节点，可以通过调运单全程跟踪接口，发布全程跟踪信息；
步骤s703.运单系统生成协商再投mq；
步骤s704.商家工作台消费mq，即拉取协商再投mq；
步骤s705.调运单审核接口；
步骤s706.运单系统生成再投审核结果mq；
步骤s707.终端消费。揽派后台拉取该审核结果mq；
步骤s708.揽派后台将拉取到的审核结果存储进再投数据表；
步骤s709.推送工作台。揽派后台将该运单的审核结果推送至终端管理工作台；
步骤s710.生成再投审核卡片。终端管理工作台根据接收到的审核结果生成协商再投卡片任务，如根据审核结果生成的任务可以是再投该运单，也可以是将该运单进行退货处理，还可以是将该运单做报废选择。最后，可以根据卡片任务对配送人员进行指示以处理该运单。
一种示例实施方式中，参考图8所示，可以根据步骤s810和步骤s820对异常物流信息进行处理：
在步骤s810中.当所述交互意图为积极交互意图时，生成对应于所述积极交互意图的处理请求，响应所述处理请求以对所述异常物流信息进行修正。
当客户的交互意图为积极交互意图如客户要求再派时，可以生成对应的处理请求，响应该处理请求以将该异常运单完成配送。与现有的协商再投逻辑不同，具体的，揽派后台可以将该运单的任务变更为“再投”任务，向运单全程跟踪接口只发送“ai外呼结果”全程跟踪。同时，可以将ai外呼的响应结果落库，存储进拒收待审数据表中，并将商家的审核结果推送至终端管理工作台生成协商再投卡片任务。
在步骤s820中.当所述交互意图为消极交互意图时，生成对应于所述消极交互意图的审核请求，响应所述审核请求并根据审核结果对所述异常物流信息进行修正。
当客户的交互意图为消极交互意图如客户未接通、客户接通挂断、客户要求拒收、客户触发无效按键、客户退订ai外呼服务时，可以生成对应的审核请求，响应该审核请求可以利用现有的协商再投逻辑通过商家对该异常运单进行审核，审核结果可以是“再投”、“退货”、“报废”，根据商家的审核结果以对该异常运单进行处理。
本方法中，通过在物流配送过程中为客户提供ai外呼服务，可以快速获取客户对运单的响应结果。根据客户的响应结果，揽派后台可以第一时间为配送人员做出处理该运单的任务指示，提高客户体验。重要的是，根据客户不同的响应结果采取对应的处理方式，可以灵活的应对各种异常物流场景，进一步提高物流运营效率。而且，该方法可以规范物流配送的操作流程，如ai外呼代替人工呼叫客户，可以防止出现配送人员私自替客户退单、刷单等情况。另外，客户接听ai呼叫时，通过手机按键就可以选择运单的处理方式，简化了物流配送流程。
一种示例实施方式中，当客户要求拒收运单时，可以利用现有的拒收待审逻辑处理该运单。需要说明的是，在调运单拒收待审接口时，需要将协商再投原因变更为数据字典预设的“拒收”原因，如拒收原因名称和id可以为退货13或要求拒收25，其中，青龙基础资料数据字典配置的退货服务对应的id为13，要求拒收服务对应的id为25。当客户首次退订ai外呼服务时，可以利用现有的拒收待审逻辑处理该运单。需要说明的是，可以调用ai外呼黑名单接口，将该客户的电话号码同步至ai侧外呼黑名单中。
另一种示例实施方式中，以cod运单类型为例，cod运单可以包括商家cod运单和非商家cod运单，对应不同的任务id。对cod运单进行协商再投时，可以增加对该类型运单的客户退订服务。当cod订单配送异常时，参考图9所示，可以根据步骤s910至步骤s913对该cod运单进行处理：
步骤s901.调运单拒收待审接口。对于该cod运单订单，揽派后台可以通过向运单系统调运单拒收待审接口给商家工作台推送拒收待审任务；
步骤s902.发起协商再投，全程跟踪。此时，运单系统的处理节点为【发起协商再投】节点，可以通过调运单全程跟踪接口，发布全程跟踪信息；
步骤s903.运单系统生成协商再投mq；
步骤s904.商家工作台消费mq，即拉取协商再投mq；
步骤s905.客服消费mq，即拉取协商再投mq；
步骤s906.客服呼叫商家。另外，对于cod运单，客服还需要接收ai外呼结果mq，以对该cod运单进行循环监控；
步骤s907.商家工作台调运单审核结果接口；
步骤s908.运单系统生成再投审核结果mq；
步骤s909.客服消费。客服拉取该再投审核结果mq；
步骤s910.终端消费。揽派后台拉取该再投审核结果mq；
步骤s911.揽派后台将拉取到的审核结果存储进再投数据表；
步骤s912.推送工作台。揽派后台将该运单的审核结果推送至终端管理工作台；
步骤s913.生成再投审核卡片。终端管理工作台根据接收到的审核结果生成协商再投卡片任务，如根据审核结果生成的任务可以是再投该cod运单，也可以是将该cod运单进行退货处理，还可以是将该cod运单做报废选择。最后，可以根据卡片任务对配送人员进行指示以处理该cod运单。
由于揽派后台对单次协商再投运单和多次协商再投运单的处理逻辑不同，举例而言，对于允许多次协商再投的运单，需要判断协商再投的次数是否大于预设次数的阈值。而对于仅允许一次协商再投的运单，需要判断是否接收到协商再投的审核结果，若将ai外呼结果计入协商再投的审核结果枚举字段中，揽派后台会默认该运单已经完成一次协商再投，降低了物流配送的准确性。因此，一种实施例中，在根据审核结果对异常物流信息进行修正前，可以将目标用户对智能语音呼叫的响应结果进行过滤，以根据审核结果对异常物流信息进行修正。
示例性的，可以将ai外呼结果单独以审核结果枚举字段进行存储，不再记录到商家的审核结果中，避免影响后续发起协商再投后的商家审核过程。对于单次协商再投或多次协商再投，可以将ai外呼结果另起枚举字段进行存储，揽派后台可以将ai外呼结果进行过滤，只判断商家审核结果，进而根据商家审核结果在配送客户端进行展示，如商家审核结果为再投时，可以在配送客户端展示“协商再投”按钮；如商家审核结果为退货时，可以在配送客户端展示“拒收”按钮时。
需要说明的是，在向客户触发ai外呼到获取该客户的响应结果的时间段内，如将异常运单发起协商再投，并通过调用ai系统触发外呼任务时，若该ai外呼任务在排队状态或正在执行状态，配送人员仍可以对该运单执行收货、妥投和再投等操作。可以理解的是，配送人员再次对该运单协商再投时，揽派后台不进行处理，即不发起ai外呼也不利用现有协商再投逻辑处理该运单，并将其直接过滤。此外，向客户触发ai外呼且24个小时后仍未获取客户的响应结果时，揽派后台可以自动利用现有的协商再投逻辑，即调运单拒收待审接口给商家工作台推送拒收待审任务。
一种示例实施方式中，当异常物流信息不满足预设的配置规则时，可以生成对应于该异常物流信息的审核请求，响应审核请求并根据审核结果对所述异常物流信息进行修正。示例性的，该异常运单不满足触发ai外呼的配置规则时，可以直接利用现有的协商再投逻辑将该异常运单推送到商家工作台，商家工作台对该异常运单进行审核，根据审核结果处理该异常运单，如可以向客户再投该异常运单，也可以将该异常运单做退货或报废处理。
在本公开示例实施方式所提供的基于智能语音呼叫的物流信息处理方法中，通过当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。一方面，通过对异常物流信息触发智能语音呼叫，可以快速获取目标用户的响应结果，与人工呼叫方式相比提高了呼叫的处理效率，进而减少了运作成本；另一方面，根据目标用户的响应结果及时对该异常物流信息进行处理，可以提升用户体验；再一方面，基于目标用户的不同交互意图采取对应的处理方式，可以灵活的应对各种异常物流场景，进一步提高物流运营效率。
应当注意，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。
进一步的，本示例实施方式中，还提供了一种基于智能语音呼叫的物流信息处理装置，该装置可以应用于一服务器或终端设备。参考图10所示，该物流信息处理装置1000可以包括呼叫触发模块1010、意图确定模块1020和信息处理模块1030，其中：
呼叫触发模块1010，用于当异常物流信息满足预设的配置规则时，触发向目标用户发起的智能语音呼叫；
意图确定模块1020，用于将所述目标用户对所述智能语音呼叫的响应结果进行解析，并根据解析结果确定所述目标用户的交互意图；
信息处理模块1030，用于生成对应于所述交互意图的任务请求，响应所述任务请求以对所述异常物流信息进行处理。
在一种可选的实施方式中，所述配置规则包括符合智能语音呼叫触发条件的物流信息类型、呼叫原因类型和物流调度区域信息；
呼叫触发模块1010包括：
规则校验模块，用于预设所述配置规则的优先级，并根据所述优先级对所述异常物流信息中的物流信息类型进行校验；
语音呼叫触发模块，用于校验通过后，当所述异常物流信息中的呼叫原因类型、物流调度区域信息与所述配置规则中的所述呼叫原因类型、所述物流调度区域信息均匹配时，向所述目标用户发起智能语音呼叫。
在一种可选的实施方式中，语音呼叫触发模块还被配置为：调用数据字典配置的时间间隔，并在所述时间间隔后向所述目标用户发起智能语音呼叫。
在一种可选的实施方式中，意图确定模块1020包括：
响应结果发送模块，用于将所述目标用户对所述智能语音呼叫的响应结果发送至消息队列；
响应结果解析模块，用于拉取所述消息队列以对所述响应结果进行解析，得到预设格式的响应数据；
交互意图确定模块，用于根据数据库中的数据映射关系确定与所述响应数据对应的所述目标用户的交互意图。
在一种可选的实施方式中，信息处理模块1030包括：
第一修正模块，用于当所述交互意图为积极交互意图时，生成对应于所述积极交互意图的处理请求，响应所述处理请求以对所述异常物流信息进行修正；
第二修正模块，用于当所述交互意图为消极交互意图时，生成对应于所述消极交互意图的审核请求，响应所述审核请求并根据审核结果对所述异常物流信息进行修正。
在一种可选的实施方式中，物流信息处理装置1000还包括：
信息过滤模块，用于将所述目标用户对所述智能语音呼叫的响应结果进行过滤，以根据所述审核结果对所述异常物流信息进行修正。
在一种可选的实施方式中，物流信息处理装置1000还被配置为：
第三修正模块，用于当所述异常物流信息不满足预设的配置规则时，生成对应于所述异常物流信息的审核请求，响应所述审核请求并根据审核结果对所述异常物流信息进行修正。
应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。
应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。
