CN116307974A - 一种配送通知方法、装置、电子设备和可读存储介质 - Google Patents

Abstract

本申请提供了一种配送通知方法、装置、电子设备和可读存储介质，该方法包括：响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据人员类型信息判断配送人员是否为目标类型人员，目标对象包括商家或顾客；若配送人员为目标类型人员，则显示至少一个信息模板以及至少一个原因标签；响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息；响应于配送人员的第一发送指令，确定通知信息的发送方式，并将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端，发送方式包括外呼方式或短信方式。

Description

一种配送通知方法、装置、电子设备和可读存储介质

技术领域

本申请涉及网络技术领域，尤其是涉及到一种配送通知方法、配送通知装置、电子设备和可读存储介质。

背景技术

目前，听力障碍或语音障碍的骑手在履约中会遇到各种问题，例如，在到店和送达环节，会遇到找不到商家地址、找不到顾客地址、联络不到顾客(如敲不开门)等问题。

因为听障或语障的缘故，听障或语障骑手无法通过拨打电话的方式联络顾客或商家，可能出现超时或履约不完成，进而导致对听障或语障骑手产生罚单，以及顾客客诉的问题。

发明内容

有鉴于此，本申请提供了一种配送通知方法、配送通知装置、电子设备和可读存储介质，解决了相关技术中听障或语障骑手无法联络顾客或商家而导致的超时或履约不完成的问题。

第一方面，本申请实施例提供了一种配送通知方法，包括：响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据人员类型信息判断配送人员是否为目标类型人员，其中，目标对象包括商家或顾客；若配送人员为目标类型人员，则显示至少一个信息模板以及至少一个原因标签；响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息；响应于配送人员的第一发送指令，确定通知信息的发送方式，并将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端，其中，发送方式包括外呼方式或短信方式。

根据本申请实施例的上述配送通知方法，还可以具有以下附加技术特征：

在上述技术方案中，可选地，响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息，包括：接收配送人员对至少一个信息模板中目标信息模板的第一选择指令，响应于第一选择指令，确定目标信息模板；接收配送人员对至少一个原因标签中目标原因标签的第二选择指令，响应于第二选择指令，确定目标原因标签，并根据目标信息模板和目标原因标签，生成通知信息。

在上述任一技术方案中，可选地，响应于配送人员的第一发送指令，确定通知信息的发送方式，包括：若第一发送指令为配送人员对显示的外呼控件进行操作所触发，则确定通知信息的发送方式为外呼方式；或者，若第一发送指令为配送人员对显示的发送短信控件进行操作所触发，则确定通知信息的发送方式为短信方式。

在上述任一技术方案中，可选地，在将通知信息和发送方式上传至服务器之后，还包括：接收配送人员对通知信息的第二发送指令，若第二发送指令的触发时间与第一发送指令的触发时间的时间间隔小于或等于预设时间阈值，则不向服务器发送通知信息，并显示提示信息，提示信息用于指示配送人员在预设时间阈值后发送通知信息。

在上述任一技术方案中，可选地，该方法还包括：接收配送人员对显示的标签添加控件进行操作所触发的标签添加指令，解析标签添加指令，获取自定义原因标签；将自定义原因标签与已存在的原因标签进行比较；若自定义原因标签与已存在的原因标签不相同，则存储自定义原因标签。

在上述任一技术方案中，可选地，在接收配送人员对显示的标签添加控件进行操作所触发的标签添加指令之前，还包括：获取已存在的原因标签的数量，若数量小于或等于预设数量阈值，则显示标签添加控件。

在上述任一技术方案中，可选地，该方法还包括：接收配送人员对已存在的原因标签的标签删除指令，确定待删除原因标签；若待删除原因标签为自定义原因标签，则删除待删除原因标签。

在上述任一技术方案中，可选地，在将通知信息和发送方式的信息上传至服务器之后，还包括：接收配送人员对通知信息的状态查询指令，将状态查询指令发送至服务器，以供服务器查询通知信息的发送状态；接收并显示服务器反馈的通知信息的发送状态；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

在上述任一技术方案中，可选地，在将通知信息和发送方式的信息上传至服务器之后，还包括：接收配送人员对目标对象的订单的配送报备指令，向服务器发送配送报备指令，以供服务器查询通知信息的发送状态，并根据发送状态生成报备处理结果；接收并显示服务器反馈的报备处理结果。

第二方面，本申请实施例提供了一种配送通知方法，包括：接收来自配送人员的终端的通知信息以及通知信息对应的发送方式的信息；根据发送方式，将通知信息发送至目标对象的终端；其中，配送人员为目标类型人员，通知信息为根据配送人员所选择的目标信息模板和目标原因标签所生成，发送方式为根据配送人员所选择的发送方式控件所确定，发送方式包括外呼方式或短信方式，目标对象包括商家或顾客。

根据本申请实施例的上述配送通知方法，还可以具有以下附加技术特征：

在上述技术方案中，可选地，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：接收来自配送人员的终端对通知信息的状态查询指令，查询通知信息的发送状态；将通知信息的发送状态反馈至配送人员的终端；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

在上述任一技术方案中，可选地，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：接收来自配送人员对目标对象的订单的配送报备指令，查询通知信息的发送状态，并根据发送状态生成报备处理结果；将报备处理结果反馈至配送人员的终端。

在上述任一技术方案中，可选地，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：统计预设时间段内，配送人员的终端发送的通知信息的次数；根据次数，计算预设时间段内的通知费用；按照通知费用对配送人员的账户进行扣费处理，并将通知费用反馈至配送人员的终端。

第三方面，本申请实施例提供了一种配送通知装置，包括：类型确定模块，用于响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据人员类型信息判断配送人员是否为目标类型人员，其中，目标对象包括商家或顾客；显示模块，用于若配送人员的类型为目标类型，则显示至少一个信息模板以及至少一个原因标签；信息生成模块，用于响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息；发送方式确定模块，用于响应于配送人员的第一发送指令，确定通知信息的发送方式；发送模块，用于将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端，其中，发送方式包括外呼方式或短信方式。

