CN110232488A

CN110232488A - 工单处理方法、系统及设备

Info

Publication number: CN110232488A
Application number: CN201810183462.XA
Authority: CN
Inventors: 张晓光
Original assignee: Alibaba Group Holding Ltd
Current assignee: Alibaba Group Holding Ltd
Priority date: 2018-03-06
Filing date: 2018-03-06
Publication date: 2019-09-13
Anticipated expiration: 2038-03-06
Also published as: CN110232488B

Abstract

本申请实施例提供一种工单处理方法、系统及设备。其中，方法包括如下的步骤：获取服务工单的第一服务属性；根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级；将所述服务工单按照所述优先级列入所述第一服务属性对应的工单队列中等待派发。本申请实施例提供的技术方案，基于服务工单及已派发未处理完工单的服务属性确定服务工单的优先级，在保证优先处理优先级高的工单的同时，还有助于实现服务工单与已派发未处理完工单的合并处理，进而提高工单的处理效率，提升服务组织效能。

Description

工单处理方法、系统及设备

技术领域

本申请涉及计算机技术领域，尤其涉及一种工单处理方法、系统及设备。

背景技术

现有酒店行业的任务派发大多是基于人工、短信、电话完成的。人工的任务派发常见于小型的酒店，适用于客房数量少，服务人员少，酒店面积也较小的场景。稍具规模的酒店，还采用这种人工派发任务的方式，会带来诸多问题，进而影响酒店的服务效率，客户消费体验低。

发明内容

鉴于上述问题，提出了本申请以便解决上述问题或至少部分地解决上述问题的工单处理方法、系统及设备。

于是，在本申请的一个实施例中，提供了一种工单处理方法。该方法包括：

获取服务工单的第一服务属性；

根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级；

将所述服务工单按照所述优先级列入所述第一服务属性对应的工单队列中等待派发。

在本申请的另一实施例中，提供了一种工单处理方法。该方法包括：

根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；

待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；

通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应。

在本申请的又一实施例中，提供了一种工单处理方法。该方法包括：

接收服务端在轮至服务工单的派发次序时根据所述服务工单的第一服务属性选择出的通知对象后发送的确收所述服务工单的通知；

输出所述通知；

其中，所述服务工单的派发次序是根据所述第一服务属性及已派发未处理完工单的第二服务属性确定的。

在本申请的一个实施例中，提供了一种工单处理系统。该系统包括：

服务端，用于根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应；

所述目标服务提供方对应的第一客户端，用于接收所述服务端发送的确收所述服务工单的通知，输出所述通知。

在本申请的一个实施例中，提供了一种工单处理方法。该方法包括：

通知服务工单派发对象对应的客户端做出确收所述服务工单的响应；

所述服务工单未确收时，从组织等级架构中查找级别高于所述派发对象的通知对象；

通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知。

根据与线下酒店服务相关的服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；

待轮至所述服务工单的派发次序时，根据所述第一服务属性，从多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员；

通知所述目标酒店服务人员对应的客户端作出确收所述服务工单的响应。

在本申请的一实施例中，提供了一种电子设备。该电子设备包括：第一存储器和第一处理器，其中，

所述第一存储器，用于存储程序；

所述第一处理器，与所述第一存储器耦合，用于执行所述第一存储器中存储的所述程序，以用于：

获取服务工单的第一服务属性；

在本申请的另一实施例中，提供了一种服务端设备。该服务端设备包括：第二存储器和第二处理器，其中，

所述第二存储器，用于存储程序；

所述第二处理器，与所述第二存储器耦合，用于执行所述第二存储器中存储的所述程序，以用于：

在本申请一实施例中，提供了一种客户端设备。该客户端设备包括：第三存储器和第三处理器，其中，

所述第三存储器，用于存储程序；

所述第三处理器，与所述第三存储器耦合，用于执行所述第三存储器中存储的所述程序，以用于：

输出所述通知；

在本申请一实施例中，提供了一种服务端设备。该服务端设备包括：第四存储器和第四处理器，其中，

所述第四存储器，用于存储程序；

所述第四处理器，与所述第四存储器耦合，用于执行所述第四存储器中存储的所述程序，以用于：

在本申请一实施例中，提供了一种服务端设备。该服务端设备包括：第五存储器和第五处理器，其中，

所述第五存储器，用于存储程序；

所述第五处理器，与所述第五存储器耦合，用于执行所述第五存储器中存储的所述程序，以用于：

本申请实施例提供了一种技术方案，基于服务工单及已派发未处理完工单的服务属性确定服务工单的优先级，在保证优先处理优先级高的工单的同时，还有助于实现服务工单与已派发未处理完工单的合并处理，进而提高工单的处理效率，提升服务组织效能。另外，本申请实施例还提供了一种技术方案，通知服务提供方确收服务工单后，若服务工单未确收则通知组织等级架构中级别高的通知对象来确收服务工单，以解决现有技术中服务提供方可能由于正在服务或环境干扰无法确收服务工单的情况下延误服务工单的确收进而影响服务工单的处理及时性等诸多问题，提高了服务工单的处理效率，服务效能提高，有助于提升用户对服务提供方的服务满意度。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请一实施例提供的工单处理方法的流程示意图；

图2为本申请一实施例提供的技术方案实现原理示意图；

图3为本申请一实施例提供的工单处理系统的结构示意图；

图4为本申请另一实施例提供的工单处理方法的流程示意图；

图5为本申请又一实施例提供的工单处理方法的流程示意图；

图6为本申请又一实施例提供的工单处理方法的流程示意图；

图7为本申请又一实施例提供的工单处理方法的流程示意图；

图8为本申请又一实施例提供的工单处理方法的流程示意图；

图9为本申请一实施例提供的工单处理装置的结构框图；

图10为本申请另一实施例提供的工单处理装置的结构框图；

图11为本申请又一实施例提供的工单处理装置的结构框图；

图12为本申请又一实施例提供的工单处理装置的结构框图；

图13为本申请又一实施例提供的工单处理装置的结构框图；

图14为本申请一实施例提供的电子设备的结构框图；

图15为本申请一实施例提供的服务端设备的结构框图；

图16为本申请一实施例提供的客户端设备的结构框图；

图17为本申请另一实施例提供的服务端设备的结构框图；

图18为本申请又一实施例提供的服务端设备的结构框图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。

在本申请的说明书、权利要求书及上述附图中描述的一些流程中，包含了按照特定顺序出现的多个操作，这些操作可以不按照其在本文中出现的顺序来处理或并行处理。操作的序号如101、102等，仅仅是用于区分各个不同的操作，序号本身不代表任何的处理顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序处理或并行处理。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

现有技术中所采用的人工派发任务的方式，首先需要由人编辑短信或者打电话，这就需要人工成本；再者，负责派发的人员不知道具体的服务人员在那里，是否有空，这些都会造成派发的效率低下；还有，接收任务的服务人员可能由于正在服务或者环境干扰接收不到短信或者电话，这些会造成接收的效率低下。本申请实施例提供的技术方案就是为了解决以上人工成本高、效率低的问题。

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

图1示出了本申请一实施例提供的工单处理方法的流程示意图。本实施例提供的所述方法适用于服务端，其中，所述服务端可以是常用服务器、云端、虚拟服务器等，本申请实施例对此不作具体限定。如图1所示，该方法包括：

101、获取服务工单的第一服务属性。

102、根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级。

103、将所述服务工单按照所述优先级列入所述第一服务属性对应的工单队列等待派发。

上述步骤101中，服务工单的第一服务属性可包括：创建时间、服务类别、服务目的地、服务项目、服务请求方信息、紧急度信息等中的一种或多种。本申请实施例提供的技术方案可应用于多种应用场景中，例如，酒店服务场景。不同应用场景中，服务工单的服务属性包含的内容会有所不同。在酒店服务场景中，服务类别可包括：酒店外部服务、大堂服务、客房服务、餐厅服务、健身房服务、洗衣房服务等。服务目的地如房间号、酒店大堂、餐厅等等。每一服务类别下又对应有多种不同的服务项目。例如，客房服务对应的服务项目可包括：房间电器使用问题、住客需要一些物品(如水)、房间网络问题等；大堂服务对应的服务项目可包括：行李搬运服务、行李寄存服务等；餐厅服务对应的服务项目可包括：定位服务、因用餐后菜品长时间未上的催餐服务等等。其他服务类别(如酒店外部服务、健身房服务、洗衣房服务等等)对应的服务项目均可参见实际酒店中所能提供的具体服务，此处不在一一列举。服务请求方信息可包含：房间号、用户标识(例如用户登录酒店应用APP的登录账号)、用户所属类型(如VIP用户、普通用户等)等。紧急度信息可以是人工干预设置的，也可空置，本申请实施例对此不作具体限定。

属性信息在创建服务工单时即生成并携带在服务工单中。例如，在接收到用户上报的服务请求后，从服务请求中获取服务类型、服务项目、用户信息等信息；将获取到的信息填写至工单模板中，并基于服务类型及服务请求的时间对工单进行编号。其中，在具体实施时，服务工单编号中的部分数字可表征服务工单的服务类型，另一部分数字可表征服务工单的创建时间、再一部分可表征服务工单的流水号等等。当然，若服务请求方(可以是酒店服务人员也可以是酒店客户等)在提交服务请求时，同时提交了紧急度信息，则紧急度信息也可标记在服务工单的编号中，用服务工单编号中的一个位置处的数字表征紧急度信息。例如，服务工单号中的第一位的数字代表紧急度，1代表高紧急度，2代表普通紧急度、3代表低紧急度。或者，所述属性信息不携带在工单中，但与工单存在关联关系。当工单被调取时，该属性信息也可同时被获取到。

