业务通知方法和装置与流程

本公开涉及网络技术，尤其涉及一种业务通知方法和装置。

背景技术：

随着网络技术的发展，用户也逐渐在网上进行各种业务。比如，用户可以在网上购物，在网上订外卖等。伴随着用户网上业务的增多，也出现了用于为用户传送各种业务产品的配送员，比如，送快递的快递员，送外卖的外卖员等。当配送员将用户的业务产品(比如，餐食或者快递)送到用户所在位置后，通常需要通知用户来取，可以将配送员通知用户的事件称为业务通知；而且大多数情况下配送员所配送的产品不止一个用户，可能同时配送多个用户的产品，配送员要逐个通知用户来取自己的产品，效率很低。

技术实现要素：

为克服相关技术中存在的问题，本公开提供一种业务通知方法和装置，以提高业务通知的效率。

根据本公开实施例的第一方面，提供一种业务通知方法，包括：

接收客户端发送的对应至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识；

根据所述业务标识，分别获取所述至少一个业务对应的用户的联系信息，并根据所述联系信息联系所述用户进行业务通知。

根据本公开实施例的第二方面，提供一种业务通知方法，包括：

接收对应至少一个业务的通知触发；

根据所述通知触发，向服务端发送对应所述至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识，以使得所述服务端根据业务标识联系所述至少一个业务的用户进行业务通知。

根据本公开实施例的第三方面，提供一种业务通知装置，包括：

请求接收模块，用于接收客户端发送的对应至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识；

通知执行模块，用于根据所述业务标识，分别获取所述至少一个业务对应的用户的联系信息，并根据所述联系信息联系所述用户进行业务通知。

根据本公开实施例的第四方面，提供一种业务通知装置，包括：

触发接收模块，用于接收对应至少一个业务的通知触发；

请求发送模块，用于根据所述通知触发，向服务端发送对应所述至少一个业务的通知请求，所述通知请求携带至少一个业务分别对应的业务标识，以使得所述服务端根据业务标识联系所述至少一个业务的用户进行业务通知。

本公开的实施例提供的技术方案可以包括以下有益效果：通过在接收到对于至少一个业务的通知请求时，并行联系该至少一个业务的用户进行业务通知，相对于逐个通知的方式，显著提高了业务通知的效率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。

图1是根据一示例性实施例示出的业务通知应用的系统架构；

图2是根据一示例性实施例示出的一种业务通知方法的流程图；

图3是根据一示例性实施例示出的另一种业务通知方法的流程图；

图4是根据一示例性实施例示出的又一种业务通知方法的流程图；

图5是根据一示例性实施例示出的又一种业务通知方法的流程图；

图6是根据一示例性实施例示出的一种业务通知装置的结构示意图；

图7是根据一示例性实施例示出的另一种业务通知装置的结构示意图；

图8是根据一示例性实施例示出的又一种业务通知装置的结构示意图；

图9是根据一示例性实施例示出的又一种业务通知装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。

本公开提供的业务通知方法，可以由图1所示的包括客户端11和服务器12的系统来执行，如图1所示，客户端11可以显示多个业务，比如示例的业务1、业务2、业务3，该客户端11可以位于配送员的手持终端上。并且，本公开的业务通知，即配送员已经将各业务对应的业务产品送到用户处，需要通过客户端11通知各个业务对应的用户业务已经完成；比如，对于外卖业务来说，可以是配送员要提示各个订单业务的用户餐已经送到。

为了实现上述的业务通知，客户端11可以执行图2示例的业务通知方法的流程，服务端12可以执行图3示例的业务通知方法的流程。

201、接收对应至少一个业务的通知触发。

202、根据所述通知触发，向服务端发送对应所述至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识，以使得所述服务端根据业务标识联系所述至少一个业务的用户进行业务通知。

301、接收客户端发送的对应至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识。

302、根据所述业务标识，分别获取所述至少一个业务对应的用户的联系信息，并根据所述联系信息联系用户进行业务通知。

结合图2和图3来描述，在步骤201中，客户端11可以接收到对应至少一个业务的通知触发。例如，配送员可以通过手动触发的方式，点击选择某个业务，或者，在客户端11的显示界面上，每个业务都对应显示一个用于触发通知请求发送的按钮，那么配送员可以手动选择业务对应的触发按钮，触发客户端11向服务端12发送对应该业务的通知请求。本步骤中的客户端接收到通知触发，指的可以为配送员点击了触发按钮，并且，配送员可以点击至少一个业务的按钮，例如图1中的三个业务都要进行业务通知。

可选的，配送员在进行通知触发时，可以逐个触发各个业务，或者也可以一次性触发多个业务。示例性的，比如，在客户端11的显示界面上，可以是每个业务分别对应显示一个用于触发通知请求发送的按钮，配送员可以逐个业务点击按钮触发，比如，可以点击触发其中一个业务，或者逐个点击触发多个业务；或者，还可以是在界面上显示一个“一键触发”的类似功能按钮，配送员点击该按钮可以触发多个业务同时进行通知请求。

