CN113947355A - 报备信息的处理方法、装置及电子设备 - Google Patents

Abstract

本申请公开了一种报备信息的处理方法、装置及电子设备，涉及信息处理技术领域。其中方法包括：首先根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；然后监测所述联系方式列表中的各个联系方式的联系状态信息；并依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。本申请可避免配送员虚假报备联系不上用户的异常情况发生，保证了报备信息的真实性。

Description

报备信息的处理方法、装置及电子设备

技术领域

本申请涉及信息处理技术领域，尤其是涉及到一种报备信息的处理方法、装置及电子设备。

背景技术

配送员送货到达收货人附近时，会拨打该收货人的联系电话，有时经常会遇到联系不上收货人的情况，于是为了避免送货超时，配送员可选择进行报备，以避免罚单损失。

目前，配送员往往在拨打收货人的其中一个电话未拨通后，就开始报备联系不上收货人，而收货人的其他备用电话很可能可以拨通，因此会存在虚假报备的异常情况，无法保证报备信息的真实性。

发明内容

有鉴于此，本申请提供了一种报备信息的处理方法、装置及电子设备，主要目的在于改善目前现有技术中会存在虚假报备的异常情况，无法保证报备信息真实性的技术问题。

依据本申请的一个方面，提供了一种报备信息的处理方法，该方法包括：

根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；

监测所述联系方式列表中的各个联系方式的联系状态信息；

依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。

可选的，所述依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息，具体包括：

依据所述各个联系方式的联系状态信息，并结合本地终端位置与所述配送订单的收货地址之间的距离、和/或可用报备次数，综合确定是否允许操作发送所述报备信息。

可选的，依据所述各个联系方式的联系状态信息，以及本地终端位置与所述配送订单的收货地址之间的距离、和可用报备次数，综合确定是否允许操作发送所述报备信息，具体包括：

若所述联系方式列表中的联系方式均为联系后未成功的状态、且所述距离小于或等于预设距离阈值、且所述可用报备次数大于0，则允许操作发送所述报备信息；

若所述联系方式列表中存在至少一联系方式为未联系的状态、和/或所述距离大于预设距离阈值、和/或所述可用报备次数等于0，则不允许操作发送所述报备信息。

可选的，若按照目标联系方式联系后未接通、或接通后未接收到所述用户反馈的联系信息，则确定所述目标联系方式为联系后未成功的状态。

可选的，所述允许操作发送所述报备信息，具体包括：

将所述报备信息的报备异常按钮，由不可点击状态变更为可点击状态；或，

允许显示所述报备信息的报备异常按钮；或，

响应于所述报备信息的发送指令，触发发送所述报备信息。

可选的，所述方法还包括：

若存在未及时接通所述用户主动联系的信息，则为所述配送订单添加预设标记并进行突出显示。

可选的，所述为所述配送订单添加预设标记，具体包括：

在所述配送订单的联系入口、和/或联系列表、和/或所述联系方式列表中增加预设标记，所述联系列表中包含所述配送订单涉及到的各个用户的联系功能按钮。

可选的，所述方法还包括：

响应于根据所述预设标记触发的回拨指令，根据所述用户主动发起联系的联系方式进行回拨。

可选的，在允许操作发送所述报备信息之后，所述方法还包括：

若成功发送所述报备信息，则根据所述报备信息，显示所述配送订单的报备状态信息。

可选的，所述用户的主要联系方式和备用联系方式为手机虚拟号码。

依据本申请的另一方面，提供了一种报备信息的处理装置，该装置包括：

获取模块，用于根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；

监测模块，用于监测所述联系方式列表中的各个联系方式的联系状态信息；

确定模块，用于依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。

依据本申请又一个方面，提供了一种存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现上述报备信息的处理方法。

依据本申请再一个方面，提供了一种电子设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现上述报备信息的处理方法。

借由上述技术方案，本申请提供的一种报备信息的处理方法、装置及电子设备，与目前现有技术相比，本申请针对配送订单，可依据包括用户主要联系方式和备用联系方式在内的所有联系方式进行联系状态的监测，进而确定是否允许操作发送联系不上用户的报备信息。在配送员未拨打用户全部电话而想要报备联系不上用户时，不允许配送员操作发送该报备信息。进而可避免配送员虚假报备联系不上用户的异常情况发生，保证了报备信息的真实性。

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

附图说明

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

图1示出了本申请实施例提供的一种报备信息的处理方法的流程示意图；