第四方面，本申请实施例提供了一种配送通知装置，包括：接收模块，用于接收来自配送人员的终端的通知信息以及通知信息对应的发送方式的信息；发送模块，用于根据发送方式，将通知信息发送至目标对象的终端；其中，配送人员为目标类型人员，通知信息为根据配送人员所选择的目标信息模板和目标原因标签所生成，发送方式为根据配送人员所选择的发送方式控件所确定，发送方式包括外呼方式或短信方式，目标对象包括商家或顾客。

第五方面，本申请实施例提供了一种电子设备，该电子设备包括处理器和存储器，存储器存储可在处理器上运行的程序或指令，程序或指令被处理器执行时实现如第一方面或第二方面的方法的步骤。

第六方面，本申请实施例提供了一种可读存储介质，可读存储介质上存储程序或指令，程序或指令被处理器执行时实现如第一方面或第二方面的方法的步骤。

第七方面，本申请实施例提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现如第一方面或第二方面的方法。

第八方面，本申请实施例提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如第一方面或第二方面的方法。

在本申请实施例中，在接收到配送人员触发联系目标对象的指令后，获取该配送人员的人员类型信息，根据配送人员的人员类型信息对配送人员的类型进行确定，也即，判断配送人员是否为目标类型人员。如果判断出配送人员为目标类型人员，则表明配送人员是无法利用正常的拨打电话的方式与目标对象沟通的，在此情况下，为了能够顺利联系到目标对象，为目标类型的配送人员提供向目标对象发送通知信息的功能，通知信息可由配送人员通过选择目标信息模板和目标原因标签进行编辑。接收配送人员的第一发送指令，解析该第一发送指令，确定通知信息的发送方式，将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端。

本申请实施例，针对听障或语障配送人员联系不到顾客或商家的异常场景，提供配送人员向顾客或商家发送通知信息的方式，保障此类配送人员能够联系到顾客或商家，保证履约过程的正常进行，解决了配送人员因听障或语障的缘故，无法联络顾客或商家导致的超时或履约不完成的问题，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，以及减少由此引起的客诉量。

上述说明仅是本申请技术方案的概述，为了能够更清楚了解本申请的技术手段，而可依照说明书的内容予以实施，并且为了让本申请的上述和其它目的、特征和优点能够更明显易懂，以下特举本申请的具体实施方式。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1示出了本申请实施例的应用于配送人员的终端的配送通知方法的流程示意图；

图2示出了本申请实施例的配送人员的终端的界面显示示意图之一；

图3示出了本申请实施例的配送人员的终端的界面显示示意图之二；

图4示出了本申请实施例的配送人员的终端的界面显示示意图之三；

图5示出了本申请实施例的应用于服务器的配送通知方法的流程示意图；

图6示出了本申请实施例的状态查询的逻辑示意图；

图7示出了本申请实施例的配送报备的逻辑示意图；

图8示出了本申请实施例的通知费用计算的逻辑示意图；

图9示出了本申请实施例的应用于配送人员的终端的配送通知装置的结构框图；

图10示出了本申请实施例的应用于服务器的配送通知装置的结构框图；

图11示出了本申请实施例的电子设备的结构框图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员获得的所有其他实施例，都属于本申请保护的范围。

本申请的说明书和权利要求书中的术语“第一”、“第二”等是用于区别类似的对象，而不用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施，且“第一”、“第二”等所区分的对象通常为一类，并不限定对象的个数，例如第一对象可以是一个，也可以是多个。此外，说明书以及权利要求中“和/或”表示所连接对象的至少其中之一，字符“/”，一般表示前后关联对象是一种“或”的关系。

下面结合附图，通过具体的实施例及其应用场景对本申请实施例提供的配送通知方法、配送通知装置、电子设备和可读存储介质进行详细地说明。

顾客线上下单，在商家购买商品，生成订单，该订单由配送人员接单，从商家取货并配送至顾客处。但是，配送人员常常会遇到找不到商家地址、找不到顾客地址、联络不到顾客(如敲不开门)等问题，目前配送人员中有较多听障或语障人员，他们由于听障或语障的缘故，无法通过拨打电话的方式联络顾客或商家，可能出现超时或履约不完成的问题。

为了解决了听障或语障的配送人员无法联络顾客或商家而导致的超时或履约不完成的问题，本申请实施例提供了一种配送通知方法，应用于配送人员的终端，如图1所示，该方法包括：

步骤101，响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，其中，目标对象包括商家或顾客。

在该步骤中，当配送人员有联系目标对象(也即，商家或顾客)的需求时，触发联系目标对象的指令，例如在其终端的APP的订单详情页面上点击“发送通知”控件。在接收到该指令后，从服务器获取该配送人员的人员类型信息，该人员类型信息用于确定配送人员的类型，可以为配送人员进行账户注册时所填写的，也可以为配送人员对顾客的订单进行接单时所备注的。

步骤102，根据人员类型信息判断配送人员是否为目标类型人员，若配送人员的类型为目标类型，则显示至少一个信息模板以及至少一个原因标签。

步骤103，响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息。

在步骤102和步骤103中，根据配送人员的人员类型信息对配送人员的类型进行确定，也即，判断配送人员是否为目标类型人员，这里目标类型人员是指无法利用正常的拨打电话的方式与目标对象沟通的人员，例如具有听力障碍、语音障碍等特殊类型中至少一种的人员。

如果判断出配送人员为目标类型人员，则表明配送人员是无法利用正常的拨打电话的方式与目标对象沟通的，在此情况下，为了能够顺利联系到目标对象，为目标类型的配送人员提供向目标对象发送通知信息的功能。