上述102中，已派发未处理完工单可简单理解为：已派发到服务提供方，但服务提供方还未启动执行的服务工单。这里选择已派发未处理完工单的服务属性来确定服务工单的优先级，是为了将一些服务工单派发至正在处理或还未处理该已派发未处理完工单的服务提供方，以便于同一服务提供方能合并处理这两个服务工单，以提高工单处理效率。例如，酒店中提供房间打扫的服务人员(即服务提供方)正在打扫101房间，此时服务端欲派发的服务工单为：为102房间的客户送两瓶水。因为，为被打扫房间配水是打扫房间的一项内容，因此将该服务工单派发至正在打扫101房间的服务人员，该服务人员在打扫间隙为102房间的客户送水就是顺带的事儿。显然，这样能有效的提高工单的处理效率。

在一种可实现的技术方案中，这些已派发未处理完工单可存被存储在已派发工单库中，已处理完成工单将被从该已派发工单库中剔除。由此，服务端在派发一新服务工单时，可从已派发工单库中选择已派发未处理完工单。但这里需要补充的是：服务端需及时将已处理完成的工单从已派发工单库中剔除。即本申请实施例提供的技术方案就需要服务提供方在接收到服务提供方通过客户端针对已完成服务工单反馈已完成信息后，将服务提供方已完成信息中携带的服务工单标识对应的服务工单从已派发工单库中剔除。例如，服务提供方(例如酒店服务人员)在处理完一个服务工单后，通过触控用户界面上该服务工单对应的“已完成”控键上传已完成信息。即，服务提供方侧客户端响应于用户针对一服务工单触发的已完成事件，将该服务工单的标识携带在已完成信息中发送至服务端。

在一种可实现的技术方案中，本实施例中步骤102、根据服务工单的服务属性及已派发未处理完工单的服务属性，确定所述服务工单的优先级可采用如下方式实现：

1021、根据所述第一服务属性，确定第一优先级。

1022、基于所述第一服务属性与所述已派发未处理完工单的第二服务属性，评估所述服务工单与所述已派发未处理完工单合并处理的概率。

1023、根据所述概率确定第二优先级。

1024、根据所述第一优先级及所述第二优先级，计算所述服务工单的优先级。

上述1021可具体采用如下方式实现：获取所述服务属性包含的各信息对应的权重；基于各信息对应的权重计算所述第一优先级。服务属性中包含的各信息对应的权重获取方式可不同。例如，服务属性中包含的服务类别、服务项目、服务请求方信息、紧急度信息等，可直接通过如下表1所示示例的对应关系获取到。这里需要说明的是表1是以酒店服务为例来说明的，对于不同的应用场景表1中所示的各信息可作适应性的变化。

表1属性信息与权重的对应关系

而服务属性中包含的创建时间是无法通过表1的方式直接获取到对应权重的。对于创建时间：由于时间是不断变化的，工单队列中的服务工单也是在不断变化的，具体实现时是无法直接通过创建时间单一时间点来为其配置权重的。因此，在实际操作时可通过对工单队列中所有服务工单进行时间排序，时间越靠后的创建时间需配置的权重越高。在一种可实现的方案中，可根据采用服务工单在工单队列中的创建时间排序的序号，为服务工单的创建时间配置对应的权重。

获取到服务属性中各信息对应的权重后，可采用如下计算方式得到加权和，将加权和结果作为所述工单的优先级：

计算方式一：优先级＝a+b+c+d+e

计算方式二：优先级＝服务类别＊a+服务项目＊b+紧急度信息＊c+服务请求方信息＊d+创建时间＊e

其中，上述a为服务类别对应的权重，b为服务项目对应的权重，c为紧急度信息对应的权重，d为服务请求方信息对应的权重，e为创建时间对应的权重。上述计算方式二中，服务类别、服务项目、紧急度信息、服务请求方信息、创建时间、为各自对应的设定基数。各属性信息对应的设定基数可为一个预先设定的值。当然，除上述两种方式外，优先权计算还可采用其他方式实现，本申请实施例对此不作具体限定。

进一步的，上述1022可具体实现如下：

首先、根据所述第一服务属性中包含的第一服务目的地与所述第二服务属性中包含的第二服务目的地，计算同一服务提供方合并处理所述服务工单与所述已派发未处理完工单时从所述第一服务目的地至所述第二服务目的地所需的路程用时；以及根据所述第一服务属性中包含的第一服务项目与所述第二服务属性中包含的第二服务项目，确定可合并性；

然后，根据所述路程用时及所述可合并性，计算所述服务工单与所述已派发未处理完工单合并处理的概率。

其中，本申请提供的技术方案将服务工单与所述已派发未处理完工单合并处理的前提是为了提高处理效率。若两个服务工单的服务目的地距离较远，则不如将两个服务工单分发至不同的服务提供方来处理，能有效的提高工单处理的及时性，用户体验度更高。另外，还需考虑两个服务工单是否能合并，即需结合具体的服务项目判断是不是具有可合并性。例如，房间清洁需要较长时间，如果有两个相邻的房间同时提出清洁服务，那么则不能合并。如果合并，服务人员还是依次打扫，对于后一个房间的清理时间还是取决于两个房间的清理时间，此时在服务员充足的情况下就不能合并。

这里还需要说明的是：这里得到的概率只是系统的一种推荐，不强制要求服务提供方必须合并处理，这个最终还是由服务提供方(即服务人员)自己决定。如果，服务端通过计算两个服务工单合并处理的概率较高，但在服务人员的实际处理时，很少有服务人员将两个服务工单合并处理，那么服务端基于该概率确定的该服务工单的优先级就不合乎实际场景。因此，服务端可通过历史上服务人员合并处理这类服务工单的概率，来对上述计算出的概率进行修正。即本申请实施例提供的技术方案，还包括：

获取历史上同一服务提供方合并处理服务工单的概率；基于所述概率，对所述服务工单与所述已派发未处理完工单合并处理的概率进行修正。

在一种可实现的技术方案中，上述历史上同一服务提供方合并处理服务工单的概率可采用如下方法实现：

如果历史数据包含服务的时间、服务目标的位置、及服务的项目，将这些信息作为服务端侧一概率计算规则的输入。该概率计算规则中需要配置一些参数，例如：标准服务合并的时间(Ts)、标准服务目标合并的距离限制(Ss)、标准服务项目的可合并性(Ps)(值域：[0,1])。该概率计算规则的计算过程大致如下：

1)逐条取历史数据中的各历史服务工单与所有历史服务工单进行合并匹配。

假设当前历史服务工单为R1，所有历史服务工单分别表征为R1...Rn，计算R1与Ri(i的值域为[2,N])的服务时间差值T1i；计算R1与Ri的服务距离差值S1i；计算R1与Ri的可合并性P1i；如果T1i<Ts，且S1i<Ss,且P1i>Ps，则满足合并条件，依次将所有满足条件的历史服务工单对进行计数M。

2)去除M中重复出现的历史服务工单对的数量。

例如：R1&Rx对和Rx&R1对视为相同，去除相同历史服务工单对后，得到的历史服务工单对数量为m。

3)该历史数据跨度的时间段内合并的概率则为：m/n。

上述1023中，可预先配置概率与第二优先权的对应关系。在具体实施时，通过查询该概率与第二优先权的对应关系，即可确定出所述服务工单的第二优先级。

上述1024中，假设所述服务工单的优先级为P，第一优先级为Ps，第二优先级为Pr。相应的，服务工单的优先级可采用如下公式计算得到：

P＝Ps+Pr

这里需要补充的是：上述实施例提供的技术方案中，服务工单派发至服务提供方后，服务提供方可自行判断哪两个服务工单合并处理；也可由系统提示服务提供方该服务工单可与哪个服务工单进行合并处理。即，服务端在向服务提供方派发服务工单时，还可向服务提供方发送合并提示，以提示服务提供方可将该新派发的服务工单与那一已派发未处理完工单合并。这种提示仅是一种建议，具体实施时最终是否合并处理可由服务人员自己决定。

由上述内容可知，服务工单的服务属性可包括：创建时间、服务类别、服务目的地、服务项目、服务请求方信息、紧急度信息等中的一种或多种。上述103中，第一服务属性对应的工单队列，可以是第一服务属性的服务类别对应的工单队列，也可是第一服务属性的服务项目对应的工单队列，等等。在具体实施时，一种或多种服务类别对应有一个工单队列，或者，某一种服务项目或多种服务项目对应有一个工单队列。将工单队列划分为多个，是因为不同服务类别或服务项目，其派发的对象是不冲突的；所以多个工单队列可并行的同时进行派发。若将所有服务工单均放置在同一工单队列中，势必会降低服务工单的派发效率。

本申请实施例提供的技术方案，基于服务工单及已派发未处理完工单的服务属性确定服务工单的优先级，在保证优先处理优先级高的工单的同时，还有助于实现服务工单与已派发未处理完工单的合并处理，进而提高工单的处理效率，提升服务组织效能。

工单队列中的服务工单是按照优先级排序的，优先级越高排序越靠前。服务工单在派发时，可将其派发给适合处理该服务工单的服务提供方，以提高工单处理效率。例如，具体实施时，可根据工单本身的属性(例如：服务类别、服务目的地)、服务人员实时位置、服务人员已经分配的工单综合决策进行派发。其中，为服务工单选择合适的服务提供方的依据可包括：服务工单的服务属性(如服务类别、服务目的地等)，服务提供方实时位置、服务已经分配的服务工单(简单来说即服务提供方已确收待处理的服务工单数量及工单处理量等)等等。即本申请实施例还可包括如下步骤：