图2示出了本申请实施例提供的另一种报备信息的处理方法的流程示意图；

图3示出了本申请实施例提供的联系入口示例的示意图；

图4示出了本申请实施例提供的联系列表示例的示意图；

图5示出了本申请实施例提供的联系方式列表示例的示意图；

图6示出了本申请实施例提供的一种报备信息的处理装置的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本申请。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

为了改善目前现有技术中会存在虚假报备的异常情况，无法保证报备信息真实性的技术问题。本实施例提供了一种报备信息的处理方法，如图1所示，该方法包括：

步骤101、根据用户的配送订单，获取用户的联系方式列表。

本实施例中的用户可为与配送订单的配送任务相关的目标用户，如目标用户可以是收货人、或发货人、或下单用户、或楼宇配送站长(如负责收货人所在大厦内的各楼层配送任务)等。

对于本实施例的执行主体可为配送员的客户端。例如，根据用户的配送订单，可向后台服务器请求获取该用户的联系方式列表，其中，后台服务器可查询到该配送订单涉及的该用户的联系方式列表。

联系方式列表中可包含用户的主要联系方式和备用联系方式。用户的联系方式可为用户的手机号、和/或即时通讯(Instant Messaging，IM)账号、和/或电子邮箱等。如果联系方式是用户手机号，那么为了保证用户的隐私性，可选的，用户的主要联系方式和备用联系方式可为手机虚拟号码，该手机虚拟号码与用户的真实手机号预先建立有映射关系，并且保存在后台服务器端侧，使得用户的真实手机号在前端不可见。

本实施例方法在配送员报备联系不上用户之前，可依据包括用户主要联系方式和备用联系方式在内的所有联系方式进行联系状态的监测，具体可执行步骤102所示的过程。

步骤102、监测联系方式列表中的各个联系方式的联系状态信息。

例如，如果联系方式为用户手机号，则该联系方式的联系状态信息可包括已接通、未接通、待拨打等状态信息，其中，已接通状态还可具体分为已接通且收到用户有效回复(可确定为有效联系)、和已接通但未收到用户有效回复等，而用户有效回复可通过语音识别和预设关键词进行判断。

再例如，如果联系方式为即时通讯账号，则该联系方式的联系状态信息为已联系、未联系等状态信息，其中，已联系还可具体分为已发消息且确认消息已触达用户(可确定为有效联系)、和已发消息但消息未触达用户(如用户消息未读)等。

步骤103、依据联系方式列表中的各个联系方式的联系状态信息，确定是否允许操作发送联系不上用户的报备信息。

例如，当联系方式列表中的全部联系方式均为无效联系的状态时，允许配送员操作发送联系不上用户的报备信息；当联系方式列表中没有或只有部分联系方式为有效联系的状态时，不允许配送员操作发送联系不上用户的报备信息。

与目前现有技术相比，本实施例针对配送订单，可依据包括用户主要联系方式和备用联系方式在内的所有联系方式进行联系状态的监测，进而确定是否允许操作发送联系不上用户的报备信息。在配送员未拨打用户全部电话而想要报备联系不上用户时，不允许配送员操作发送该报备信息。进而可避免配送员虚假报备联系不上用户的异常情况发生，保证了报备信息的真实性。

进一步的，作为上述实施例具体实施方式的细化和扩展，为了完整说明本实施例的实施方式，本实施例还提供了另一种报备信息的处理方法，如图2所示，该方法包括：

步骤201、根据用户的配送订单，获取用户的联系方式列表。

在本实施例中，可在配送订单的订单列表页或订单详情页上展示联系的功能按钮，配送员点击该功能按钮，会输出显示联系列表的浮窗，该联系列表可为一级列表，该联系列表具体可包含配送订单涉及到的各个用户的联系功能按钮。如联系收货人、联系发货人、联系楼宇配送站长(基于该订单的送达地点是否有楼宇配送的服务，确定是否展示该联系楼宇配送站长的功能按钮)等。而在一级列表中可继续选择备用联系收货人或发货人等，进而可显示用户的备用联系方式列表，即二级列表，在该二级列表中包含包括用户主要联系方式和备用联系方式在内的所有联系方式。

步骤202、监测联系方式列表中的各个联系方式的联系状态信息。