通知信息可由配送人员进行编辑。在本申请的一个实施例中，响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息，包括：接收配送人员对至少一个信息模板中目标信息模板的第一选择指令，响应于第一选择指令，确定目标信息模板；接收配送人员对至少一个原因标签中目标原因标签的第二选择指令，响应于第二选择指令，确定目标原因标签，并根据目标信息模板和目标原因标签，生成通知信息。

在该实施例中，支持展示多个信息模板，不同信息模板中的内容不同，通过不同信息模板，来满足不同形式通知信息的需求。以及支持展示每个信息模板对应的原因标签，原因标签是指配送人员无法联系到目标对象的原因，原因标签可以填充至信息模板以生成通知信息，且每个信息模板对应的原因标签可以不同。

配送人员在多个信息模板中选择一个目标信息模板，以及在该目标信息模板对应的原因标签中选择一个目标原因标签，在配送人员选定后，将目标原因标签自动填充进目标信息模板，从而生成通知信息。

示例性地，如图2所示，在发送通知页面，显示信息模板1、信息模板2、信息模板3共三个信息模板，配送人员选定信息模板1后，显示的原因标签包括：骑士急需与您联系、因无法联络到您、因您的订单无法当面配送，骑士急需与您联系、您的货品将放至智能柜等。若配送人员选定“骑士急需与您联系”这个原因标签后，将该原因标签填充至信息模板1，生成“您好，饿了么平台，为您配送的骑士是听障骑士，骑士急需与您联系，请尽快通过饿了么站内信或短信与骑士联系，以防耽误您的用餐或收货”的通知信息。

需要说明的是，在配送人员首次使用，也即首次发送通知时，在选择信息模板后，可以默认填入该信息模板的第一个原因标签。在配送人员非首次使用，在选择一个信息模板后，默认填入上一次使用该信息模板提交通知信息时所选择的原因标签。通过上述方式，减少配送人员的操作，提高编辑通知的效率。

步骤104，响应于配送人员的第一发送指令，确定通知信息的发送方式，并将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端，其中，发送方式包括外呼方式或短信方式。

在该步骤中，接收配送人员的第一发送指令，解析该第一发送指令，确定通知信息的发送方式，发送方式包括外呼方式或短信方式，外呼方式是指服务器呼出服务主动发起对目标对象的呼叫，在目标对象接听后以语音形式播报通知信息，短信方式是指通知信息以短信的形式发送至目标对象。进一步地，将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端。

在本申请的一个实施例中，响应于配送人员的第一发送指令，确定通知信息的发送方式，包括：若第一发送指令为配送人员对显示的外呼控件进行操作所触发，则确定通知信息的发送方式为外呼方式；或者，若第一发送指令为配送人员对显示的发送短信控件进行操作所触发，则确定通知信息的发送方式为短信方式。

示例性地，如图2所示，发送通知页面上显示有发送方式控件，包括外呼控件“发起外呼”和发送短信控件“发送短信”，通过配送人员对发送方式控件的操作触发第一发送指令，第一发送指令的作用包括发送方式的确定以及通知信息的提交。在编辑完通知信息后，如果配送人员点击外呼控件“发起外呼”，则确定发送方式为外呼方式，进而将通知信息和外呼方式的信息上传至服务器；如果配送人员点击发送短信控件“发送短信”，则确定发送方式为短信方式，进而将通知信息和短信方式的信息上传至服务器。

通过上述方式，使得配送人员可以自由选择通知信息的发送方式，提高通知信息发送方式的灵活性，满足配送人员对通知信息的不同发送需求。

发送通知信息支持不同发送场景，也即，在配送人员联系不上商家时，向商家的终端发送通知信息，在配送人员联系不上顾客时，向顾客的终端发送通知信息。不同发送场景可在订单页面进行选择，选择后，再进入发送通知页面。

需要说明的是，在向服务器提交通知信息时，支持二次确认弹窗，展示通知信息，通过二次确认避免配送人员对通知信息的误发送。向服务器提交通知信息后，显示提示信息“通知信息提交成功”，以使配送人员知晓通知信息提交成功，这里需要注意的是，提交成功指的是向服务器提交成功，不代表服务器向目标对象的终端发送成功。

另外，本申请实施例可支持单个订单的批量联系发送通知，批量联系是指若目标对象有多个号码(包括下单号码、备用号码等)时，同时向目标对象的多个号码发送通知信息。

本申请实施例，针对听障或语障配送人员联系不到顾客或商家的异常场景，提供配送人员向顾客或商家发送通知信息的方式，保障此类配送人员能够联系到顾客或商家，保证履约过程的正常进行，解决了配送人员因听障或语障的缘故，无法联络顾客或商家导致的超时或履约不完成的问题，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，以及减少由此引起的客诉量。

在本申请的一个实施例中，设置防频机制。具体地，在将通知信息和发送方式上传至服务器之后，还包括：接收配送人员对通知信息的第二发送指令，若第二发送指令的触发时间与第一发送指令的触发时间的时间间隔小于或等于预设时间阈值，则不向服务器发送通知信息，并显示提示信息，提示信息用于指示配送人员在预设时间阈值后发送通知信息。

在该实施例中，每笔订单多次发送通知信息的间隔需要具有一定的限制，例如限制3分钟。如果配送人员触发的相邻两次发送指令的时间间隔在预设时间阈值之内，则显示提示信息，以提示配送人员通知信息发送的较频繁，需要在预设时间阈值后再次发送，例如显示“您刚发起过智能呼叫，请耐心等待”。

本申请实施例，通过设置防频机制，防止通知信息发送的过于频繁，避免浪费通信资源以及发送出现错误。