104、待轮至派发所述服务工单时，根据所述服务工单的服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方。

105、将所述服务工单派发至所述目标服务提供方。

上述104中，可根据服务工单的服务属性中的服务目的地、服务类型和/或服务提供方的工作量情况，确定多个服务提供方中最合适处理服务工单的目的服务提供方。即本步骤104可具体包括：从所述多个服务提供方中，选择能提供所述服务类别服务、距离所述服务目的地最近和/或工作量最少等等的目标服务提供方。

其中，从多个服务提供方中选择距离所述服务目的地最近的目的服务提供方，可具体包括：

S1、接收各服务提供方对应客户端上传的位置信息。

S2、根据各服务提供方对应的客户端的位置信息及所述服务目的地，计算各服务提供方距离所述服务目的地的距离。

S3、根据所述距离最近的服务提供方作为所述目标服务提供方。

其中，上述多个服务提供方的位置信息可采用蓝牙定位方法、wifi定位方法或摄像头定位方法等确定，本申请实施例对此不作具体限定。蓝牙定位方法、wifi定位方法或摄像头定位方法的具体实现可参见现有技术中的相应的内容，此处不再赘述。例如，在酒店应用场景下，酒店内布设有多个蓝牙定位设备。客户端根据接收到的蓝牙信号的强弱以及发射蓝牙信号的蓝牙定位设备的设备标识计算所述客户端的位置信息。所述客户端向服务端上传所述位置信息时，可将与客户端设备标识绑定的用户信息一同上传，以便于服务端能基于用户信息区别各上传的位置信息。酒店服务人员每人都配有客户端设备，酒店服务人员通过登录客户端设备上的酒店APP进行用户信息的注册后，即可完成客户端设备标识与用户信息的绑定。

采用上述步骤从多个服务提供方中选出的目的服务提供方，很可能为两个或两个以上。此时，即可采用如下方法从两个或两个以上目的服务提供方中选取一个目的服务提供方。即当目标服务提供方为两个或两个以上时，上述步骤104、所述根据服务工单的服务属性，从多个服务提供方中选择能处理所述服务工单的目标服务提供方，还可包括：

获取两个或两个以上的所述目标服务提供方各自的状态属性；

根据所述状态属性，从两个或两个以上所述目标服务提供方中选出一个目标服务提供方。

其中，所述状态属性可包括已确收未完成工单的工作量及工单处理能力值；以及上述根据所述状态属性，从两个或两个以上所述目标服务提供方中选出一个目标服务提供方，可具体为：

根据两个或两个以上的所述目标服务提供方各自的已确收未完成工单的工作量及工单处理能力值，分别计算两个或两个以上的所述目标服务提供方再增加所述服务工单后处理所有未完成工单需花费的时间；

从两个或两个以上的所述目标服务提供方中，选出时间花费少的一个目标服务提供方。

这里需要说明的是：上述已确收未完成工单的工作量可基于历史上同一服务项目的服务工单的平均处理时间来确定。假设在酒店服务场景中，已确收未完成工单的服务项目为打扫房间，可提取前10天、1个月或3个月等打扫房间的服务工单的平均处理时间作为打扫房间的服务工单的工作量。上述服务提供方的工单处理能力值可采用如下方式计算得到：根据服务提供方历史时段内完成服务工单的平均用时，评估所述服务提供方的工单处理能力。例如，服务提供方A打扫一个房间所用的时间为20分钟，服务提供方B打扫一个房间所用的时间为30分钟，显然服务提供方A的工单处理能力要高于服务提供方B。在一种可实现的技术方案中，可为每种服务项目预先配置对应的平均用时与工单处理能力的对应关系，对某一服务提供方进行能力评估时直接根据该服务提供方的平均用户，查询该平均用时与工单处理能力的对应关系即可得到该服务提供方的工单处理能力。当然，也可采用其他评估算法，本申请实施例对此不作具体限定。

为了便于理解，这里举一个具体实例对上述从两个或两个以上的所述目标服务提供方中选出一个目标服务提供方的过程进行说明。假设采用上述方法选出的目标服务提供方为两个：服务提供方A和服务提供方B。服务提供方A和服务提供方B目前都有一个已确收未完成工单，即打扫房间。服务提供方A的工单处理能力：打扫房间用时20分钟；服务提供方B的工作处理能力：打扫房间用时30分钟。若分别给服务提供方A和服务提供方B派发所述服务工单还是打扫服务，则分别计算服务提供方A和B要处理完成两个房间的打扫需花费的时间。假设，服务提供方A当前打扫房间到服务工单指定的房间距离大于服务提供方B当前打扫房间到服务工单指定的房间的距离，如，服务提供方A从当前打扫房间到服务工单指定的房间的路程用时为5分钟；服务提供方B从当前打扫房间到服务工单指定的房间的路程用时为2分钟。对于服务提供方A来说，计算得到的总花费时间T_A＝20分钟+5分钟＝25分钟；对于服务提供方B来说，总花费时间T_B＝30分钟+2分钟＝32分钟。显然，将服务工单应派发给服务提供方A，服务提供方用时更短，房间及早被打扫出来，有助于提升服务组织效能。

在另一种具体的实施方案中，上述服务工单至少包含：第一服务类别及第一服务目的地。相应的，上述步骤104中，根据所述服务工单的服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方，可采用如下步骤实现：

1041、根据所述多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择职能属性涵盖的服务领域中包含所述第一服务类别服务的多个候选服务提供方。

1042、获取所述多个候选服务提供方中各候选服务提供方的已确收未完成工单的工作量及所述各候选服务提供方对应的客户端的位置信息。

1043、根据所述各候选服务提供方对应的客户端的位置信息及所述第一服务目的地，计算所述各候选服务提供方距所述服务目的地的距离。

1044、根据所述各候选服务提供方的已确收未完成工单的工作量及各候选服务提供方距所述第一服务目的地的距离，计算各候选服务提供方移动至所述第一服务目的地所需时间及所述各候选服务提供方完成各自已确收未完成工单的工作量所需时间的总时长。

1045、从所述多个待选服务提供方中，选择总时长最少的候选服务提供方作为所述目标服务提供方。

有关上述各步骤中已确收未完成工单的工作量及所述各候选服务提供方对应的客户端的位置信息的解释均可参见上述内容，此处不再赘述。

进一步的，当采用上述1041～1045选出的目标服务提供方为两个或两个以上时，本申请实施例提供的方法还可包括：

1046、获取两个或两个以上的所述目标服务提供方各自的工单处理能力值。

其中，各目标服务提供方的工单处理能力值可基于其历史工单完成情况得到。即，本申请实施例提供的技术方案中还包含有基于历史数据统计与各服务提供方有关的数据(例如工单处理能力值)的方案。本申请统计出的与各服务提供方有关的数据不仅限于服务提供方的工单处理能力值，还可是其他数据，本申请实施例对此不作具体限定。以统计与各服务提供方的工单处理能力值为例，本申请实施例提供的技术方案包括：

根据服务提供方历史时段内处理的历史工单工作量及各历史工单完成时长，确定所述服务提供方的工单处理能力值。

1047、从两个或两个以上的所述目标服务提供方中，选出工单处理能力值高的一个目标服务提供方。

这里需要补充的是：各服务提供方的职能属性可由服务端来维护，例如，服务端根据服务提供方(如酒店服务人员)通过客户端注册时上传的所属部门和/或具体的职责项等等信息，为服务提供方生成相应的职能属性。职能属性中可包含：所属部门、职责项(清扫服务、配水、婴儿床等服务)等等。例如，一个酒店服务人员，其所属部门为客房服务部门，则服务端可基于该客房服务部门所涉及的所有职责项，为所述酒店服务人员创建相应的职能属性。或者，酒店服务人员通过客户端注册时填入的具体职责项，为所述酒店服务人员创建相应的职能属性。这里基于具体职责项创建职能属性，比较适于一些仅提供特殊服务项的酒店服务人员，例如，仅提供清扫服务的酒店服务人员。

在服务端可维护有服务提供方及职能属性的对应关系信息。例如，下表2所示的对应关系。

表2、服务提供方及职能属性的对应关系

这里需要说明的是：有可能选择出的两个或两个以上的目标服务提供方都没有已派发未处理完的工单，此时可直接通过比较两个目标服务提供方的工单处理能力值，从中选择出一个工单处理能力值最强的目标服务提供方即可。

本申请发明人发现：现有技术中的服务工单派发出去以后就不再监控该工单是否被确收。当被派发的服务提供方由于正在服务或环境干扰无法接收到该派单通知时，很有可能影响到紧急类服务工单的处理进度。为此，为了监控服务工单被派发出去后的确收情况，本申请实施例中上述步骤105可具体采用如下方法实现：

1051、通知所述目标服务提供方确收所述服务工单。

1052、所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象。

1053、通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别通知对象被通知。

上述1051中，通知所述目标服务提供方时可采用至少一种通知方式。至少一种通知方式可包括：文本消息通知方式、语音通知方式或视频通知方式。在一种可实现的技术方案中，上述采用至少一种通知方式通知所述目标服务提供方确收所述服务工单，具体可采用如下方法实现：

采用第一通知方式，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应；

采用第一通知方式通知后的第一时长内未收到所述目标服务提供方对应的客户端针对所述服务工单反馈的确收响应时，从通知等级架构中查找级别高于所述第一通知方式的第二通知方式；

采用所述第二通知方式，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应；