后续可依据可用报备次数(如每个配送员的可用报表次数可预先设置，配送员报备后可对该可用报备次数进行更新)、以及联系方式列表中的各个联系方式的联系状态信息，确定是否允许操作发送联系不上用户的报备信息；或者，可依据联系方式列表中的各个联系方式的联系状态信息，以及本地终端(如配送员终端)位置与配送订单的收货地址(配送地址)之间的距离，确定是否允许操作发送联系不上用户的报备信息等。

对于本实施例可根据实际需求预先设置参考条件内容，进而确定是否允许操作发送联系不上用户的报备信息。而考虑到多方面因素，示例性的，以执行步骤203所示的过程进行说明。

步骤203、依据联系方式列表中的各个联系方式的联系状态信息，并结合本地终端位置与配送订单的收货地址之间的距离、和/或可用报备次数，综合确定是否允许操作发送联系不上用户的报备信息。

可选的，依据联系方式列表中的各个联系方式的联系状态信息，并结合本地终端位置与配送订单的收货地址之间的距离，综合确定是否允许操作发送联系不上用户的报备信息的过程具体可包括：若联系方式列表中的联系方式均为联系后未成功的状态(如若按照目标联系方式联系后未接通、或接通后未接收到用户反馈的联系信息，则确定目标联系方式为联系后未成功的状态)、且距离小于或等于预设距离阈值，则允许操作发送联系不上用户的报备信息；若联系方式列表中存在至少一联系方式为未联系的状态、和/或本地终端位置与配送订单的收货地址之间的距离大于预设距离阈值，则不允许操作发送联系不上用户的报备信息。

可选的，依据联系方式列表中的各个联系方式的联系状态信息，并结合可用报备次数，综合确定是否允许操作发送联系不上用户的报备信息的过程具体可包括：若联系方式列表中的联系方式均为联系后未成功的状态(如若按照目标联系方式联系后未接通、或接通后未接收到用户反馈的联系信息，则确定目标联系方式为联系后未成功的状态)、且可用报备次数大于0，则允许操作发送联系不上用户的报备信息；若联系方式列表中存在至少一联系方式为未联系的状态、和/或可用报备次数等于0，则不允许操作发送联系不上用户的报备信息。

可选的，依据联系方式列表中的各个联系方式的联系状态信息，并结合本地终端位置与配送订单的收货地址之间的距离、和可用报备次数，综合确定是否允许操作发送联系不上用户的报备信息的过程具体可包括：若联系方式列表中的联系方式均为联系后未成功的状态(如若按照目标联系方式联系后未接通、或接通后未接收到用户反馈的联系信息，则确定目标联系方式为联系后未成功的状态)、且距离小于或等于预设距离阈值、且可用报备次数大于0，则允许操作发送联系不上用户的报备信息；若联系方式列表中存在至少一联系方式为未联系的状态、和/或本地终端位置与配送订单的收货地址之间的距离大于预设距离阈值、和/或可用报备次数等于0，则不允许操作发送联系不上用户的报备信息。

例如，以联系方式均为用户手机号为例，配送员按照用户的各个手机号逐一进行拨打联系，直至电话联系到该用户为止。如果配送员只拨打了该用户的部分电话均未接通，则不允许操作发送联系不上用户的报备信息；如果配送员经常性的报备联系不上用户，当前可用报备次数已为0，则不允许操作发送联系不上用户的报备信息；如果需要联系的用户为收货人，正常情况下配送员在订单配送过程中距离收货人地址一定范围内(如配送员身在收货人附近)才联系收货人，而配送员当前与订单收货地址之间还有较长的距离，此时可不允许操作发送联系不上用户的报备信息。

如果配送员拨打了该用户的全部电话，主要联系电话和备用电话都打不通或打通后该用户不说话(考虑到手机信号差的场景)、且配送员身在订单收货地址附近、该配送员当前可用报备次数大于0时，可允许配送员操作发送联系不上用户的报备信息。

示例性的，允许操作发送联系不上用户的报备信息，具体可包括：将该报备信息的报备异常按钮，由不可点击状态变更为可点击状态；或，允许显示该报备信息的报备异常按钮(如之前该按钮为隐藏状态)；或，响应于该报备信息的发送指令，触发发送联系不上用户的报备信息，即直接发送该报备信息，而在不允许操作发送该报备信息的情况下，即使配送员输入相应的发送指令，也无法实现上报该报备信息。