在本申请的一个实施例中，支持标签添加功能。具体地，接收配送人员对显示的标签添加控件进行操作所触发的标签添加指令，解析标签添加指令，获取自定义原因标签；将自定义原因标签与已存在的原因标签进行比较；若自定义原因标签与已存在的原因标签不相同，则存储自定义原因标签。

在该实施例中，对于每个信息模板，均支持配送人员填写原因标签，生成自定义原因标签，示例性地，如图2所示，配送人员如果需要新增原因标签，则点击标签添加控件“添加”。并且，填写后需要对自定义原因标签进行校验，使得新增加的自定义原因标签不能和已有原因标签重复。

另外，添加自定义原因标签时，限制标签字数上限为预设字数(例如20个)，避免原因标签字数过多超过对其限定的显示区域。

通过上述方式，实现配送人员对原因标签的自定义，满足配送人员的不同通知信息需求。

在上述任一技术方案中，可选地，在接收配送人员对显示的标签添加控件进行操作所触发的标签添加指令之前，还包括：获取已存在的原因标签的数量，若数量小于或等于预设数量阈值，则显示标签添加控件。

在该实施例中，限定显示的原因标签的数量，以避免原因标签的数量过多超过对其限定的显示区域。如果显示的原因标签的数量未达到预设数量阈值，则显示标签添加控件，支持配送人员继续添加原因标签；如果显示的原因标签的数量达到预设数量阈值，则不支持配送人员继续添加原因标签，标签添加控件消失。

在本申请的一个实施例中，支持标签删除功能。具体地，接收配送人员对已存在的原因标签的标签删除指令，确定待删除原因标签；若待删除原因标签为自定义原因标签，则删除待删除原因标签。

在该实施例中，当配送人员对某个或某些原因标签不再需要时，可对原因标签进行删除。需要说明的是，原因标签中除了自定义原因标签，还包括系统预设原因标签，系统预设原因标签是根据其他配送人员的联系原因所生成的，系统预设原因标签不可删除，配送人员仅能够删除自定义原因标签。

通过上述方式，实现配送人员对原因标签的删除，满足配送人员的使用需求。

在本申请的一个实施例中，支持对通知信息的发送状态查看的功能。具体地，在将通知信息和发送方式的信息上传至服务器之后，还包括：接收配送人员对通知信息的状态查询指令，将状态查询指令发送至服务器，以供服务器查询通知信息的发送状态；接收并显示服务器反馈的通知信息的发送状态；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

在该实施例中，配送人员触发对通知信息的状态查询指令，将状态查询指令发送至服务器。服务器调用apollo运单，获取通知信息的发送状态，并反馈至配送人员的终端。配送人员的终端接收后，将通知信息的发送状态进行显示，使得配送人员能够清晰地了解到通知信息的发送状态。

其中，若通知信息处于拨打中或发送中，则通知信息的发送状态为通知信息为发送中；若目标对象已接听或读取，则通知信息的发送状态为通知信息以被目标对象接收；若目标对象未接听或读取，则通知信息的发送状态为通知信息需重新发送；若出现系统异常，则通知信息的发送状态为通知信息需重新发送。另外，若出现系统异常，还可以返回提示信息“请尝试其他方式联系”。

需要说明的是，如果目标对象有多个号码需同时呼出，通知信息的发送状态的展示规则如下：如果只要有一个号码接听了，则展示通知信息以被目标对象接收；如果当前无一号码接听，且只要有一个号码在拨打中，则展示通知信息为发送中；如果所有号码都拨打完了，若都未接听，则展示通知信息需重新发送；所有号码均为异常状态，则展示通知信息需重新发送。

在本申请的一个实施例中，支持对异常订单的报备功能。具体地，在将通知信息和发送方式的信息上传至服务器之后，还包括：接收配送人员对目标对象的订单的配送报备指令，向服务器发送配送报备指令，以供服务器查询通知信息的发送状态，并根据发送状态生成报备处理结果；接收并显示服务器反馈的报备处理结果。

在该实施例中，配送人员可对异常订单进行报备，由服务器根据查询到的通知信息的发送状态，生成报备处理结果，包括报备成功或失败，以及报备成功后配送人员所享权益。接收到服务器反馈的报备处理结果后，将报备处理结果进行展示。另外，服务器还可以将查询到的通知信息的发送状态反馈给配送人员的终端以进行显示。

若报备成功，则配送人员本单免超时处罚，本单如果继续送达，配送人员可获得一定额度的补偿金，本单如果顾客未在30分钟内选择再次配送，配送人员可申请无责取消，获得一定额度的补偿金。

示例性地，听障或语障配送人员发出待报备指令后，如图3所示，显示报备页面，报备原因为联系不上顾客，报备页面显示报备后须知，并且，在报备页面提供联系顾客的接口，听障或语障配送人员可以选择在报备页面通过外呼方式或短信方式再次尝试联系顾客，若仍然无法联系上顾客，则点击确认报备的控件，向服务器发送配送报备指令。

通过上述方式，支持配送人员对异常订单的报备，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，保障听障或语障配送人员的权益。

当然，除了听障或语障的配送人员，正常配送人员再未联系到顾客或商家的情况下，也可以进行异常订单的报备。示例性地，正常配送人员发出配送报备指令后，如图4所示，显示报备页面，报备原因为联系不上顾客，报备页面显示报备后须知，并且，在报备页面提供拨打顾客电话的接口，正常配送人员可以选择在报备页面再次尝试联系顾客，若仍然无法联系上顾客，则点击确认报备的控件，向服务器发送配送报备指令。

本申请实施例提供了一种配送通知方法，应用于服务器，如图5所示，该方法包括：

步骤501，接收来自配送人员的终端的通知信息以及通知信息对应的发送方式的信息；

步骤502，根据发送方式，将通知信息发送至目标对象的终端。