采用所述第二通知方式通知后的第二时长内仍未收到所述目标服务提供方对应的客户端针对所述服务工单反馈的确收响应，且所述第二通知方式为所述通知等级架构中的最高级方式时，确定所述服务工单未确收。

一种可实施的方式是，所述通知等级架构中包括由低至高等级排布的文本消息通知方式、语音通知方式和视频通知方式中的任意两种或多种，如图2所示。

结合图2所示的工单通知部分，上述各步骤可简单理解为：通知方式升级过程，即当前派发服务工单的服务提供方在一定时间(如1分钟、2分钟或5分钟等)内没有确认接收该服务工单，那么通知的方式会由文本消息通知升级到语音通知；若服务提供方在一定时间内还未确认接收到该服务工单，则继续升级到视频通知或其他通知方式，继续通知服务提供方直至到通知等级架构中的最高一级通知方式；如果最高一级通知方式服务提供方还未确收，则确定所述服务工单未确收，进入步骤1052，即进入组织架构升级过程。组织架构升级过程可简单理解为：当采用最高一级通知方式服务提供方仍在一定时间内没有确认接收服务工单时，通知的人员会由服务提供方升级到主管。如果采用通知升级过程时仍是采用最高一级通知方式主管也未确收服务工单，则继续按照组织等级架构的上级继续升级，直到最高一级(如图2中的总经理级别)。其中，主管及主管级别以上的经理、总经理在确收服务工单后，可有几种处理方式，如线下找到组织等级架构中的最低等级的服务提供方进行处理；或找到合适的处理人，将工单转交给他处理；或亲自处理等。

或者，本申请实施例通过增加催促通知的方式，来提高服务工单的通知次数，以减低服务工单通知被忽略的概率。即本申请实施例提供的上述步骤105可具体采用如下方法实现：

1051’、向所述目标服务提供方对应的客户端发送针对所述服务工单的确收消息。

1052’、在所述确收消息发出后的第三时长内，若接收到用户通过工单管理客户端触发的催促请求，则向所述目标服务提供方对应的客户端发送针对所述服务工单的催促信息。

1053’、在所述催促消息发出后的第四时长内仍未收到所述目标服务提供方对应的客户端针对所述服务工单反馈的确收响应时，确定所述服务工单未确收。

本申请实施例中提及的服务工单的生成方式存在多种，例如通过呼叫中心来电的方式，消费者在APP手动提交的方式，消费者线下找到服务人员要求提供服务的方式，设备自检等方式触发生成。即本申请实施例提供的技术方案还可包括生成服务工单的步骤。其中，所述服务工单的可在如下几种事件被触发时生成。具体的：

响应于请求服务的来电事件，生成所述服务工单；和/或

响应于用户上传服务请求的触发事件，生成所述服务工单；和/或

响应于服务提供方上传用户请求服务的触发事件，生成所述服务工单；和/或

响应于系统自检出的服务事件，生成所述服务工单。

例如，在酒店服务场景中，客房来电请求维修网络问题，此时客房接线人员接收到请求电话后即可通过应用平台填写服务信息，并将该填写好的服务信息上传至服务端，以由服务端调用相应的工单模板将接收到的服务信息生成服务工单。

或者，用户通过客户端应用上传服务请求，服务端接收到客户端应用上传的服务请求后，提取服务请求中的服务信息，调用相应的工单模板生成服务工单。

或者，用户线下找到某一个服务员请求服务，该服务员可通过客户端应用上传用户的服务请求，同样的，服务端接收到客户端应用上传的服务请求后，提取服务请求中的服务信息，调用相应的工单模板生成服务工单。

或者，系统自检出的维护的设备故障，则自动针对该故障生成相应的服务工单。

进一步的，本申请实施例提供的技术方案还可包括如下步骤：

106、在工单队列中，查找相关联的多个服务工单。

具体的，在工单队列中，查找服务工单的服务内容相同、服务工单具有合并性的多个服务工单。

107、合并查找到的相关联的多个工单。

此处在工单队列中即将两个或多个服务工单进行合并，也是一种提高工单处理效率的一种方式。这种合并方式区别于上述将新派发的服务工单与已派发未处理完工单的建议合并处理的方式不一样，在未派发之前即将两个工单进行合并属于强制性合并处理的方式。

需要补充的是：通过上述方式进行服务工单的优先权确定时，可能会出现有两个或两个以上的优先级相同的服务工单出现。此时，还采用如下方法处理，即本申请实施例提供的技术方案还可包括如下步骤：

若工单队列中包含有至少两个优先级相同的服务工单，则获取优先级相同的服务工单的创建时间；根据所述创建时间，调整所述至少两个优先级相同的服务工单的派发次序。

本申请实施例提供的技术方案，基于服务工单及已派发未处理完工单的服务属性确定服务工单的优先级，在保证优先处理优先级高的工单的同时，还有助于实现服务工单与已派发未处理完工单的合并处理，进而提高工单的处理效率，提升服务组织效能；另外，本申请实施例提供的技术方案，还采用至少一种通知方式通知服务提供方确收服务工单，当服务工单未确收时，通知组织等级架构中级别高的通知对象来确收服务工单，以解决现有技术中服务提供方可能由于正在服务或环境干扰无法确收服务工单的情况下延误服务工单的确收进而影响服务工单的处理及时性等诸多问题，提高了服务工单的处理效率，服务效能提高，有助于提升用户对服务提供方的服务满意度。

进一步的，本实施例提供的技术方案可应用于多种应用场景中。在不同的应用场景中，相应的服务工单及服务提供方也不同。例如，在酒店服务类场景中，上述服务工单与线下酒店服务相关，服务提供方为酒店服务人员。

上述实施例提供的工单处理方法可基于如下系统架构实现。即如图3所示，本申请一实施例提供的工单处理系统的结构示意图。如图3所示，该工单处理系统包括：

服务端201，用于根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应；

所述目标服务提供方对应的第一客户端202，用于接收所述服务端发送的确收所述服务工单的通知，输出所述通知。

进一步的，本申请实施例提供的工单处理系统还可包括：通知对象对应的第二客户端203。相应的，

所述服务端201，还用于所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象；通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知；

所述通知对象对应的第二客户端203，用于接收所述服务端发送的确收服务工单的通知，输出所述通知。

这里需要说明的是：上述实施例提供的系统可应用在多种工单处理的应用场景中，例如在酒店服务场景。当本申请提供的工单处理系统应用于酒店服务场景中时，所述服务工单与线下酒店服务相关，服务提供方为酒店服务人员。

另外，本申请实施例提供的所述工单处理系统中各组成单元，如服务端、第一客户端、第二客户端的具体工作流程及之间的信令交互将在以下各实施例中作进一步的说明。

图4示出了本申请另一实施例提供的工单处理方法的流程图。本实施例提供的所述方法适用于服务端，其中，所述服务端可以是常用服务器、云端、虚拟服务器等，本申请实施例对此不作具体限定。如图4所示，所述工单处理方法包括：

301、根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序。

302、待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方。

303、通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应。

这里需要说明的是：本实施例中所述服务工单的派发次序是基于服务工单的优先级来确定的，即，根据所述优先级，确定所述服务工单在所述第一服务属性对应的工单队列中的派发次序。其中，服务工单的优先级确定过程可参见上述实施例中的相应内容，此处不作赘述。

进一步的，本申请实施例提供的技术方案还可包括：所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象；通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知。

上述302、通知所述目标服务提供方确收所述服务工单，可采用如下方法实现：

参见上述图2所示，所述通知等级架构中可包括由低至高等级排布的文本消息通知方式、语音通知方式和视频通知方式中的任意两种或多种。

或者，上述302、通知所述目标服务提供方确收所述服务工单，还可采用如下方法实现：

向所述目标服务提供方对应的客户端发送针对所述服务工单的确收消息；

在所述确收消息发出后的第三时长内，若接收到用户通过工单管理客户端触发的催促请求，则向所述目标服务提供方对应的客户端发送针对所述服务工单的催促信息；

在所述催促消息发出后的第四时长内仍未收到所述目标服务提供方对应的客户端针对所述服务工单反馈的确收响应时，确定所述服务工单未确收。

其中，上述的第一时长、第二时长、第三时长及第四时长可预先设定。第一时长、第二时长、第三时长及第四时长中的部分或全部可相等，或者部分或全部均不相等，本申请实施例对各时长的具体设定不作具体限定。

这里需要说明的是：本申请实施例提供的各方法步骤的具体实现可参见上述各实施例中的相应内容，此处不再赘述。

图5示出了本申请另一实施例提供的工单处理方法的流程图。本实施例提供的所述方法适用于客户端，该客户端可以是集成在终端上的一个具有嵌入式程序的硬件，也可以是安装在终端中的一个应用软件，还可以是嵌入在终端操作系统中的工具软件等，本发明实施例对此不作限定。该终端可以为包括手机、平板电脑、PDA(Personal DigitalAssistant，个人数字助理)、POS(Point of Sales，销售终端)、车载电脑等任意终端设备。具体的，如图5所示，本实施例提供的所述方法包括：

401、接收服务端在轮至服务工单的派发次序时根据所述服务工单的第一服务属性选择出的通知对象后发送的确收所述服务工单的通知。

402、输出所述通知。

其中，所述服务工单的派发次序是根据所述第一服务属性及已派发未处理完工单的第二服务属性确定的。同样的，所述服务工单的派发次序基于服务工单的优先级来确定的，即根据所述优先级，确定所述服务工单在所述第一服务属性对应的工单队列中的派发次序。其中，服务工单的优先级确定过程可参见上述实施例中的相应内容，此处不作赘述。