为了方便配送员及时了解报备成功，进一步可选的，在允许操作发送联系不上用户的报备信息之后，本实施例方法还包括：若成功发送联系不上用户的报备信息，则根据该联系不上用户的报备信息，显示配送订单的报备状态信息。例如，在配送员报备联系不上收货人后，若配送员点击订单详情页主操作栏按钮“遇到问题”，进入遇到问题列表页时，则选项“联系不上收货人”会显示报备状态信息，如显示“您已报备，正在核实中”。

在具体的应用场景中，有可能配送员在联系用户后未成功(如拨打用户手机号未接通或接通后该用户不说话等)，但该用户后续又主动联系配送员的情况；或者用户由于关注着该订单的配送进度，在判定负责订单配送的配送员靠近自己的收货地址时可主动联系配送员确认新的收货位置(如原定在大厦7楼收件，改为该大厦1楼收件)等。在这些场景下都会收到用户主动联系的信息，如果配送员忙于订单配送未能及时了解到这些信息进行反馈，很可能会影响订单的配送进度。因此，为了解决这一问题，可选的，本实施例方法还可包括：若存在未及时接通用户主动联系的信息，则为配送订单添加预设标记并进行突出显示。

预设标记的样式可根据实际需求进行预先设定。显示该预设标记的目的是为了提醒配送员存在未及时接通用户主动联系的信息，如用户曾主动打电话过来但自己没有及时接听，进而配送员根据该标记找到用户主动联系的电话进行回拨，从而及时与用户进行联系。

示例性的，为配送订单添加预设标记，具体可包括：在配送订单的联系入口、和/或联系列表(如步骤201的解释中说明的一级列表)、用户的联系方式列表(如步骤201的解释中说明的二级列表)中增加预设标记，联系列表中包含配送订单涉及到的各个用户的联系功能按钮。

例如，如图3所示为在配送订单的联系入口处添加圆点，即在图片左下角的电话联系入口处添加圆点样式的标记，并且为了突出显示，可显示红色或者其他颜色的圆点，这样使得配送员能够了解到该订单的用户主动联系过自己，但自己并未及时接听。如图4所示为在联系列表(一级列表)中添加圆点标记，如该订单的收货人曾主动联系过配送员但未能及时接听，那么可在联系收货人的位置处显示该圆点标记，以便于配送员及时了解是该订单的收货人之前联系过自己但未能及时接听。如图5所示为在收货人电话列表中添加圆点标记，如收货人曾利用的电话1主动联系过配送员但未能及时接听，那么可在电话1的位置处显示该圆点标记，以便于配送员及时了解是该订单的收货人之前通过电话1联系过自己但未能及时接听，后续可通过该电话1号码进行回拨。

进一步可选的，为了加快双方的沟通效率，本实施例方法还可包括：响应于根据该预设标记触发的回拨指令，根据用户主动发起联系的联系方式进行回拨。例如，如图5所示，配送员可通过点击带有圆点标记的电话1的功能按钮，实现通过该电话1号码进行回拨，及时联系该订单的收货人。

为了说明上述各实施例的具体实施过程，给出如下应用示例，但不限于此：

在外卖配送的场景中，骑手(配送员)配送外卖到达顾客附近时，会拨打顾客联系电话，经常会遇到联系不上顾客的情况，于是他会选择遇到问题列表中“联系不上顾客”进行报备，以避免罚单损失。但是往往骑手只拨打顾客的其中部分电话未拨通，就开始报备联系不上顾客，而顾客的其他备用电话很可能可以拨通，因此会存在虚假报备联系不上顾客的异常情况。并且若顾客或商户主动联系了骑手，但骑手并未及时接听电话后，当骑手想要主动去联系商户或顾客时，他无法根据来电精准地拨打对方号码，同样增加联系不上商户或顾客的几率。

为了解决上述问题，基于本实施例方法，在订单列表页或订单详情页，点击联系按钮，出现联系列表浮窗，一级列表中包含联系商户、联系顾客(提供号码给骑手，骑手主动拨打用户，同时只能拨打一个用户)、智能呼叫顾客、在线对话、短息联系顾客、联系楼宇配送站长，智能呼叫顾客(系统拨打用户，可以同时拨打多个用户)和联系楼宇配送站长则会根据当前订单信息状态进行匹配显示。如智能外呼顾客是基于运单类型决定的；楼宇配送是基于该订单的送达地点是否有楼宇配送的服务决定的。