在步骤202中，客户端11向服务端12发送通知请求，该通知请求用于指示服务端12向这些业务对应的用户进行业务通知。其中，请求中可以携带各个业务分别对应的业务标识，以外卖业务为例，那么配送员手持终端上的客户端11显示的多个业务，可以是各个外卖订单，那么通知请求中可以携带用于标识订单的信息，比如订单号。

可选的，对于多个业务来讲，如果客户端11是各个业务分别发送对应的通知请求，则各个请求中携带对应业务的业务标识即可；如果客户端11是发送一个请求用于请求通知多个业务，则请求中可以携带多个业务的业务标识。

服务端12可以在步骤301中接收到客户端11发送的通知请求，该通知请求对应于至少一个业务，当有多个业务对应的通知请求时，这多个业务可以是同一个客户端发送的多个业务，或者也可以是多个客户端发送的多个业务。并且，在步骤302中，为了对各业务对应的用户进行业务通知，服务端12可以根据通知请求中携带的业务标识，获取业务对应的用户联系信息，并根据联系信息并行联系多个用户进行业务通知。

例如，仍以外卖业务为例，客户端11中可以显示多个外卖订单，配送员在送餐到达后，可以点击需要通知的订单对应的触发按钮，则客户端11可以向服务端12发送这些订单的通知请求，请求中携带的业务标识可以是订单号。服务端12可以根据订单号得到该订单对应的用户的联系方式，这里以联系方式是手机号为例。服务端12可以并行拨打多个订单的用户的手机号进行通知，并且通知的方式可以是语音提示“您订购的外卖现已送达，请下楼取餐”。具体实施时，可以是服务端的云呼叫中心进行多个用户的并行呼叫。

本实施例的业务通知方式，可以并行发起对多个业务的通知，可以并行联系多个业务对应的用户，相对于传统方式中配送员要逐个用户的联系，将显著提高业务通知的效率。

图4示例了本公开的业务通知方法的另一个流程，在本例子中，为了给用户更清晰准确的提示，也使得用户更好的了解当前通知的是哪个业务，服务端在对用户进行提示时可以将提示信息进行细化。如图4所示，该流程可以是服务端执行，可以包括：

在步骤401中，服务端接收到客户端发送的通知请求，携带业务标识。

例如，以外卖业务为例，在本步骤中，服务端12可以接收到客户端11发送的通知请求，请求中可以携带多个外卖订单的订单号。

在步骤402中，服务端根据业务标识，分别获取多个业务对应的用户的联系信息、以及业务提供方信息。

例如，服务端可以根据订单号，分别获取要进行业务通知的多个订单的用户的手机号码，并且，本例子中，服务端还可以获取业务提供方信息即提供外卖服务的店铺信息，比如店铺名称“某某包子铺”。这些手机号码和店铺信息可以在用户下达外卖订单时服务端就获取到。

在步骤403中，服务端将业务提供方信息由文本格式转换为语音格式。

例如，本步骤中服务端可以进行文本到语音的格式转换。比如，外卖服务的店铺信息在服务端可以是以文本格式存储，本例子中，要将其转换成语音。因为后续在提示用户时需要将用户所定外卖的店铺信息也提示给用户， 比如“您订购的***店铺的外卖现已送达，请下楼取餐”，其中，“***店铺”即可以是在本步骤中进行格式转换得到，而上述提示信息中除店铺之外的其他信息可以是预先设置好的语音，加上转换得到的店铺语音即可对用户进行提示。

在步骤404中，服务端根据联系信息联系多个用户进行业务通知，并且还同时向用户语音提示对应业务的业务提供方信息。

例如，对于某个订单，服务端可以向下订单的用户拨打其手机号，并且在用户接听电话后，对用户进行如下语音提示“您订购的***店铺的外卖现已送达，请下楼取餐”，既提示了用户餐已送达，并且也提示了是哪个店铺。

本实施例的业务通知方法，通过在对用户进行业务通知时，对通知信息进行了细化，使得用户能够得到更详细准确的通知信息；并且，本例子采用了文本转换语音的方式，能够适应不同业务的不同信息，应用方便。

图5示例了本公开的业务通知方法的又一个流程，在本例子中，主要是在服务端对用户进行业务通知之后，如何向客户端反馈业务通知结果，使得配送员通过客户端及时了解各个用户是否接收到业务通知。如图5所示，该实施例可以包括如下流程，其中，已经描述过的步骤不再详述：

在步骤501中，客户端向服务端发送通知请求，携带业务标识。

在步骤502中，服务端根据业务标识获取用户联系信息和业务提供方信息，并将业务提供方信息进行文本至语音的转换。