上述402中，输出所述通知可具体为：所述通知包括文本信息时，显示所述文本信息；和/或所述通知包括语音信息时，显示所述语音信息的页面元素；响应于用户针对所述语音信息的页面元素触发的触控操作，播放所述语音信息；和/或所述通知包括视频信息时，显示所述视频信息的页面元素；响应于用户针对所述视频信息的页面元素触发的触控操作，播放所述视频信息。

本实施例可扩展的是：此处视频方式可做到边指导边分配任务的目的。比如，对于某些专业人士有事不能及时处理某一紧急服务工单时，可上传操作视频，被指派处理该服务工单的服务人员可基于该视频中指导的操作过程完成该服务工单，如检修网络或房间内的电器等。

进一步的，本实施例提供的所述方法还可包括：

403、响应于用户针对所述通知触发的确收操作，向所述服务端反馈确收响应。

进一步的，本实施例提供的所述方法还可包括：

404、接收至少两个定位设备发送的定位信号及各定位设备的设备标识；

405、根据所述定位信号的强弱及各定位设备的设备标识，确定位置信息；

406、将所述位置信息上传至所述服务端。

其中，定位设备可以是蓝牙设备或wifi设备等。上述步骤404和405可采用现有蓝牙定位或wifi定位方案实现，具体实现过程参见现有技术中，此处不再赘述。这里将位置信息上传至服务端的目的是为了便于服务端将所述客户端上传的位置信息作为选择的合适的服务提供方的基础数据。例如，服务端在选择将服务工单派发给那个服务提供方时，可通过各服务提供方对应的客户端上传的位置信息，从中选择距离服务工单的服务目的地最近的服务提供方作为最终选择的工单派发对象。

进一步的，本实施例提供的所述方法还可包括：

407、享有服务工单分配权限时，响应于用户针对多个服务提供方触发的选择事件，将所述通知转发至所述选择事件指向的服务提供方。

本实施例提供的所述方法的执行主体客户端可以是安装在移动终端上的客户端应用APP。客户端应用APP可为使用该应用的用户，如服务人员、主管、经理、总经理分配不同的权限。主管、经理、总经理均可享有服务工单分配权限。具体实施时，客户端可通过上传服务端用户标识(如登录名)，由服务端判断该客户端的用户是否享有服务工单分配权限。

进一步的，本实施例提供的所述方法还可包括：

响应于用户针对所述服务工单触发的处理完成事件，向所述服务端反馈针对所述服务工单的处理完成消息，由所述服务端将所述服务工单的由未处理状态更改已处理状态。

这里需要说明的是：上述实施例中提及到已派发工单库，服务端在接收到服务工单的处理完成消息后，还可将该服务工单从已派发工单库中剔除。

图6示出了本申请一实施例提供的工单处理方法的流程示意图。如图6所示，本实施例提供的所述方法适用于服务端，其中，所述服务端可以是常用服务器、云端、虚拟服务器等，本申请实施例对此不作具体限定。如图6所示，所述工单处理方法包括：

501、通知服务工单派发对象对应的客户端做出确收所述服务工单的响应。

502、所述服务工单未确收时，从组织等级架构中查找级别高于所述派发对象的通知对象。

503、通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知。

上述501通知服务工单派发对象对应的客户端做出确收所述服务工单的响应，可具体包括：

采用第一通知方式，通知所述派发对象对应的客户端做出确收所述服务工单的响应；

采用第一通知方式通知后的第一时长内未收到所述派发对象对应的客户端针对所述服务工单反馈的确收响应时，从通知等级架构中查找级别高于所述第一通知方式的第二通知方式；

采用所述第二通知方式，通知所述派发对象对应的客户端做出确收所述服务工单的响应；

采用所述第二通知方式通知后的第二时长内仍未收到所述派发对象对应的客户端针对所述服务工单反馈的确收响应，且所述第二通知方式为所述通知等级架构中的最高级方式时，确定所述服务工单未确收。

其中，所述通知等级架构中包括由低至高等级排布的文本消息通知方式、语音通知方式和视频通知方式中的任意两种或多种。

或者，上述501通知服务工单派发对象对应的客户端做出确收所述服务工单的响应，可具体包括：

向所述派发对象对应的客户端发送针对所述服务工单的确收消息；

在所述确收消息发出后的第三时长内，若接收到用户通过工单管理客户端触发的催促请求，则向所述派发对象对应的客户端发送针对所述服务工单的催促信息；

在所述催促消息发出后的第四时长内仍未收到所述派发对象对应的客户端针对所述服务工单反馈的确收响应时，确定所述服务工单未确收。

上述502、通知组织等级架构中级别高于所述目标服务提供方的通知对象确收所述服务工单，也可采用至少一种通知方式进行通知，具体通知方式可参见上述501的具体实现过程。若采用至少一种通知方式通知所述通知对象后，服务工单还未被确收，则继续通知组织等级架构中级别高于所述通知对象的下一通知对象，直至服务工单被确收。具体的，如图2所示的，所述组织等级架构中包含有服务人员、主管、经理及总经理。采用短消息及语言通知，服务人员未确收就升级至主管；若采用短消息及语言通知，主管未确收就升级至经理；如此逐步升级直至服务工单被确收。这里需要说明的是，对应不同的应用场景，其组织等级架构是不同；即便是同一应用场景如酒店服务场景，不同酒店的内部组织等级结构也不一定相同。因此，组织等级架构可依据实际应用场景及具体场景中的实际情况来设定。

这里需要说明的是：有关本实施例提供的各步骤的实现内容，可参见上述各实施例中的相应的内容，此处不再赘述。

本申请实施例提供的技术方案，采用至少一种通知方式通知服务提供方确收服务工单，当服务工单未确收时，通知组织等级架构中级别高的通知对象来确收服务工单，以解决现有技术中服务提供方可能由于正在服务或环境干扰无法确收服务工单的情况下延误服务工单的确收进而影响服务工单的处理及时性等诸多问题，提高了服务工单的处理效率，服务效能提高，有助于提升用户对服务提供方的服务满意度。

上述图6所示的实施例是从服务端的角度来叙述的。本申请实施例提供的技术方案从客户端的角度，具体包括：接收服务端发送的确收服务工单的通知；输出所述通知。其中，所述通知的通知对象是根据服务工单的服务属性，从多个服务提供方中选择出的，或者所述通知的通知对象的级别在组织等级架构中高于根据服务工单的服务属性从多个服务提供方中选择出的通知对象。

其中，所述通知对象可以是服务人员对应的客户端、经理对应的客户端、主管对应的客户端、总经理对应的客户端等等。通知方式可以包括：文本消息方式、语音方式、视频方式等等，本申请实施例对此不作具体限定。

输出所述通知具体为：所述通知包括文本信息时，显示所述文本信息；和/或所述通知包括语音信息时，显示所述语音信息的页面元素；响应于用户针对所述页面元素触发的触控操作，播放所述语音信息；和/或所述通知包括视频信息时，显示所述视频信息的页面元素；响应于用户针对所述页面元素触发的触控操作，播放所述视频信息。

进一步的，还包括：响应于用户针对所述通知触发的确收操作，向所述服务端反馈确收响应。

进一步的，还包括：接收至少两个定位设备发送的定位信号及各定位设备的设备标识；根据所述定位信号的强弱及各定位设备的设备标识，确定位置信息；将所述位置信息上传至所述服务端。

进一步的，客户端可为每一个服务提供方分配一个对应的用户。每个用户可具有不同权限。例如，图2所示的组织等级架构中，不同等级的服务提供方可具有不同的权限。即，本申请实施例提供的技术方案，还可包括如下步骤：享有服务工单分配权限时，响应于用户针对多个服务提供方触发的选择事件，将所述通知转发至所述选择事件指向的服务提供方。

进一步的，本申请实施例还包括如下步骤：响应于用户针对所述服务工单触发的处理完成事件，向所述服务端反馈针对所述服务工单的处理完成消息，由所述服务端将所述服务工单的由未处理状态更改已处理状态。

上述图6所示的实施例及上述与图6对应的从客户端侧说明的方案也可基于类似于上述实施例中图3所示的系统架构下实现。即本实施例提供的，上述该系统包括：

服务端，用于通知服务工单派发对象对应的客户端做出确收所述服务工单的响应；所述服务工单未确收时，从组织等级架构中查找级别高于所述派发对象的通知对象；通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知；

所述派发对象对应的第一客户端，用于接收服务端发送的确收服务工单的通知并输出所述通知；

所述通知对象对应的第二客户端，用于接收所述服务端发送的确收服务工单的通知并输出所述通知。

这里需要说明的是，本实施例提供的所述服务端、第一客户端和第二客户端还可实现上述各实施例中涉及的步骤，具体的实现内容可参见上述各实施例中的内容，此处不再赘述。

图7示出了本申请一实施例提供的工单处理方法的流程示意图。如图所示，本实施例包括：

601、服务端响应于工单触发事件，生成服务工单。

602、服务端获取所述服务工单的第一服务属性，并根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级。

603、服务端将所述服务工单按照所述优先级列入所述第一服务属性对应的工单队列中等待派发。

604、待轮至派发所述服务工单时，服务端根据所述服务工单的服务属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方。

605、服务端采用第一种通知方式通知所述目标服务提供方确收所述服务工单。

606、服务端对所述服务工单进行确收监听，若服务端未接收到所述目标服务提供方对应的第一客户端反馈的确收响应，则服务端采用第二种方式通知；若服务端接收到针对所述服务工单的确收响应，则停止监听。