联系顾客或商户(包含更多电话)，点击更多电话按钮，出现二级备用电话列表(列表中包含备用电话、上报异常按钮)；当骑手打开一级或二级联系列表时，界面则开始判断监测顾客所有电话号码的拨打情况，若所有电话均未接听则支持报备“联系不上顾客”(即报备异常按钮变为可点击状态)，骑手报备后若点击详情页主操作栏按钮“遇到问题”，进入遇到问题列表页时，则选项“联系不上顾客”会显示报备状态信息；若顾客或商户主动联系了骑手，但骑手并未及时接听电话时，则在联系入口、以及该联系电话的按钮上显示红色圆点，以提示骑手该订单商户或顾客曾经来电过，骑手可根据此信息给商户或顾客去电。

通过上述本实施例方案，一级联系列表支持智能电话拨打和联系楼宇配送站长，联系场景更加细致全面；当骑手打开一级或二级联系列表时，界面则开始判断监听顾客所有电话号码的拨打情况，若所有电话均未接听则支持报备“联系不上顾客”，只有当骑手尝试过所有拨打所有电话，且所有电话均为接听时，才可报备，以此方式鼓励骑手尝试更多联系方式，避免骑手虚假报备联系不上顾客；在联系入口和列表中标记商户或骑手来电的红色圆点，骑手可根据此信息更加精准有效地联系商户或顾客，降低联系不上顾客的几率。

进一步的，作为图1和图2所示方法的具体实现，本实施例提供了一种报备信息的处理装置，如图6所示，该装置包括：获取模块31、监测模块32、确定模块33。

获取模块31，用于根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；

监测模块32，用于监测所述联系方式列表中的各个联系方式的联系状态信息；

确定模块33，用于依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。

在具体的应用场景中，确定模块33，具体用于依据所述各个联系方式的联系状态信息，并结合本地终端位置与所述配送订单的收货地址之间的距离、和/或可用报备次数，综合确定是否允许操作发送所述报备信息。

在具体的应用场景中，确定模块33，具体还用于若所述联系方式列表中的联系方式均为联系后未成功的状态、且所述距离小于或等于预设距离阈值、且所述可用报备次数大于0，则允许操作发送所述报备信息；若所述联系方式列表中存在至少一联系方式为未联系的状态、和/或所述距离大于预设距离阈值、和/或所述可用报备次数等于0，则不允许操作发送所述报备信息。

在具体的应用场景中，可选的，若按照目标联系方式联系后未接通、或接通后未接收到所述用户的联系信息，则确定所述目标联系方式为联系后未成功的状态。

在具体的应用场景中，确定模块33，具体还用于将所述报备信息的报备异常按钮，由不可点击状态变更为可点击状态；或，允许显示所述报备信息的报备异常按钮；或，响应于所述报备信息的发送指令，触发发送所述报备信息。

在具体的应用场景中，本装置还包括：第一显示模块；

显示模块，用于若存在未及时接通所述用户主动联系的信息，则为所述配送订单添加预设标记并进行突出显示。

在具体的应用场景中，第一显示模块，具体用于在所述配送订单的联系入口、和/或联系列表、和/或所述联系方式列表中增加预设标记，所述联系列表中包含所述配送订单涉及到的各个用户的联系功能按钮。

在具体的应用场景中，本装置还包括：处理模块；

处理模块，用于响应于根据所述预设标记触发的回拨指令，根据所述用户主动发起联系的联系方式进行回拨。

在具体的应用场景中，本装置还包括：第二显示模块；

第二显示模块，用于在允许操作发送所述报备信息之后，若成功发送所述报备信息，则根据所述报备信息，显示所述配送订单的报备状态信息。

在具体的应用场景中，可选的，所述用户的主要联系方式和备用联系方式为手机虚拟号码。

需要说明的是，本实施例提供的一种报备信息的处理装置所涉及各功能单元的其它相应描述，可以参考图1和图2中的对应描述，在此不再赘述。

基于上述如图1和图2所示方法，相应的，本实施例还提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述如图1和图2所示的报备信息的处理方法。

基于这样的理解，本申请的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施场景的方法。

基于上述如图1和图2所示的方法，以及图6所示的虚拟装置实施例，为了实现上述目的，本申请实施例还提供了一种电子设备，具体可以为个人计算机、智能手机、平板电脑、智能手表、智能手环、或其他网络设备等，该设备包括存储介质和处理器；存储介质，用于存储计算机程序；处理器，用于执行计算机程序以实现上述如图1和图2所示的报备信息的处理方法。