在步骤503中，服务端根据联系信息和业务提供方信息对用户进行业务通知，比如，对用户进行语音提示，提示用户业务已经执行完成。

在步骤504中，服务端判断用户是否已经获取到业务通知。

例如，服务端可以向用户拨打手机，同样也能够检测到用户是否接听了该手机；当用户接听了该手机时，向用户播放语音业务通知。因此，服务端可以检测到用户是否已经获取到该业务通知。

示例性的，可以假设用户接听了服务端拨打用户手机的电话，并且接听时长达到10秒钟，则可以确定用户已经获取到业务通知，比如，用户已经听 了语音提示，知道自己的外卖餐已经送到了。又例如，还可以假设用户根本就未接听电话，或者，即使接听了电话，但是接听时长仅仅为2秒钟，则可以认为用户未获取到业务通知。

本步骤中，若判断结果为用户获取到对应该业务的业务通知，则可以执行步骤505和步骤506；否则，若判断结果为用户未获取到对应该业务的业务通知，则可以执行步骤507和步骤508。

在步骤505中，服务端向客户端反馈通知成功的第一状态信息。

在步骤506中，客户端根据第一状态信息，获取用户已经通知成功，则关闭对应该业务的通知请求功能。

比如，客户端可以将对应该业务的通知请求的触发按钮灰掉，使得配送员不能再选择触发，从而防止配送员重复拨打对用户造成骚扰，而且按钮灰掉也可以使得配送员知道该业务已经通知成功。

在步骤507中，服务端向客户端反馈通知失败的第二状态信息。

在步骤506中，客户端根据第二状态信息，进行对业务再次通知请求的提示。比如，提示给配送员，某一个订单的用户未接听电话，是否重新拨打。向配送员提示的方式可以有多种，比如，可以通过改变业务对应的触发按钮的颜色，用红色表示未接听；或者，也可以直接在按钮上显示未接听的文字提示，等方式，这样配送员就可以及时获知某个订单需要重新通知。

本实施例的业务通知方法，通过由服务端将业务通知的结果通知给客户端，并且客户端据此进行不同的提示，使得配送员能够及时的了解到各个业务的业务通知是否被用户接收，并在未接收时尽快的再次通知用户。

上述的方法是以外卖例子为例来说明，但是可以理解的是，不局限于该应用场景，其他场景也可以应用该方法，比如快递应用等。

为了执行本公开的业务通知方法，本公开还提供了业务通知装置，如下对该装置的结构进行简单说明，具体原理可以结合参见方法实施例。如图6所示，该业务通知装置可以应用于服务端，可以包括：请求接收模块61和通知执行模块62，其中：

请求接收模块61，用于接收客户端发送的对应至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识；

通知执行模块62，用于根据所述业务标识，分别获取所述至少一个业务对应的用户的联系信息，并根据所述联系信息联系用户进行业务通知。

进一步的，可以参见图7所示，该服务端的装置还可以包括：状态反馈模块63，用于执行如下至少一种功能：

对于其中一个业务，若检测到用户获取到对应该业务的业务通知，则向所述客户端反馈通知成功的第一状态信息，以使得所述客户端关闭对应所述业务的通知请求功能；

或者，对于其中一个业务，若检测到用户未获取到对应该业务的业务通知，则向所述客户端反馈通知失败的第二状态信息，以使得所述客户端进行对所述业务再次通知请求的提示。

进一步的，该装置还可以包括：信息转换模块64。

信息转换模块64，用于根据所述业务标识，分别获取所述至少一个业务对应的业务提供方信息，并将所述业务提供方信息由文本格式转换为语音格式；

所述通知执行模块62，还用于在根据所述联系信息联系用户进行业务通知时，还向所述用户语音提示对应业务的业务提供方信息。

图8示例了一种应用于客户端的业务通知装置，如图8所示，该装置可以包括：触发接收模块81和请求发送模块82。

触发接收模块81，用于接收对应至少一个业务的通知触发；

请求发送模块82，用于根据所述通知触发，向服务端发送对应所述至少一个业务的通知请求，所述通知请求携带所述至少一个业务分别对应的业务标识，以使得所述服务端根据业务标识联系所述至少一个业务的用户进行业务通知。

进一步的，如图9所示，该装置可以包括：

第一状态接收模块83，用于接收所述服务端发送的对应其中一个业务的 第一状态信息，所述第一状态信息用于表示所述服务端向所述业务对应的用户业务通知成功；

第一功能管理模块84，用于根据所述第一状态信息，关闭对应所述业务的通知请求功能。

进一步的，该装置还可以包括：第二状态接收模块85，用于接收所述服务端发送的对应其中一个业务第二状态信息，所述第二状态信息用于表示所述服务端向所述业务对应的用户业务通知失败；

第二功能管理模块86，用于根据所述第二状态信息，执行对所述业务再次通知请求的提示。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本申请旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求指出。

应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求来限制。