607、服务端对所述服务工单进行确收监听，若服务端采用第二种方式通知还未接收到针对所述服务工单的确收响应，则当前通知对象不是组织等级架构中的最高一级时，采用第一通知方式通知组织等级架构中级别高一级别通知对象确收所述服务工单，返回步骤606；若服务端接收到针对所述服务工单的确收响应，则停止监听。

上述实施例中，当通知对象升级到组织等级架构中的最高一级别的通知对象时，服务端停止监听。

这里需要补充的是：本实施例提供的具体实现实例中，服务端采用的通知方式升级架构中仅有两种通知方式，实际上服务端采用的通知方式升级架构中可包含有三级或三级以上的通知方式，参见图2所示，如文本消息方式、语音方式及视频方式等等，本申请实施例对此不作具体限定。

上述601～607的具体实现可参见上述各实施例中的相应内容，此处不再赘述。

本申请各实施例提供的技术方案还可扩展的是：上述各实施例中的服务提供方可以是被多个酒店或商场所用的服务人员。多个不同的酒店或商场共享服务人员，该服务人员为多个不同的酒店或商场提供相同的或不同的服务。例如，修理酒店空调、维护酒店系统网络等的服务人员。该服务人员可在通过客户端注册时，上传其职责项的同时还上传其所负责的多个酒店或上商场的标识，以便服务端将其所负责的多个酒店或上商场的标识也作为该服务人员的职能属性中的数据。相应的，本申请各实施例提供的技术方案中服务工单的第一服务属性还可包括：来源方信息(即酒店标识或商场标识)。以及，上述各实施例中：根据所述多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择职能属性涵盖的服务领域中包含所述第一服务类别服务的多个候选服务提供方，应具体为：

根据所述多个服务提供方中各服务提供方的职能属性中包含的服务场所标识及职责项，从所述多个服务提供方中选择服务场所标识与所述服务工单的来源方信息匹配，且职责项包含所述第一服务类别服务的多个候选服务提供方。

下面将以酒店应用场景为例，对本申请实施例提供的技术方案进行说明。

图8示出了本申请又一实施例提供的工单处理方法的流程示意图。本实施例提供的所述方法适用于服务端，其中，所述服务端可以是常用服务器、云端、虚拟服务器等，本申请实施例对此不作具体限定。如图8所示，该方法包括：

611、根据与线下酒店服务相关的服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序。

612、待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员。

613、通知所述目标酒店服务人员对应的客户端作出确收所述服务工单的响应。

上述611～613的具体实现可参见上述各实施例中的相关内容，此处不再赘述。

进一步的，本实施例提供的所述方法，其特征在于，还包括：

614、所述服务工单未确收时，从组织等级架构中查找级别高于所述目标酒店服务人员的管理人员。

615、通知所述管理人员对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别管理人员被通知。

其中，上述通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应，包括：

采用第一通知方式，通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应；

采用第一通知方式通知后的第一时长内未收到所述目标酒店服务人员对应的客户端针对所述服务工单反馈的确收响应时，从通知等级架构中查找级别高于所述第一通知方式的第二通知方式；

采用所述第二通知方式，通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应；

采用所述第二通知方式通知后的第二时长内仍未收到所述目标酒店服务人员对应的客户端针对所述服务工单反馈的确收响应，且所述第二通知方式为所述通知等级架构中的最高级方式时，确定所述服务工单未确收。

或者，上述通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应，包括：

向所述目标酒店服务人员对应的客户端发送针对所述服务工单的确收消息；

在所述确收消息发出后的第三时长内，若接收到工单管理用户通过工单管理客户端触发的催促请求，则向所述目标酒店服务人员对应的客户端发送针对所述服务工单的催促信息；

在所述催促消息发出后的第四时长内仍未收到所述目标酒店服务人员对应的客户端针对所述服务工单反馈的确收响应时，确定所述服务工单未确收。

进一步的，第一服务属性包含：第一酒店服务类别及第一酒店区域内服务目的地；以及

上述612、根据所述第一服务属性及多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员，包括：

根据所述多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择职能属性涵盖的服务领域中包含所述第一酒店服务类别服务的多个候选酒店服务人员；

获取所述多个候选酒店服务人员中各候选酒店服务人员的已确收未完成工单的工作量及所述各候选酒店服务人员对应客户端的位置信息；

根据所述各候选酒店服务人员对应客户端的位置信息及所述第一酒店区域内服务目的地，计算所述各候选酒店服务人员距所述第一酒店区域内服务目的地的距离；

根据所述各候选酒店服务人员的已确收未完成工单的工作量及各候选酒店服务人员距所述第一酒店区域内服务目的地的距离，计算各候选酒店服务人员移动至所述第一酒店区域内服务目的地所需时间及所述各候选酒店服务人员完成各自已确收未完成工单的工作量所需时间的总时长；

从所述多个待选酒店服务人员中，选择总时长最少的候选酒店服务人员作为所述目标酒店服务人员。

进一步的，上述获取所述各候选酒店服务人员对应客户端的位置信息；

接收酒店区域内布置的多个定位设备上传的各候选酒店服务人员对应客户端的定位感测信号，基于所述各候选酒店服务人员对应客户端的定位感测信号计算所述各候选酒店服务人员对应客户端的位置信息；或者

接收各候选酒店服务人员对应的客户端上报的位置信息。

进一步的，本申请实施例所述的方法，还可包括：

响应于酒店客人通过客户端触发的请求服务来电事件，生成所述服务工单；和/或

响应于酒店客人通过客户端上传服务请求信息的触发事件，生成所述服务工单；和/或

响应于酒店服务人员或管理人员通过客户端上传酒店客人请求服务的触发事件，生成所述服务工单；和/或

响应于酒店服务系统自检出的服务事件，生成所述服务工单。

本实施例中提及的各步骤的具体实现可参见上述各实施例中的相关内容，此处不再赘述。

下面通过简单的示例，并通过与现有方式处理同样服务项目的效率进行比较，以对本申请实施例提供的技术方案所带来的效果进行说明。

假设人工通知服务人员需要1分钟，服务人员送水服务需要5分钟(从仓库取数2分钟，送水到客房3分钟)

场景一、如果有两个相邻的住客需要送水服务。

按照传动的方式花费的人工成本：1分钟*2(通知)+5分钟*2(送水过程)＝12分钟。

按照本申请技术方案的方式花费的人工成本：0分钟(通知不需要人工参与)+5分钟(送水过程合并)＝5分钟。

场景一种，本申请技术方案花费的人工成本降低了58.3％。

场景二、如果有1个住客需要送水服务，一个服务员在仓库附近，一个服务员不在仓库附近。

按照传动的方式花费的人工成本：1分钟(通知)+5分钟*50％(50％的概率派发到离仓库远的服务人员)+3分钟*50％(50％的概率派发到离仓库近的服务人员)＝5分钟。

按照本申请技术方案的方式花费的人工成本：0分钟(通知不需要人工参与)+3分钟(直接派发到离仓库近的服务人员)＝3分钟，这种情况下本申请技术方案花费的成本降低了40％。

场景三、如果有1个住客需要送水服务，第一次无法联系到对应的服务人员，第二次才联系到。

按照传统的方式花费的人工成本：2分钟(通知)+5分钟(送水过程)＝7分钟。

按照本申请技术方案的方式花费的人工成本:0分钟(通知)+5分钟(送水过程)＝5分钟，这种情况下本申请技术方案花费的成本降低了28.5％。

场景四、如果有1个住客需要送水服务，第一次、第二次无法联系到对应的服务人员，第三次才联系到

按照传统的方式花费的人工成本：3分钟(通知)+5分钟(送水过程)＝8分钟。

按照本申请技术方案的方式花费的人工成本:0分钟(通知)+5分钟(送水过程)＝5分钟，这种情况下本申请技术方案花费的成本降低了37.5％。

图9示出了本申请一实施例提供的工单处理装置的结构示意图。如图9所示，该装置包括：

第一获取模块701，用于获取服务工单的第一服务属性；

第一确定模块702，用于根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级；

列入模块703，用于将所述服务工单按照所述优先级列入所述第一服务属性对应的工单队列中等待派发。

进一步的，所述第一确定模块702还用于：根据所述第一服务属性，确定第一优先级；基于所述第一服务属性与所述已派发未处理完工单的第二服务属性，评估所述服务工单与所述已派发未处理完工单合并处理的概率；根据所述概率确定第二优先级；根据所述第一优先级及所述第二优先级，计算所述服务工单的优先级。

进一步的，所述服务属性包括创建时间、服务类别、服务项目、服务请求方信息、紧急度信息中的一种或多种；以及所述第一确定模块702还用于：获取所述服务属性包含的各信息对应的权重；基于各信息对应的权重，计算所述第一优先级。

进一步的，所述第一确定模块702还用于根据所述第一服务属性中包含的第一服务目的地与所述第二服务属性中包含的第二服务目的地，计算同一服务提供方合并处理所述服务工单与所述已派发未处理完工单时从所述第一服务目的地至所述第二服务目的地所需的路程用时；根据所述第一服务属性中包含的第一服务项目与所述第二服务属性中包含的第二服务项目，确定可合并性；根据所述路程用时及所述可合并性，计算所述服务工单与所述已派发未处理完工单合并处理的概率。

进一步的，本实施例提供的装置还可包括：第二获取模块，用于获取历史上同一服务提供方合并处理服务工单的概率；修正模块，用于基于所述历史上同一服务提供方合并处理服务工单的概率，对所述服务工单与所述已派发未处理完工单合并处理的概率进行修正。