其中，配送人员为目标类型人员，通知信息为根据配送人员所选择的目标信息模板和目标原因标签所生成，发送方式为根据配送人员所选择的发送方式控件所确定，发送方式包括外呼方式或短信方式，目标对象包括商家或顾客。

在该实施例中，当配送人员有联系目标对象(也即，商家或顾客)的需求时，触发联系目标对象的指令，并根据配送人员的人员类型信息判断配送人员是否为目标类型人员，如果判断出配送人员为目标类型人员，则表明配送人员是无法利用正常的拨打电话的方式与目标对象沟通的，在此情况下，为了能够顺利联系到目标对象，为目标类型的配送人员提供向目标对象发送通知信息的功能，通知信息可由配送人员通过选择目标信息模板和目标原因标签进行编辑。配送人员触发第一发送指令后，将通知信息和发送方式的信息上传至服务器。

服务器在接收到通知信息和发送方式的信息后，按照发送方式将通知信息发送至目标对象的终端。其中，发送方式包括外呼方式或短信方式，外呼方式是指服务器呼出服务主动发起对目标对象的呼叫，在目标对象接听后以语音形式播报通知信息，短信方式是指通知信息以短信的形式发送至目标对象。

需要说明的是，服务器接收到通知信息后，向配送人员的终端反馈通知信息提交成功的提示信息，以使配送人员知晓通知信息提交成功，这里需要注意的是，提交成功指的是配送人员的终端向服务器提交成功，不代表服务器向目标对象的终端发送成功。

本申请实施例可支持单个订单的批量联系发送通知，批量联系是指若目标对象有多个号码(包括下单号码、备用号码等)时，服务器同时向目标对象的多个号码发送通知信息。

本申请实施例，针对听障或语障配送人员联系不到顾客或商家的异常场景，提供配送人员向顾客或商家发送通知信息的方式，保障此类配送人员能够联系到顾客或商家，保证履约过程的正常进行，解决了配送人员因听障或语障的缘故，无法联络顾客或商家导致的超时或履约不完成的问题，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，以及减少由此引起的客诉量。

在本申请的一个实施例中，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：接收来自配送人员的终端对通知信息的状态查询指令，查询通知信息的发送状态；将通知信息的发送状态反馈至配送人员的终端；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

在该实施例中，服务器接收配送人员触发的对通知信息的状态查询指令，响应于该状态查询指令，调用apollo运单，获取通知信息的发送状态，并反馈至配送人员的终端。配送人员的终端接收后，将通知信息的发送状态进行显示，使得配送人员能够清晰地了解到通知信息的发送状态。

示例性地，如图6所示，配送人员的终端发送状态查询指令，服务器的履约周边系统调用通用查询服务查询配送人员的人员类型信息，通用查询服务向履约周边系统返回结果。如果是听障或语障配送人员，履约周边系统则从服务器的apollo运单获取对顾客的外呼拨打记录，并筛选顾客号码最近一次外呼拨打记录，并将外呼拨打记录进行封装，对封装后的外呼拨打记录进行处理，也即根据外呼拨打记录确定外呼拨打状态，最后反馈外呼拨打状态至配送人员的终端。

其中，若通知信息处于拨打中或发送中，则通知信息的发送状态为通知信息为发送中；若目标对象已接听或读取，则通知信息的发送状态为通知信息以被目标对象接收；若目标对象未接听或读取，则通知信息的发送状态为通知信息需重新发送；若出现系统异常，则通知信息的发送状态为通知信息需重新发送。另外，若出现系统异常，还可以返回提示信息“请尝试其他方式联系”。

在本申请的一个实施例中，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：接收来自配送人员对目标对象的订单的配送报备指令，查询通知信息的发送状态，并根据发送状态生成报备处理结果；将报备处理结果反馈至配送人员的终端。

在该实施例中，配送人员可对异常订单进行报备，由服务器根据查询到的通知信息的发送状态，生成报备处理结果，包括报备成功或失败，以及报备成功后配送人员所享权益。服务器将报备处理结果反馈至配送人员的终端，以供配送人员的终端对报备处理结果进行展示。

示例性地，如图7所示，配送人员的终端发送待报备指令，服务器的履约周边系统调用通用查询服务查询配送人员的人员类型信息，通用查询服务向履约周边系统返回结果。如果是听障或语障配送人员，履约周边系统则从服务器的apollo运单获取对顾客的外呼拨打记录，并筛选顾客号码最近一次外呼拨打记录，并将外呼拨打记录进行封装，对封装后的外呼拨打记录进行处理，也即根据外呼拨打记录确定外呼拨打状态，反馈外呼拨打状态至配送人员的终端。配送人员的终端判断外呼拨打状态，可以调转外呼页面选择再次进行外呼。最后，配送人员的终端发送配送报备指令，确认进行报备，履约周边系统根据外呼拨打状态生成报备处理结果，并反馈报备处理结果至配送人员的终端。

通过上述方式，支持配送人员对异常订单的报备，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，保障听障或语障配送人员的权益。

在本申请的一个实施例中，在根据发送方式，将通知信息发送至目标对象的终端之后，还包括：统计预设时间段内，配送人员的终端发送的通知信息的次数；根据次数，计算预设时间段内的通知费用；按照通知费用对配送人员的账户进行扣费处理，并将通知费用反馈至配送人员的终端。

在该实施例中，提供了通知计费的方式。具体地，统计预设时间段内，配送人员的终端发送的通知信息的次数，根据次数，计算预设时间段内的通知费用，从而进行扣费处理，以及提醒配送人员扣费通知和通知费用的具体金额。

需要说明的是，若通知信息为短信方式，则根据每个短信的单价和发送次数，计算出预设时间段内的所有通知信息的通知费用。

若通知信息为外呼方式，由于通知信息已被配送人员编辑好，可以确定通知信息的字数，可根据预存的每个文字的语音播报速度确定通知信息的播报时长，从而根据时长和单价计算每个通知信息的费用，进而能够计算出预设时间段内的所有通知信息的通知费用。