可选的，上述实体设备还可以包括用户接口、网络接口、摄像头、射频(RadioFrequency，RF)电路，传感器、音频电路、WI-FI模块等等。用户接口可以包括显示屏(Display)、输入单元比如键盘(Keyboard)等，可选用户接口还可以包括USB接口、读卡器接口等。网络接口可选的可以包括标准的有线接口、无线接口(如WI-FI接口)等。

本领域技术人员可以理解，本实施例提供的上述实体设备结构并不构成对该实体设备的限定，可以包括更多或更少的部件，或者组合某些部件，或者不同的部件布置。

存储介质中还可以包括操作系统、网络通信模块。操作系统是管理上述实体设备硬件和软件资源的程序，支持信息处理程序以及其它软件和/或程序的运行。网络通信模块用于实现存储介质内部各组件之间的通信，以及与信息处理实体设备中其它硬件和软件之间通信。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本申请可以借助软件加必要的通用硬件平台的方式来实现，也可以通过硬件实现。通过应用本实施例的技术方案，与目前现有技术相比，本实施例方案针对配送订单，可依据包括用户主要联系方式和备用联系方式在内的所有联系方式进行联系状态的监测，进而确定是否允许操作发送联系不上用户的报备信息。在配送员未拨打用户全部电话而想要报备联系不上用户时，不允许配送员操作发送该报备信息。进而可避免配送员虚假报备联系不上用户的异常情况发生，保证了报备信息的真实性。

本领域技术人员可以理解附图只是一个优选实施场景的示意图，附图中的模块或流程并不一定是实施本申请所必须的。本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中，也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块，也可以进一步拆分成多个子模块。

上述本申请序号仅仅为了描述，不代表实施场景的优劣。以上公开的仅为本申请的几个具体实施场景，但是，本申请并非局限于此，任何本领域的技术人员能思之的变化都应落入本申请的保护范围。

Claims (10)

1.一种报备信息的处理方法，其特征在于，包括：

根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；

监测所述联系方式列表中的各个联系方式的联系状态信息；

依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。

2.根据权利要求1所述的方法，其特征在于，所述依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息，具体包括：

依据所述各个联系方式的联系状态信息，并结合本地终端位置与所述配送订单的收货地址之间的距离、和/或可用报备次数，综合确定是否允许操作发送所述报备信息。

3.根据权利要求2所述的方法，其特征在于，依据所述各个联系方式的联系状态信息，以及本地终端位置与所述配送订单的收货地址之间的距离、和可用报备次数，综合确定是否允许操作发送所述报备信息，具体包括：

若所述联系方式列表中的联系方式均为联系后未成功的状态、且所述距离小于或等于预设距离阈值、且所述可用报备次数大于0，则允许操作发送所述报备信息；

若所述联系方式列表中存在至少一联系方式为未联系的状态、和/或所述距离大于预设距离阈值、和/或所述可用报备次数等于0，则不允许操作发送所述报备信息。

4.根据权利要求3所述的方法，其特征在于，若按照目标联系方式联系后未接通、或接通后未接收到所述用户反馈的联系信息，则确定所述目标联系方式为联系后未成功的状态。

5.根据权利要求3所述的方法，其特征在于，所述允许操作发送所述报备信息，具体包括：

将所述报备信息的报备异常按钮，由不可点击状态变更为可点击状态；或，

允许显示所述报备信息的报备异常按钮；或，

响应于所述报备信息的发送指令，触发发送所述报备信息。

6.根据权利要求1所述的方法，其特征在于，所述方法还包括：

若存在未及时接通所述用户主动联系的信息，则为所述配送订单添加预设标记并进行突出显示。

7.根据权利要求6所述的方法，其特征在于，所述为所述配送订单添加预设标记，具体包括：

在所述配送订单的联系入口、和/或联系列表、和/或所述联系方式列表中增加预设标记，所述联系列表中包含所述配送订单涉及到的各个用户的联系功能按钮。

8.一种报备信息的处理装置，其特征在于，包括：

获取模块，用于根据用户的配送订单，获取所述用户的联系方式列表，所述联系方式列表中包含所述用户的主要联系方式和备用联系方式；

监测模块，用于监测所述联系方式列表中的各个联系方式的联系状态信息；

确定模块，用于依据所述各个联系方式的联系状态信息，确定是否允许操作发送联系不上所述用户的报备信息。

9.一种存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至7中任一项所述的方法。

10.一种电子设备，包括存储介质、处理器及存储在存储介质上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至7中任一项所述的方法。

Images