进一步的，本实施例提供的装置还可包括：

选择模块，用于待轮至派发所述服务工单时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；

通知模块，用于通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应。

查找模块，用于所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象；

所述通知模块，还用于通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别通知对象被通知。

进一步的，所述通知模块还用于：

进一步的，所述通知等级架构中包括由低至高等级排布的文本消息通知方式、语音通知方式和视频通知方式中的任意两种或多种。

或者，所述通知模块还用于向所述目标服务提供方对应的客户端发送针对所述服务工单的确收消息；在所述确收消息发出后的第三时长内，若接收到用户通过工单管理客户端触发的催促请求，则向所述目标服务提供方对应的客户端发送针对所述服务工单的催促信息；在所述催促消息发出后的第四时长内仍未收到所述目标服务提供方对应的客户端针对所述服务工单反馈的确收响应时，确定所述服务工单未确收。

进一步的，所述第一服务属性包括：第一服务类别和/或第一服务目的地；以及，所述选择模块还用于：

根据所述多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择职能属性涵盖的服务领域中包含所述第一服务类别服务的多个候选服务提供方；

获取所述多个候选服务提供方中各候选服务提供方的已确收未完成工单的工作量及所述各候选服务提供方对应的客户端的位置信息；

根据所述各候选服务提供方对应的客户端的位置信息及所述第一服务目的地，计算所述各候选服务提供方距所述服务目的地的距离；

根据所述各候选服务提供方的已确收未完成工单的工作量及各候选服务提供方距所述第一服务目的地的距离，计算各候选服务提供方移动至所述第一服务目的地所需时间及所述各候选服务提供方完成各自已确收未完成工单的工作量所需时间的总时长；

从所述多个待选服务提供方中，选择总时长最少的候选服务提供方作为所述目标服务提供方。

进一步的，所述目标服务提供方为两个或两个以上时，所述选择模块还用于：

获取两个或两个以上的所述目标服务提供方各自的工单处理能力值；

从两个或两个以上的所述目标服务提供方中，选出工单处理能力值高的一个目标服务提供方。

进一步的，本实施例提供的装置还包括：

第二确定模块，根据服务提供方历史时段内处理的历史工单工作量及各历史工单完成时长，确定所述服务提供方的工单处理能力值。

进一步的，本申请实施例还包括生成模块。所述生成模块用于：

响应于请求服务的来电事件，生成所述服务工单；和/或

响应于系统自检出的服务事件，生成所述服务工单。

这里需要说明的是：上述实施例提供的工单处理装置可实现上述各方法实施例中描述的技术方案，上述各模块或单元具体实现的原理可参见上述各方法实施例中的相应内容，此处不再赘述。

本申请实施例还提供的技术方案，采用至少一种通知方式通知服务提供方确收服务工单，当服务工单未确收时，通知组织等级架构中级别高的通知对象来确收服务工单，以解决现有技术中服务提供方可能由于正在服务或环境干扰无法确收服务工单的情况下延误服务工单的确收进而影响服务工单的处理及时性等诸多问题，提高了服务工单的处理效率，服务效能提高，有助于提升用户对服务提供方的服务满意度。

图10示出了本申请一实施例提供的种工单处理装置的结构示意图。如图10所示，本实施例提供的所述装置包括：

确定模块801，用于根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；

选择模块802、待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；

通知模块803，用于通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应。

进一步的，所述通知模块803还用于：

所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象；

进一步的，所述通知模块803还用于：

或者，所述通知模块还用于：

进一步的，所述第一服务属性包括：第一服务类别及第一服务目的地，以及所述选择模块802还用于：

进一步的，所述确定模块801还用于：

根据所述第一服务属性，确定第一优先级；

基于所述第一服务属性与所述已派发未处理完工单的第二服务属性，评估所述服务工单与所述已派发未处理完工单合并处理的概率；

根据所述概率确定第二优先级；

根据所述第一优先级及所述第二优先级，计算所述服务工单的优先级；

根据所述优先级，确定所述服务工单在所述第一服务属性对应的工单队列中的派发次序。

进一步的，所述确定模块801还用于：

根据所述第一服务属性中包含的第一服务目的地与所述第二服务属性中包含的第二服务目的地，计算同一服务提供方合并处理所述服务工单与所述已派发未处理完工单时从所述第一服务目的地至所述第二服务目的地所需的路程用时；

根据所述第一服务属性中包含的第一服务项目与所述第二服务属性中包含的第二服务项目，确定可合并性；

根据所述路程用时及所述可合并性，计算所述服务工单与所述已派发未处理完工单合并处理的概率。

进一步的，本申请实施例提供的装置，还包括：

获取模块，用于获取历史上同一服务提供方合并处理服务工单的概率；

修正模块，用于基于所述历史上同一服务提供方合并处理服务工单的概率，对所述服务工单与所述已派发未处理完工单合并处理的概率进行修正。

进一步的，所述服务工单与线下酒店服务相关，服务提供方为酒店服务人员。

图11示出了本申请一实施例提供的工单处理装置的结构示意图。如图11所示，该装置包括：

接收模块901，用于接收服务端在轮至服务工单的派发次序时根据所述服务工单的第一服务属性选择出的通知对象后发送的确收所述服务工单的通知；

输出模块902，用于输出所述通知；

进一步的，所述输出模块902用于：

所述通知包括文本信息时，显示所述文本信息；和/或

所述通知包括语音信息时，显示所述语音信息的页面元素；响应于用户针对所述页面元素触发的触控操作，播放所述语音信息。

进一步的，该装置还包括反馈模块，用于响应于用户针对所述通知触发的确收操作，向所述服务端反馈确收响应。

进一步的，该装置还包括：

确定模块，用于根据接收到的定位设备发送的定位信号强弱及所述定位设备的安装位置，确定位置信息；

上传模块，用于将所述位置信息上传至所述服务端。

进一步的，该装置还包括：

转发模块，用于享有服务工单分配权限时，响应于用户针对多个服务提供方触发的选择事件，将所述通知转发至所述选择事件指向的服务提供方。

进一步的，所述反馈模块还用于响应于用户针对所述服务工单触发的处理完成事件，向所述服务端反馈针对所述服务工单的处理完成消息，由所述服务端将所述服务工单的由未处理状态更改已处理状态。

图12示出了本申请一实施例提供的工单处理装置的结构示意图。如图12所示，该装置，包括：

通知模块1001，用于通知服务工单派发对象对应的客户端做出确收所述服务工单的响应；

选择模块1002，用于所述服务工单未确收时，从组织等级架构中查找级别高于所述派发对象的通知对象；

所述通知模块1001，还用于通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知。

进一步的，所述通知模块1001还用于：

进一步的，所述通知模块1001还用于

图13示出了本申请一实施例提供的工单处理装置的结构示意图。如图12所示，该装置包括：

确定模块1101，根据与线下酒店服务相关的服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序；

选择模块1102、待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员；

通知模块1103、通知所述目标酒店服务人员对应的客户端作出确收所述服务工单的响应。

进一步的，所述装置还包括：

查找模块，用于所述服务工单未确收时，从组织等级架构中查找级别高于所述目标酒店服务人员的管理人员；

所述通知模块1103还用于：通知所述管理人员对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别管理人员被通知。

进一步的，所述通知模块1103还用于：

或者，所述通知模块1103还用于：

或者，所述第一服务属性包含：第一酒店服务类别及第一酒店区域内服务目的地；以及所述选择模块还用于：

进一步的，所述选择模块还用于：

接收各候选酒店服务人员对应的客户端上报的位置信息。

进一步的，所述装置还包括生成模块。所述生成模块用于：

图14示出了本申请一实施例提供的电子设备的结构示意图。如图所示，该电子设备包括：第一存储器1201和第一处理器1202，其中，

所述第一存储器11201，用于存储程序；

所述第一处理器1202，与所述第一存储器1201耦合，用于执行所述第一存储器1201中存储的所述程序，以用于：

获取服务工单的第一服务属性；

上述第一存储器1201可被配置为存储其它各种数据以支持在云端设备上的操作。这些数据的示例包括用于在云端设备上操作的任何应用程序或方法的指令。第一存储器1201可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

上述第一处理器1202在执行第一存储器1201中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步，如图14所示，电子设备还包括：第一通信组件1203、第一显示器1204、第一电源组件1205、第一音频组件1206等其它组件。图14中仅示意性给出部分组件，并不意味着电子设备只包括图14所示组件。

相应地，本申请实施例还提供一种存储有计算机程序的计算机可读存储介质，所述计算机程序被计算机执行时能够实现上述各实施例提供的工单处理方法步骤或功能。

图15示出了本申请一实施例提供的服务端设备的结构示意图。如图15所示，本实施例提供的所述服务端设备包括：第二存储器1301和第二处理器1302，其中，

所述第二存储器1301，用于存储程序；

所述第二处理器1302，与所述第二存储器1301耦合，用于执行所述第二存储器1301中存储的所述程序，以用于：

本申请实施例提供的技术方案，基于服务工单及已派发未处理完工单的服务属性确定服务工单的优先级，在保证优先处理优先级高的工单的同时，还有助于实现服务工单与已派发未处理完工单的合并处理；并基于服务工单的属性信息为服务工单选择最合适的服务提供方，进而提高工单的处理效率，提升服务组织效能。

上述第二存储器1301可被配置为存储其它各种数据以支持在云端设备上的操作。这些数据的示例包括用于在云端设备上操作的任何应用程序或方法的指令。第二存储器1301可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