当然，也可以在每次外呼时，记录每次外呼的外呼时长，从而进行定价。示例性地，如图8所示，配送人员的终端发起外呼，服务器的外呼组件进行外呼，服务器的apollo运单记录每单外呼时长，服务器的定价系统获取每单外呼时长，计算月度累计外呼时长，并计算外呼费用，服务器的清结算系统收取费用，并向配送人员的终端发送月度账单。

通过上述方式，实现了对通知信息进行准确计费。

作为上述应用于配送人员的终端的配送通知方法的具体实现，本申请实施例提供了一种配送通知装置，应用于配送人员的终端。如图9所示，该配送通知装置900包括：类型确定模块901、显示模块902、信息生成模块903、发送方式确定模块904以及发送模块905。

其中，类型确定模块901，用于响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据人员类型信息判断配送人员是否为目标类型人员，其中，目标对象包括商家或顾客；显示模块902，用于若配送人员为目标类型人员，则显示至少一个信息模板以及至少一个原因标签；信息生成模块903，用于响应于配送人员对至少一个信息模板中目标信息模板以及对至少一个原因标签中目标原因标签的选择指令，根据目标信息模板和目标原因标签，生成通知信息；发送方式确定模块904，用于响应于配送人员的第一发送指令，确定通知信息的发送方式；发送模块905，用于将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端，其中，发送方式包括外呼方式或短信方式。

在该实施例中，在接收到配送人员触发联系目标对象的指令后，获取该配送人员的人员类型信息，根据配送人员的人员类型信息对配送人员的类型进行确定，也即，判断配送人员是否为目标类型人员。如果判断出配送人员为目标类型人员，则表明配送人员是无法利用正常的拨打电话的方式与目标对象沟通的，在此情况下，为了能够顺利联系到目标对象，为目标类型的配送人员提供向目标对象发送通知信息的功能，通知信息可由配送人员通过选择目标信息模板和目标原因标签进行编辑。接收配送人员的第一发送指令，解析该第一发送指令，确定通知信息的发送方式，将通知信息和发送方式的信息上传至服务器，以供服务器按照发送方式将通知信息发送至目标对象的终端。

本申请实施例，针对听障或语障配送人员联系不到顾客或商家的异常场景，提供配送人员向顾客或商家发送通知信息的方式，保障此类配送人员能够联系到顾客或商家，保证履约过程的正常进行，解决了配送人员因听障或语障的缘故，无法联络顾客或商家导致的超时或履约不完成的问题，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，以及减少由此引起的客诉量。

进一步地，该装置还包括：接收模块，用于接收配送人员对至少一个信息模板中目标信息模板的第一选择指令；信息生成模块903，具体用于响应于第一选择指令，确定目标信息模板；接收模块，还用于接收配送人员对至少一个原因标签中目标原因标签的第二选择指令；信息生成模块903，具体用于响应于第二选择指令，确定目标原因标签，并根据目标信息模板和目标原因标签，生成通知信息。

进一步地，发送方式确定模块904，具体用于若第一发送指令为配送人员对显示的外呼控件进行操作所触发，则确定通知信息的发送方式为外呼方式；或者，若第一发送指令为配送人员对显示的发送短信控件进行操作所触发，则确定通知信息的发送方式为短信方式。

进一步地，接收模块，还用于接收配送人员对通知信息的第二发送指令；发送模块905，还用于若第二发送指令的触发时间与第一发送指令的触发时间的时间间隔小于或等于预设时间阈值，则不向服务器发送通知信息；显示模块902，还用于显示提示信息，提示信息用于指示配送人员在预设时间阈值后发送通知信息。

进一步地，接收模块，还用于接收配送人员对显示的标签添加控件进行操作所触发的标签添加指令；该装置还包括：存储模块，用于：解析标签添加指令，获取自定义原因标签；将自定义原因标签与已存在的原因标签进行比较；若自定义原因标签与已存在的原因标签不相同，则存储自定义原因标签。

进一步地，显示模块902，还用于获取已存在的原因标签的数量，若数量小于或等于预设数量阈值，则显示标签添加控件。

进一步地，接收模块，还用于接收配送人员对已存在的原因标签的标签删除指令；该装置还包括：删除模块，用于：确定待删除原因标签；若待删除原因标签为自定义原因标签，则删除待删除原因标签。

进一步地，接收模块，还用于接收配送人员对通知信息的状态查询指令；发送模块905，还用于将状态查询指令发送至服务器，以供服务器查询通知信息的发送状态；接收模块，还用于接收服务器反馈的通知信息的发送状态；显示模块902，还用于显示通知信息的发送状态；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

进一步地，接收模块，还用于接收配送人员对目标对象的订单的配送报备指令；发送模块905，还用于向服务器发送配送报备指令，以供服务器查询通知信息的发送状态，并根据发送状态生成报备处理结果；接收模块，还用于接收服务器反馈的报备处理结果；显示模块902，还用于显示报备处理结果。

作为上述应用于服务器的配送通知方法的具体实现，本申请实施例提供了一种配送通知装置，应用于服务器。如图10所示，该配送通知装置1000包括：接收模块1001以及发送模块1002。

其中，接收模块1001，用于接收来自配送人员的终端的通知信息以及通知信息对应的发送方式的信息；发送模块1002，用于根据发送方式，将通知信息发送至目标对象的终端；其中，配送人员为目标类型人员，通知信息为根据配送人员所选择的目标信息模板和目标原因标签所生成，发送方式为根据配送人员所选择的发送方式控件所确定，发送方式包括外呼方式或短信方式，目标对象包括商家或顾客。

在该实施例中，当配送人员有联系目标对象(也即，商家或顾客)的需求时，触发联系目标对象的指令，并根据配送人员的人员类型信息判断配送人员是否为目标类型人员，如果判断出配送人员为目标类型人员，则表明配送人员是无法利用正常的拨打电话的方式与目标对象沟通的，在此情况下，为了能够顺利联系到目标对象，为目标类型的配送人员提供向目标对象发送通知信息的功能，通知信息可由配送人员通过选择目标信息模板和目标原因标签进行编辑。配送人员触发第一发送指令后，将通知信息和发送方式的信息上传至服务器。

服务器在接收到通知信息和发送方式的信息后，按照发送方式将通知信息发送至目标对象的终端。其中，发送方式包括外呼方式或短信方式，外呼方式是指服务器呼出服务主动发起对目标对象的呼叫，在目标对象接听后以语音形式播报通知信息，短信方式是指通知信息以短信的形式发送至目标对象。

本申请实施例，针对听障或语障配送人员联系不到顾客或商家的异常场景，提供配送人员向顾客或商家发送通知信息的方式，保障此类配送人员能够联系到顾客或商家，保证履约过程的正常进行，解决了配送人员因听障或语障的缘故，无法联络顾客或商家导致的超时或履约不完成的问题，减少因听障或语障配送人员联系不到顾客或商家所产生的罚单，以及减少由此引起的客诉量。

进一步地，接收模块1001，还用于接收来自配送人员的终端对通知信息的状态查询指令；该装置还包括：查询模块，用于查询通知信息的发送状态；发送模块1002，还用于将通知信息的发送状态反馈至配送人员的终端；其中，通知信息的发送状态包括通知信息为发送中、通知信息以被目标对象接收、通知信息需重新发送中的任一项。

进一步地，接收模块1001，还用于接收来自配送人员对目标对象的订单的配送报备指令；查询模块，用于查询通知信息的发送状态；该装置还包括：结果生成模块，用于根据发送状态生成报备处理结果；发送模块1002，还用于将报备处理结果反馈至配送人员的终端。

进一步地，该装置还包括：计算模块，用于统计预设时间段内，配送人员的终端发送的通知信息的次数，以及根据次数，计算预设时间段内的通知费用；该装置还包括：扣费模块，用于按照通知费用对配送人员的账户进行扣费处理；发送模块1002，还用于将通知费用反馈至配送人员的终端。

本申请实施例中的配送通知装置可以是电子设备，也可以是电子设备中的部件，例如集成电路或芯片。该电子设备可以是终端，也可以为除终端之外的其他设备。示例性的，电子设备可以为手机、平板电脑、笔记本电脑、掌上电脑、车载电子设备、移动上网装置(Mobile Internet Device，MID)、增强现实(Augmented Reality，AR)/虚拟现实(VirtualReality，VR)设备、机器人、可穿戴设备、超级移动个人计算机(Ultra-Mobile PersonalComputer，UMPC)、上网本或者个人数字助理(Personal Digital Assistant，PDA)等，还可以为服务器、网络附属存储器(Network Attached Storage，NAS)、个人计算机(PersonalComputer，PC)、电视机(Television，TV)、柜员机或者自助机等，本申请实施例不作具体限定。

本申请实施例中的配送通知装置可以为具有操作系统的装置。该操作系统可以为安卓(Android)操作系统，可以为ios操作系统，还可以为其他可能的操作系统，本申请实施例不作具体限定。

本申请实施例提供的配送通知装置能够实现图1或图5的方法实施例实现的各个过程，为避免重复，这里不再赘述。

本申请实施例还提供一种电子设备，如图11所示，该电子设备1100包括处理器1101和存储器1102，存储器1102上存储有可在处理器1101上运行的程序或指令，该程序或指令被处理器1101执行时实现上述配送通知方法实施例的各个步骤，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，本申请实施例中的电子设备包括上述的移动电子设备和非移动电子设备。

存储器1102可用于存储软件程序以及各种数据。存储器1102可主要包括存储程序或指令的第一存储区和存储数据的第二存储区，其中，第一存储区可存储操作系统、至少一个功能所需的应用程序或指令(比如声音播放功能、图像播放功能等)等。此外，存储器1102可以包括易失性存储器或非易失性存储器，或者，存储器1102可以包括易失性和非易失性存储器两者。其中，非易失性存储器可以是只读存储器(Read-Only Memory，ROM)、可编程只读存储器(Programmable ROM，PROM)、可擦除可编程只读存储器(Erasable PROM，EPROM)、电可擦除可编程只读存储器(Electrically EPROM，EEPROM)或闪存。易失性存储器可以是随机存取存储器(Random Access Memory，RAM)，静态随机存取存储器(Static RAM，SRAM)、动态随机存取存储器(Dynamic RAM，DRAM)、同步动态随机存取存储器(Synchronous DRAM，SDRAM)、双倍数据速率同步动态随机存取存储器(Double Data Rate SDRAM，DDRSDRAM)、增强型同步动态随机存取存储器(Enhanced SDRAM，ESDRAM)、同步连接动态随机存取存储器(Synch link DRAM，SLDRAM)和直接内存总线随机存取存储器(Direct Rambus RAM，DRRAM)。本申请实施例中的存储器1102包括但不限于这些和任意其它适合类型的存储器。

处理器1101可包括一个或多个处理单元；可选的，处理器1101集成应用处理器和调制解调处理器，其中，应用处理器主要处理涉及操作系统、用户界面和应用程序等的操作，调制解调处理器主要处理无线通信信号，如基带处理器。可以理解的是，上述调制解调处理器也可以不集成到处理器1101中。

本申请实施例还提供一种可读存储介质，可读存储介质上存储有程序或指令，该程序或指令被处理器执行时实现上述配送通知方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例还提供了一种芯片，芯片包括处理器和通信接口，通信接口和处理器耦合，处理器用于运行程序或指令，实现上述配送通知方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