上述第二处理器1302在执行第二存储器1301中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步，如图15所示，电子设备还包括：第二通信组件1303、第二显示器1304、第二电源组件1305、第二音频组件1306等其它组件。图15中仅示意性给出部分组件，并不意味着电子设备只包括图15所示组件。

图16示出了本申请一实施例提供的客户端设备的结构示意图。如图16所示，本实施例提供的客户端设备包括：第三存储器1401和第三处理器1402，其中，

所述第三存储器1401，用于存储程序；

所述第三处理器1402，与所述第三存储器耦合，用于执行所述第三存储器1401中存储的所述程序，以用于：

输出所述通知；

上述第三存储器1401可被配置为存储其它各种数据以支持在云端设备上的操作。这些数据的示例包括用于在云端设备上操作的任何应用程序或方法的指令。第三存储器1401可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

上述第三处理器1402在执行第三存储器1401中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步，如图16所示，电子设备还包括：第三通信组件1403、第三显示器1404、第三电源组件1405、第三音频组件1406等其它组件。图16中仅示意性给出部分组件，并不意味着电子设备只包括图16所示组件。

图17示出了本申请一实施例提供的服务端设备的结构示意图。如图17所示，本实施例提供的所述服务端设备包括：第四存储器1501和第四处理器1502，其中，

所述第四存储器1501，用于存储程序；

所述第四处理器1502，与所述第四存储器1501耦合，用于执行所述第四存储器1501中存储的所述程序，以用于：

上述第四存储器1501可被配置为存储其它各种数据以支持在云端设备上的操作。这些数据的示例包括用于在云端设备上操作的任何应用程序或方法的指令。第四存储器1501可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

上述第四处理器1502在执行第四存储器1501中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步，如图17所示，电子设备还包括：第四通信组件1503、第四显示器1504、第四电源组件1505、第四音频组件1506等其它组件。图17中仅示意性给出部分组件，并不意味着电子设备只包括图17所示组件。

图18示出了本申请一实施例提供的服务端设备的结构示意图。如图18所示，本实施例提供的所述服务端设备包括：第五存储器1601和第五处理器1602，其中，

所述第五存储器1601，用于存储程序；

所述第五处理器1602，与所述第五存储器1601耦合，用于执行所述第五存储器1601中存储的所述程序，以用于：

上述第五存储器1601可被配置为存储其它各种数据以支持在云端设备上的操作。这些数据的示例包括用于在云端设备上操作的任何应用程序或方法的指令。第五存储器1601可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

上述第五处理器1602在执行第五存储器1601中的程序时，除了上面的功能之外，还可实现其它功能，具体可参见前面各实施例的描述。

进一步，如图18所示，电子设备还包括：第五通信组件1603、第五显示器1604、第五电源组件1605、第五音频组件1606等其它组件。图18中仅示意性给出部分组件，并不意味着电子设备只包括图18所示组件。

以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)处理各个实施例或者实施例的某些部分所述的方法。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的精神和范围。

Claims

1.一种工单处理方法，其特征在于，包括：

获取服务工单的第一服务属性；

2.根据权利要求1所述的工单处理方法，其特征在于，根据所述第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的优先级，包括：

根据所述第一服务属性，确定第一优先级；

根据所述概率确定第二优先级；

根据所述第一优先级及所述第二优先级，计算所述服务工单的优先级。

3.根据权利要求2所述的方法，其特征在于，所述服务属性包括创建时间、服务类别、服务项目、服务请求方信息、紧急度信息中的一种或多种；以及

根据所述服务工单的服务属性，确定所述服务工单的第一优先级，包括：

获取所述服务属性包含的各信息对应的权重；

基于各信息对应的权重，计算所述第一优先级。

4.根据权利要求3所述的方法，其特征在于，根据所述第一服务属性与所述已派发未处理完工单的第二服务属性，评估所述服务工单与所述已派发未处理完工单合并处理的概率，包括：

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

获取历史上同一服务提供方合并处理服务工单的概率；

基于所述历史上同一服务提供方合并处理服务工单的概率，对所述服务工单与所述已派发未处理完工单合并处理的概率进行修正。

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

待轮至派发所述服务工单时，根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方；

通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应；

通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别通知对象被通知。

7.根据权利要求6所述的方法，其特征在于，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应，包括：

8.根据权利要求7所述的方法，其特征在于，所述通知等级架构中包括由低至高等级排布的文本消息通知方式、语音通知方式和视频通知方式中的任意两种或多种。

9.根据权利要求6所述的方法，其特征在于，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应，包括：

10.根据权利要求6所述的方法，其特征在于，所述第一服务属性包含：第一服务类别及第一服务目的地；以及

根据所述第一服务属性及多个服务提供方中各服务提供方的职能属性，从所述多个服务提供方中选择能处理所述服务工单的目标服务提供方，包括：

11.根据权利要求10所述的方法，其特征在于，选出的所述目标服务提供方为两个或两个以上时，

所述方法，还包括：

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

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

响应于请求服务的来电事件，生成所述服务工单；和/或

响应于系统自检出的服务事件，生成所述服务工单。

14.一种工单处理方法，其特征在于，包括：

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

16.根据权利要求14所述的方法，其特征在于，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应，包括：

17.根据权利要求14所述的方法，其特征在于，通知所述目标服务提供方对应的客户端做出确收所述服务工单的响应，包括：

18.根据权利要求14至17中任一项所述的方法，其特征在于，所述第一服务属性包含：第一服务类别及第一服务目的地；以及

19.根据权利要求14至17所述的方法，其特征在于，根据服务工单的第一服务属性及已派发未处理完工单的第二服务属性，确定所述服务工单的派发次序，包括：

根据所述第一服务属性，确定第一优先级；

根据所述概率确定第二优先级；

20.根据权利要求19所述的方法，其特征在于，基于所述第一服务属性与所述已派发未处理完工单的第二服务属性，评估所述服务工单与所述已派发未处理完工单合并处理的概率，包括：

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

获取历史上同一服务提供方合并处理服务工单的概率；

22.一种工单处理方法，其特征在于，

输出所述通知；

23.根据权利要求22所述的方法，其特征在于，输出所述通知，包括：

所述通知包括文本信息时，显示所述文本信息；和/或

所述通知包括语音信息时，显示所述语音信息的页面元素；响应于用户针对所述页面元素触发的触控操作，播放所述语音信息；和/或

所述通知包括视频信息时，显示所述视频信息的页面元素；响应于用户针对所述视频信息的页面元素触发的触控操作，播放所述视频信息。

24.根据权利要求22或23所述的方法，其特征在于，还包括：

根据接收到的定位设备发送的定位信号强弱及所述定位设备的安装位置，确定位置信息；

将所述位置信息上传至所述服务端。

25.根据权利要求22或23所述的方法，其特征在于，还包括：

享有服务工单分配权限时，响应于用户针对多个服务提供方触发的选择事件，将所述通知转发至所述选择事件指向的服务提供方。

26.一种工单处理系统，其特征在于，包括：

27.根据权利要求26所述的系统，其特征在于，还包括：

所述服务端，还用于所述服务工单未确收时，从组织等级架构中查找级别高于所述目标服务提供方的通知对象；通知所述通知对象对应的客户端做出确收所述服务工单的响应，直至所述服务工单确收或所述组织等级架构中最高级别通知对象被通知；

所述通知对象对应的第二客户端，用于接收所述服务端发送的确收所述服务工单的通知，输出所述通知。

28.一种工单处理方法，其特征在于，包括：

29.根据权利要求28所述的方法，其特征在于，通知服务工单派发对象对应的客户端做出确收所述服务工单的响应，包括：

30.根据权利要求28所述的方法，其特征在于，通知服务工单派发对象对应的客户端做出确收所述服务工单的响应，包括：

31.一种工单处理方法，其特征在于，包括：

待轮至所述服务工单的派发次序时，根据所述第一服务属性及多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员；

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

所述服务工单未确收时，从组织等级架构中查找级别高于所述目标酒店服务人员的管理人员；

通知所述管理人员对应的客户端做出确收所述服务工单的响应，直至所述服务工单被确收或所述组织等级架构中最高级别管理人员被通知。

33.根据权利要求31或32所述的方法，其特征在于，通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应，包括：

34.根据权利要求31或32所述的方法，其特征在于，通知所述目标酒店服务人员对应的客户端做出确收所述服务工单的响应，包括：

35.根据权利要求31或32所述的方法，其特征在于，所述第一服务属性包含：第一酒店服务类别及第一酒店区域内服务目的地；以及

根据所述第一服务属性及多个酒店服务人员中各酒店服务人员的职能属性，从所述多个酒店服务人员中选择能处理所述服务工单的目标酒店服务人员，包括：

36.根据权利要求35所述的方法，其特征在于，获取所述各候选酒店服务人员对应客户端的位置信息；

接收各候选酒店服务人员对应的客户端上报的位置信息。

37.根据权利要求31或32所述的方法，其特征在于，还包括：

38.一种电子设备，其特征在于，包括：第一存储器和第一处理器，其中，

所述第一存储器，用于存储程序；

获取服务工单的第一服务属性；

39.一种服务端设备，其特征在于，包括：第二存储器和第二处理器，其中，

所述第二存储器，用于存储程序；

40.一种客户端设备，其特征在于，包括：第三存储器和第三处理器，其中，

所述第三存储器，用于存储程序；

输出所述通知；

41.一种服务端设备，其特征在于，包括：第四存储器和第四处理器，其中，

所述第四存储器，用于存储程序；

42.一种服务端设备，其特征在于，包括：第五存储器和第五处理器，其中，

所述第五存储器，用于存储程序；