应理解，本申请实施例提到的芯片还可以称为系统级芯片、系统芯片、芯片系统或片上系统芯片等。

本申请实施例还提供一种计算机程序产品，该程序产品被存储在存储介质中，该程序产品被至少一个处理器执行以实现如上述配送通知方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。此外，需要指出的是，本申请实施方式中的方法和装置的范围不限按示出或讨论的顺序来执行功能，还可包括根据所涉及的功能按基本同时的方式或按相反的顺序来执行功能，例如，可以按不同于所描述的次序来执行所描述的方法，并且还可以添加、省去、或组合各种步骤。另外，参照某些示例所描述的特征可在其他示例中被组合。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (10)

1.一种配送通知方法，其特征在于，包括：

响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据所述人员类型信息判断所述配送人员是否为目标类型人员，其中，所述目标对象包括商家或顾客；

若所述配送人员为目标类型人员，则显示至少一个信息模板以及至少一个原因标签；

响应于所述配送人员对所述至少一个信息模板中目标信息模板以及对所述至少一个原因标签中目标原因标签的选择指令，根据所述目标信息模板和所述目标原因标签，生成通知信息；

响应于所述配送人员的第一发送指令，确定所述通知信息的发送方式，并将所述通知信息和所述发送方式的信息上传至服务器，以供所述服务器按照所述发送方式将所述通知信息发送至所述目标对象的终端，其中，所述发送方式包括外呼方式或短信方式。

2.根据权利要求1所述的方法，其特征在于，所述响应于所述配送人员对所述至少一个信息模板中目标信息模板以及对所述至少一个原因标签中目标原因标签的选择指令，根据所述目标信息模板和所述目标原因标签，生成通知信息，包括：

接收所述配送人员对所述至少一个信息模板中目标信息模板的第一选择指令，响应于所述第一选择指令，确定所述目标信息模板；

接收所述配送人员对所述至少一个原因标签中目标原因标签的第二选择指令，响应于所述第二选择指令，确定所述目标原因标签，并根据所述目标信息模板和所述目标原因标签，生成所述通知信息。

3.根据权利要求1所述的方法，其特征在于，所述响应于所述配送人员的第一发送指令，确定所述通知信息的发送方式，包括：

若所述第一发送指令为所述配送人员对显示的外呼控件进行操作所触发，则确定所述通知信息的发送方式为所述外呼方式；或者，

若所述第一发送指令为所述配送人员对显示的发送短信控件进行操作所触发，则确定所述通知信息的发送方式为所述短信方式。

4.根据权利要求1所述的方法，其特征在于，在所述将所述通知信息和所述发送方式上传至服务器之后，还包括：

接收所述配送人员对所述通知信息的第二发送指令，若所述第二发送指令的触发时间与所述第一发送指令的触发时间的时间间隔小于或等于预设时间阈值，则不向所述服务器发送所述通知信息，并显示提示信息，所述提示信息用于指示所述配送人员在预设时间阈值后发送所述通知信息。

5.根据权利要求1至4中任一项所述的方法，其特征在于，所述方法还包括：

接收所述配送人员对显示的标签添加控件进行操作所触发的标签添加指令，解析所述标签添加指令，获取自定义原因标签；

将所述自定义原因标签与已存在的原因标签进行比较；

若所述自定义原因标签与已存在的原因标签不相同，则存储所述自定义原因标签。

6.一种配送通知方法，其特征在于，包括：

接收来自配送人员的终端的通知信息以及所述通知信息对应的发送方式的信息；

根据所述发送方式，将所述通知信息发送至目标对象的终端；

其中，所述配送人员为目标类型人员，所述通知信息为根据所述配送人员所选择的目标信息模板和目标原因标签所生成，所述发送方式为根据所述配送人员所选择的发送方式控件所确定，所述发送方式包括外呼方式或短信方式，所述目标对象包括商家或顾客。

7.一种配送通知装置，其特征在于，包括：

类型确定模块，用于响应于配送人员联系目标对象的指令，获取配送人员的人员类型信息，根据所述人员类型信息判断所述配送人员是否为目标类型人员，其中，所述目标对象包括商家或顾客；

显示模块，用于若所述配送人员为目标类型人员，则显示至少一个信息模板以及至少一个原因标签；

信息生成模块，用于响应于所述配送人员对所述至少一个信息模板中目标信息模板以及对所述至少一个原因标签中目标原因标签的选择指令，根据所述目标信息模板和所述目标原因标签，生成通知信息；

发送方式确定模块，用于响应于所述配送人员的第一发送指令，确定所述通知信息的发送方式；

发送模块，用于将所述通知信息和所述发送方式的信息上传至服务器，以供所述服务器按照所述发送方式将所述通知信息发送至所述目标对象的终端，其中，所述发送方式包括外呼方式或短信方式。

8.一种配送通知装置，其特征在于，包括：

接收模块，用于接收来自配送人员的终端的通知信息以及所述通知信息对应的发送方式的信息；

发送模块，用于根据所述发送方式，将所述通知信息发送至目标对象的终端；

其中，所述配送人员为目标类型人员，所述通知信息为根据所述配送人员所选择的目标信息模板和目标原因标签所生成，所述发送方式为根据所述配送人员所选择的发送方式控件所确定，所述发送方式包括外呼方式或短信方式，所述目标对象包括商家或顾客。

9.一种电子设备，其特征在于，包括处理器和存储器，所述存储器存储有在所述处理器上运行的程序或指令，所述程序或指令被所述处理器执行时实现如权利要求1至5中任一项所述的配送通知方法的步骤，或者如权利要求6所述的配送通知方法的步骤。

10.一种可读存储介质，其上存储有程序或指令，其特征在于，所述程序或指令被处理器执行时实现如权利要求1至5中任一项所述的配送通知的步骤，或者如权利要求6所述的配送通知方法的步骤。

Images