CN109272368A - 订单处理方法、装置、服务器、移动终端和存储介质 - Google Patents
订单处理方法、装置、服务器、移动终端和存储介质 Download PDFInfo
- Publication number
- CN109272368A CN109272368A CN201710585026.0A CN201710585026A CN109272368A CN 109272368 A CN109272368 A CN 109272368A CN 201710585026 A CN201710585026 A CN 201710585026A CN 109272368 A CN109272368 A CN 109272368A
- Authority
- CN
- China
- Prior art keywords
- order
- driver
- orders
- competition
- driver terminal
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title claims abstract description 35
- 238000012216 screening Methods 0.000 claims description 59
- 238000010835 comparative analysis Methods 0.000 claims description 58
- 230000004044 response Effects 0.000 claims description 45
- 238000012545 processing Methods 0.000 claims description 38
- 230000005540 biological transmission Effects 0.000 claims description 28
- 230000015654 memory Effects 0.000 claims description 23
- 238000004590 computer program Methods 0.000 claims description 21
- 238000004458 analytical method Methods 0.000 claims description 13
- 230000008901 benefit Effects 0.000 claims description 4
- 230000009286 beneficial effect Effects 0.000 abstract description 38
- 230000006978 adaptation Effects 0.000 abstract description 33
- 238000012986 modification Methods 0.000 abstract description 33
- 230000004048 modification Effects 0.000 abstract description 33
- 238000011156 evaluation Methods 0.000 description 17
- 230000006870 function Effects 0.000 description 16
- 238000012790 confirmation Methods 0.000 description 14
- 230000002452 interceptive effect Effects 0.000 description 12
- 239000002699 waste material Substances 0.000 description 12
- 238000000034 method Methods 0.000 description 11
- 238000010586 diagram Methods 0.000 description 10
- 230000006399 behavior Effects 0.000 description 7
- 230000000694 effects Effects 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000008569 process Effects 0.000 description 6
- 238000012797 qualification Methods 0.000 description 6
- 238000012552 review Methods 0.000 description 5
- 238000005516 engineering process Methods 0.000 description 3
- OKTJSMMVPCPJKN-UHFFFAOYSA-N Carbon Chemical compound [C] OKTJSMMVPCPJKN-UHFFFAOYSA-N 0.000 description 1
- 229910052799 carbon Inorganic materials 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 230000007812 deficiency Effects 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000036651 mood Effects 0.000 description 1
- 230000008439 repair process Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0607—Regulated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
- G06Q30/0601—Electronic shopping [e-shopping]
- G06Q30/0633—Lists, e.g. purchase orders, compilation or processing
- G06Q30/0635—Processing of requisition or of purchase orders
-
- G06Q50/40—
Abstract
本发明提供了一种订单处理方法、装置、服务器、移动终端和存储介质，其中，网约车订单处理方法，适用于服务器，包括：接收至少两个司机终端对同一网约车订单的接单请求；根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；将与预设规则相关的接单失败提示信息发送至第一司机终端。通过本发明的技术方案，将接单失败提示信息发送到司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
Description
技术领域
本发明涉及智能交通技术领域，具体而言，涉及一种网约车订单处理方法、一种网约车订单处理装置、一种服务器、一种移动终端和一种计算机可读存储介质。
背景技术
随着移动互联网的发展，网约车也逐渐普及，网约车提高了用户出行的便捷性，成为主流的出行方式之一。
相关技术中，通常是服务器将乘客的订单派发出去，接收司机终端的接单请求，然后根据预设规则，确定抢单成功的司机终端，并将订单分配过去，而不会给抢单失败的司机终端推送相关信息，存在以下技术缺陷：
(1)抢单失败的司机不能获得抢单失败的客观原因，难以有针对性的提升自身的服务水平，不利于网约车服务水平的提升。
(2)抢单失败的司机不能获得抢单失败的客观原因，容易引发不满情绪，不利于司机群体的良性竞争。
发明内容
本发明旨在至少解决现有技术或相关技术中存在的技术问题之一。
为此，本发明的目的在于提供一种网约车订单处理方案，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
为了实现上述目的，本发明的第一方面的技术方案提供了一种网约车订单处理方法，适用于服务器，包括：接收至少两个司机终端对同一网约车订单的接单请求；根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；将与预设规则相关的接单失败提示信息发送至第一司机终端。
在该技术方案中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设规则可以包括筛选规则与抢单规则，筛选规则用于在接收到多个接单请求时，对司机终端进行初步筛选，抢单规则可以由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，抢单数据对比分析包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，优选地，接收至少两个司机终端对同一网约车订单的接单请求，具体包括：向多个司机终端发送接单指令；自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该技术方案中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一技术方案中，优选地，根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，具体包括：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该技术方案中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一技术方案中，优选地，在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端前，还包括：根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；根据司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定抢单规则。
在该技术方案中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一技术方案中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项，其中，数据对比分析为与第二司机终端的数据对比分析。
在该技术方案中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一技术方案中，优选地，还包括：接收任意一个第一司机终端发送的抢单失败咨询信息；解析抢单失败咨询信息中的预设关键词信息；生成预设关键词信息对应的反馈信息，并发送至任意一个第一司机终端。
在该技术方案中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
本发明的第二方面的技术方案提供了一种网约车订单处理方法，适用于司机终端，包括：向服务器发送接单请求；接收服务器反馈的接单失败提示信息；根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析、司机评价数据对比分析与地理位置数据对比分析中的至少一种，数据对比分析为与接单成功的司机终端的数据对比分析。
在该技术方案中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一技术方案中，优选地，还包括：在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息显示在司机终端的界面上。
在该技术方案中，通过在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，在闲时以信息卡片的形式显示，提升司机的阅读效率。
在上述任一技术方案中，优选地，在根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上之后，还包括：获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息；将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该技术方案中，通过获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
本发明的第三方面的技术方案提供了一种网约车订单处理装置，适用于服务器，包括：接收单元，用于接收至少两个司机终端对同一网约车订单的接单请求；确定单元，用于根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；发送单元，用于将与预设规则相关的接单失败提示信息发送至第一司机终端。
在该技术方案中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，可以包括筛选规则与抢单规则，筛选规则用于在接收到多个接单请求时，对司机终端进行初步筛选，抢单规则可以预设规则由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，接单失败提示信息包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，优选地，发送单元还用于：向多个司机终端发送接单指令；接收单元还用于：自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该技术方案中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一项技术方案中，优选地，确定单元还用于：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；确定单元还用于：根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该技术方案中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一技术方案中，优选地，确定单元还用于：根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；确定单元还用于：根据司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定抢单规则。
在该技术方案中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一技术方案中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项，其中，数据对比分析为与第二司机终端的数据对比分析。
在该技术方案中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一技术方案中，优选地，还包括：接收单元还用于：接收任意一个第一司机终端发送的抢单失败咨询信息；订单处理装置还包括：解析单元，用于解析抢单失败咨询信息中的预设关键词信息；生成单元，用于生成预设关键词信息对应的反馈信息，并发送至任意一个第一司机终端。
在该技术方案中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
本发明的第四方面的技术方案提供了一种网约车订单处理装置，适用于司机终端，包括：发送单元，用于向服务器发送接单请求；接收单元，用于接收服务器反馈的接单失败提示信息，显示单元，用于根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一种，数据对比分析为与接单成功的司机终端的数据对比分析。
在该技术方案中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一技术方案中，优选地，显示单元还用于在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在司机终端的界面上。
在该技术方案中，通过在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，在闲时以信息卡片的形式显示，提升司机的阅读效率。
在上述任一技术方案中，优选地，还包括：转换单元，用于获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息；所述发送单元还用于将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该技术方案中，通过获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
本发明的第五方面的技术方案提供了一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现本发明的第一方面的技术方案提出的任一项的网约车订单处理方法的步骤。
在该技术方案中，服务器的处理器执行计算机程序时实现本发明的第一方面的技术方案提出的任一项的网约车订单处理方法的步骤，或包括本发明的第三方面的技术方案提出的任一项的网约车订单处理装置，因此具有上述本发明的第一方面的技术方案提出的任一项的网约车订单处理方法的全部有益效果或上述本发明的第三方面的技术方案提出的任一项的网约车订单处理装置的全部有益效果，在此不再赘述。
本发明的第六方面的技术方案提供了一种移动终端，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现本发明的第二方面的技术方案提出的任一项的网约车订单处理方法的步骤，和/或包括本发明的第四方面的技术方案提出的任一项的网约车订单处理装置。
在该技术方案中，移动终端的处理器执行计算机程序时实现本发明的第二方面的技术方案提出的任一项的网约车订单处理方法的步骤，或包括本发明的第四方面的技术方案提出的任一项的网约车订单处理装置，因此具有上述本发明的第二方面的技术方案提出的任一项的网约车订单处理方法的全部有益效果或上述本发明的第四方面的技术方案提出的任一项的网约车订单处理装置的全部有益效果，在此不再赘述。
本发明的第七方面的技术方案提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现本发明的第一方面的技术方案和/或第二方面的技术方案提出的任一项的网约车订单处理方法。
在该技术方案中，计算机可读存储介质上存储的计算机程序被处理器执行时实现本发明的第一方面和/或第二方面技术方案提出的任一项的网约车订单处理方法，因此具有上述本发明的第一方面和/或第二方面技术方案提出的任一项的网约车订单处理方法的全部有益效果，在此不再赘述。
本发明的附加方面和优点将在下面的描述部分中给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。
附图说明
本发明的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：
图1示出了根据本发明的一个实施例的网约车订单处理方法的示意流程图；
图2示出了根据本发明的另一个实施例的网约车订单处理方法的示意流程图；
图3示出了根据本发明的一个实施例的网约车订单处理装置的示意框图；
图4示出了根据本发明的另一个实施例的网约车订单处理装置的示意框图；
图5示出了根据本发明的一个实施例的网约车订单处理方案移动终端的界面示意图；
图6示出了根据本发明的一个实施例的移动终端的示意框图。
具体实施方式
为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。
在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。
实施例一：
图1示出了根据本发明的一个实施例的网约车订单处理方法的示意流程图。
如图1所示，根据本发明的实施例的一种网约车订单处理方法，适用于服务器，包括：步骤S102，接收至少两个司机终端对同一网约车订单的接单请求；步骤S104，根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；步骤S106，将与预设规则相关的接单失败提示信息发送至第一司机终端。
在该实施例中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设规则可以包括筛选规则与抢单规则，筛选规则用于在接收到多个接单请求时，对司机终端进行初步筛选，抢单规则可以由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，接单失败提示信息包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
优选地，接收至少两个司机终端对同一网约车订单的接单请求，具体包括：向多个司机终端发送接单指令；自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该实施例中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一项实施例中，优选地，根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，具体包括：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该实施例中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一实施例中，优选地，在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端前，还包括：根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；根据司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定抢单规则。
在该实施例中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一实施例中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项，其中，数据对比分析为与第二司机终端的数据对比分析。
在该实施例中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一实施例中，优选地，还包括：接收任意一个第一司机终端发送的抢单失败咨询信息；解析抢单失败咨询信息中的预设关键词信息；生成预设关键词信息对应的反馈信息，并发送任意一个至第一司机终端。
在该实施例中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
实施例二：
图2示出了根据本发明的另一个实施例的网约车订单处理方法的示意流程图。
如图2所示，根据本发明的实施例的网约车订单处理方法，适用于司机终端，包括：步骤S202，向服务器发送接单请求；步骤S204，接收服务器反馈的接单失败提示信息；步骤S206，根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，数据对比分析为与接单成功的司机终端的数据对比分析
在该实施例中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述实施例中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；
地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一实施例中，优选地，还包括：根据预设的建议改进模块以及接单失败提示信息生成建议改进信息；在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息显示在司机终端的界面上。
在该实施例中，通过在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，在闲时以信息卡片的形式显示，提升司机的阅读效率。
在上述任一实施例中，优选地，在根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上之后，还包括：获取用户针对接单失败提示信息的操作指令，并将操作指令转换为抢单失败咨询信息；将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该实施例中，通过获取用户针对接单失败提示信息的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
实施例三：
图3示出了根据本发明的一个实施例的网约车订单处理装置300的示意框图。
如图3所示，根据本发明的一个实施例的网约车订单处理装置300，适用于服务器，包括：接收单元302，用于接收至少两个司机终端对同一网约车订单的接单请求；确定单元304，用于根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；发送单元306，用于将与预设规则相关的接单失败提示信息发送至第一司机终端。。
在该实施例中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设规则可以包括筛选规则与抢单规则，筛选规则用于在接收到多个接单请求时，对司机终端进行初步筛选，抢单规则可以由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，接单失败提示信息包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述实施例中，优选地，发送单元306还用于：向多个司机终端发送接单指令；接收单元302还用于：自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该技术方案中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一实施例中，优选地，确定单元304还用于：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；确定单元304还用于：根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该实施例中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一实施例中，优选地，确定单元304还用于：根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；确定单元304还用于：根据司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定抢单规则。
在该实施例中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一实施例中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项，其中，数据对比分析为与第二司机终端的数据对比分析。
在该实施例中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一实施例中，优选地，还包括：接收单元302还用于：接收任意一个第一司机终端发送的抢单失败咨询信息；订单处理装置300还包括：解析单元308，用于解析抢单失败咨询信息中的预设关键词信息；生成单元，用于310生成预设关键词信息对应的反馈信息，并发送至任意一个第一司机终端。
在该实施例中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
实施例四：
图4示出了根据本发明的另一个实施例的网约车订单处理装置400的示意框图。
如图4所示，根据本发明的一个实施例的网约车订单处理装置400，适用于司机终端，包括：发送单元402，用于向服务器发送接单请求；接收单元404，用于接收服务器反馈的接单失败提示信息，显示单元406，用于根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一种，数据对比分析为与接单成功的司机终端的数据对比分析。
在该实施例中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述实施例中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一实施例中，优选地，显示单元406还用于在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在司机终端的界面上。
在该技术方案中，通过在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，在闲时以信息卡片的形式显示，提升司机的阅读效率。
在上述任一实施例中，优选地，还包括：转换单元408，用于获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息；发送单元404还用于：将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该实施例中，通过获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
如图4所示，在上述任一实施例中，例如，确定单元402可以集成在微处理器中，接收单元404可以是接收天线，显示单元406可以是显示屏，转换单元408可以通过显示屏的触控功能与微处理器结合实现。
实施例五：
如图5所示，在抢单失败后，在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，其中，抢单失败原因为“近30天预约单完成率较低”，通过卡片的形式通知司机完成对比率“我，70％，陈师傅85％”，因此对方抢单成功，该卡片在“5s后自动关闭”。
以信息卡片的形式显示，提升司机的阅读效率。
服务器侧的实施例：
根据本发明的一个实施例的服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现本发明的实施例一提出的任一项的网约车订单处理方法的步骤。
其中，处理器执行计算机程序时实现以下步骤：接收至少两个司机终端对同一网约车订单的接单请求；根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；将与预设规则相关的接单失败提示信息发送至第一司机终端。
在该技术方案中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设规则可以包括筛选规则与抢单规则，筛选规则用于在接收到多个接单请求时，对司机终端进行初步筛选，抢单规则可以由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，接单失败提示信息包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，在上述技术方案中，优选地，接收至少两个司机终端对同一网约车订单的接单请求，具体包括：向多个司机终端发送接单指令；自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该技术方案中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一技术方案中，优选地，根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，具体包括：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该技术方案中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一技术方案中，优选地，在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端前，还包括：根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；根据司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定抢单规则。
在该技术方案中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一技术方案中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项，其中，数据对比分析为与第二司机终端的数据对比分析。
在该技术方案中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一技术方案中，优选地，还包括：接收任意一个第一司机终端发送的抢单失败咨询信息；解析抢单失败咨询信息中的预设关键词信息；生成预设关键词信息对应的反馈信息，并发送至任意一个第一司机终端。
在该技术方案中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
终端侧的实施例：
图6示出了根据本发明的一个实施例的移动终端600的示意框图。
如图6所示，根据本发明的一个实施例的移动终端600，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，处理器执行计算机程序时实现本发明的实施例二提出的任一项的网约车订单处理方法的步骤，和/或包括本发明的实施例四提出的任一项的网约车订单处理装置400。
其中，处理器执行计算机程序时实现以下步骤：向服务器发送接单请求；接收服务器反馈的接单失败提示信息；根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，数据对比分析为与接单成功的司机终端的数据对比分析
在该技术方案中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述技术方案中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；
地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一技术方案中，优选地，还包括：根据预设的建议改进模块以及接单失败提示信息生成建议改进信息；在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息显示在司机终端的界面上。
在该技术方案中，通过在检测到司机终端的工作状态为非载客状态或非接单状态时，将接单失败提示信息以信息卡片的形式显示在界面上，在闲时以信息卡片的形式显示，提升司机的阅读效率。
在上述任一技术方案中，优选地，在根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，还包括：获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息；将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该技术方案中，通过获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
计算机可读存储介质侧的实施例：
根据本发明的实施例的计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收至少两个司机终端对同一网约车订单的接单请求；根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，第一司机终端为接单请求失败的司机终端；将与预设规则相关的接单失败提示信息发送至第一司机终端。
在该实施例中，通过在在接收到至少两个司机终端的接单请求后，根据预设规则，确定至少一个第一司机终端，实现了对抢单成功和抢单失败的司机终端的确认，有利于为抢单失败的司机终端推送相应的提示信息，通过将接单失败提示信息发送至至少一个第一司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设规则由司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比确定，接单失败提示信息包括历史行程数据、司机评价数据和地理位置数据的对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述实施例中，优选地，接收至少两个司机终端对同一网约车订单的接单请求，具体包括：向多个司机终端发送接单指令；自发送接单指令时刻起计时的预设时间段内，接收至少两个司机终端发送的接单请求。
在该实施例中，通过向多个具有接单资格的司机发送接单指令，并在预设时间段内确定接收到的接单请求，实现了具有接单意向的多个司机终端的确定。
具体地，在预设时间段(比如3秒内等)内，不同司机通过平台发送接单请求，具体的，在需要抢单时，同时在多个司机的客户端界面显示抢单界面，以通过司机对界面的操控，确定是否发送接单请求。
在上述任一实施例中，优选地，根据预设规则，从至少两个司机终端中确定至少一个第一司机终端，具体包括：在接收到的接单请求的数量大于或等于3个时，根据预设规则中的筛选规则，分别确定接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有抢单权限的第一司机终端；根据预设规则中的抢单规则，在具有抢单权限的两个司机终端中，分别确定一个第一司机终端和一个第二司机终端，其中，第二司机终端为抢单成功的司机终端。
在该实施例中，通过在向多个司机终端发送接单指令后，确定自发送接单指令时刻起计时的预设时间段内接收到的接单请求对应的司机终端，有利于提高订单的处理效率，通过根据预设的筛选规则，确定具有抢单权限的至少两个司机终端，可以将对司机终端做出初步筛选，减少PK抢单操作的压力，进一步提高订单的处理效率，通过根据预设规则，在具有抢单权限的司机终端中，确定第一司机终端和第二司机终端，实现了对抢单成功和抢单失败的司机终端的确认，提高了订单分配的公平性和合理性。
在上述任一实施例中，优选地，根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则；根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则。
在该实施例中，通过根据司机终端的实时位置与载客点之间的至少一条路径和至少一条路径对应的实时路况确定筛选规则，可以对司机终端做出初步筛选，将不能在乘客要求的接驾时间内到达载客点的司机终端排除掉，可以降低PK抢单的混乱程度，有利于抢单规则的实现，提高PK抢单的效率，通过根据司机终端的历史行程数据、司机评价数据和地理位置数据和对应的权重比，确定抢单规则，提高了PK抢单的公平合理性，其中，司机评价数据占的权重较高，具体可以包括应答率、成交率、服务分，有利于选出服务水平相对高的司机来接单。
在上述任一实施例中，优选地，接单失败提示信息具体包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一项。
在该实施例中，接单失败提示信息根据抢单规则中的选择的数据来确定，具体包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，可以根据PK抢单的过程，将导致PK抢单失败的最主要的原因，推送给司机终端，有利于司机及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
在上述任一实施例中，优选地，还包括：接收任意一个第一司机终端发送的抢单失败咨询信息；解析抢单失败咨询信息中的预设关键词信息；生成预设关键词信息对应的反馈信息，并发送至第一司机终端。
在该实施例中，通过接收第一司机终端发送的抢单失败的咨询信息，并解析抢单失败咨询信息中的预设关键词信息，生成预设关键词信息对应的反馈信息，并发送至第一司机终端，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
和/或实现以下步骤：向服务器发送接单请求；接收服务器反馈的接单失败提示信息；根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上，其中，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析，数据对比分析为与接单成功的司机终端的数据对比分析。
在该实施例中，通过在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
其中，预设时长可以为2分钟，接单失败提示信息包括历史行程数据对比分析和/或司机评价数据对比分析和/或地理位置数据对比分析。比如接单失败提示信息为司机评价数据中的应答率远低于抢单成功的司机终端，司机可以针对性的提高应答率，再比如接单失败提示信息为历史行程数据中的历史行程路程远低于抢单成功的司机终端，司机可以针对性的多接单，再比如接单失败提示信息为地理位置数据中的司机终端的实时位置过远，司机可以在发送接单请求时，注意实时位置与载客点的距离，距离较远时，可以选择不发送接单请求，提高抢单的效率，减少不必要的时间浪费，同时也可以降低服务器的数据交互压力。
在上述实施例中，优选地，历史行程数据具体包括历史行程区域和历史行程距离的累积值；司机评价数据具体包括订单完成率、订单应答率和服务分；
地理位置数据具体包括司机终端的实时位置与载客点之间的行程距离和路况。
在上述任一实施例中，优选地，在检测到所述接单请求的响应时长大于或等于预设时长时，接收服务器反馈的接单失败提示信息之前，还包括：获取服务器发送的接单指令；获取用户针对接单指令的第一操作指令，并将第一操作指令转换为接单请求。
在该实施例中，通过获取服务器发送的接单指令后，获取用户针对接单指令的第一操作指令，并将第一操作指令转换为接单请求，实现了接单请求的发送，有利于订单分配的实现。
在上述任一实施例中，优选地，在根据接单失败提示信息生成接单失败提示卡片，并显示在司机终端的界面上之后，还包括：获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息；将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息。
在该实施例中，通过获取用户针对接单失败提示卡片上指定区域的操作指令，并将操作指令转换为抢单失败咨询信息，将抢单失败咨询信息发送至服务器，并获取服务器发送的反馈信息，实现了针对抢单失败原因的交互功能，可以进一步的帮助司机了解抢单失败的具体原因，有利于司机及时做出针对性的改进和调整，有利于进一步提高司机群体的运营水平，也有利于进一步提升网约车平台的服务水平。
以上结合附图详细说明了本发明的技术方案，本发明提出了一种网约车订单处理方法、装置、服务器、移动终端和存储介质，通过将接单失败提示信息发送至抢单失败的司机终端，有利于司机了解抢单失败的原因，及时做出针对性的改进和调整，有利于提高司机群体的运营水平，也有利于提升网约车平台的服务水平。
本发明方法中的步骤可根据实际需要进行顺序调整、合并和删减。
本发明装置中的单元可根据实际需要进行合并、划分和删减。
本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质包括只读存储器(Read-Only Memory，ROM)、随机存储器(Random Access Memory，RAM)、可编程只读存储器(Programmable Read-only Memory，PROM)、可擦除可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、一次可编程只读存储器(One-time Programmable Read-Only Memory，OTPROM)、电子抹除式可复写只读存储器(Electrically-Erasable Programmable Read-Only Memory，EEPROM)、只读光盘(CompactDisc Read-Only Memory，CD-ROM)或其他光盘存储器、磁盘存储器、磁带存储器、或者能够用于携带或存储数据的计算机可读的任何其他介质。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
Claims (21)
1.一种网约车订单处理方法，适用于服务器，其特征在于，包括：
接收至少两个司机终端对同一网约车订单的接单请求；
根据预设规则，从所述至少两个司机终端中确定至少一个第一司机终端，所述第一司机终端为接单请求失败的司机终端；
将与所述预设规则相关的接单失败提示信息发送至所述第一司机终端。
2.根据权利要求1所述的网约车订单处理方法，其特征在于，所述接收至少两个司机终端对同一网约车订单的接单请求，具体包括：
向多个司机终端发送所述同一网约车订单的接单指令；
自发送所述接单指令时刻起计时的预设时间段内，接收所述至少两个司机终端发送的所述接单请求。
3.根据权利要求1所述的网约车订单处理方法，其特征在于，所述根据预设规则，从所述至少两个司机终端中确定至少一个第一司机终端，具体包括：
在接收到的所述接单请求的数量大于或等于3个时，根据所述预设规则中的筛选规则，分别确定所述接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有所述抢单权限的所述第一司机终端；
根据所述预设规则中的抢单规则，在所述具有抢单权限的两个司机终端中，分别确定一个所述第一司机终端和一个第二司机终端，
其中，所述第二司机终端为抢单成功的司机终端。
4.根据权利要求3所述的网约车订单处理方法，其特征在于，所述在接收到的所述接单请求的数量大于或等于3个时，根据所述预设规则中的筛选规则，分别确定所述接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有所述抢单权限的所述第一司机终端前，还包括：
根据所述司机终端的实时位置与载客点之间的至少一条路径和所述至少一条路径对应的实时路况确定所述筛选规则；
根据所述司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定所述抢单规则。
5.根据权利要求3所述的网约车订单处理方法，其特征在于，
所述接单失败提示信息具体包括所述历史行程数据对比分析、所述司机评价数据对比分析以及所述地理位置数据对比分析中的至少一项，
其中，所述数据对比分析为与所述第二司机终端的数据对比分析。
6.根据权利要求1至5中任一项所述的网约车订单处理方法，其特征在于，还包括：
接收任意一个所述第一司机终端发送的抢单失败咨询信息；
解析所述抢单失败咨询信息中的预设关键词信息；
生成所述预设关键词信息对应的反馈信息，并发送至任意一个所述第一司机终端。
7.一种网约车订单处理方法，适用于司机终端，其特征在于，包括：
向服务器发送接单请求；
接收所述服务器反馈的接单失败提示信息；
根据所述接单失败提示信息生成接单失败提示卡片，并显示在所述司机终端的界面上，
其中，所述接单失败提示信息包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一种，所述数据对比分析为与接单成功的司机终端的数据对比分析。
8.根据权利要求7所述的网约车订单处理方法，其特征在于，
所述历史行程数据具体包括历史行程区域和历史行程距离的累积值；
所述司机评价数据具体包括订单完成率、订单应答率和服务分；
所述地理位置数据具体包括所述司机终端的实时位置与载客点之间的行程距离和路况。
9.根据权利要求7所述的网约车订单处理方法，其特征在于，所述在根据所述接单失败提示信息生成接单失败提示卡片，并显示在所述司机终端的界面上之后，还包括：
获取用户针对所述接单失败提示卡片上指定区域的操作指令，并将所述操作指令转换为抢单失败咨询信息；
将所述抢单失败咨询信息发送至所述服务器，以接收所述服务器发送的反馈信息。
10.一种网约车订单处理装置，适用于服务器，其特征在于，包括：
接收单元，用于接收至少两个司机终端对同一网约车订单的接单请求；
确定单元，用于根据预设规则，从所述至少两个司机终端中确定至少一个第一司机终端，所述第一司机终端为接单请求失败的司机终端；
发送单元，用于将与所述预设规则相关的接单失败提示信息发送至所述第一司机终端。
11.根据权利要求10所述的网约车订单处理装置，其特征在于，
所述发送单元还用于：向多个司机终端发送所述同一网约车订单的接单指令；
所述接收单元还用于：自发送所述接单指令时刻起计时的预设时间段内，接收所述至少两个司机终端发送的所述接单请求。
12.根据权利要求10所述的网约车订单处理装置，其特征在于，
所述确定单元还用于：在接收到的所述接单请求的数量大于或等于3个时，根据所述预设规则中的筛选规则，分别确定所述接单请求对应的司机终端中具有抢单权限的两个司机终端以及不具有所述抢单权限的所述第一司机终端；
所述确定单元还用于：根据所述预设规则中的抢单规则，在所述具有抢单权限的两个司机终端中，分别确定一个所述第一司机终端和一个第二司机终端，
其中，所述第二司机终端为抢单成功的司机终端。
13.根据权利要求12所述的网约车订单处理装置，其特征在于，
所述确定单元还用于：根据所述司机终端的实时位置与载客点之间的至少一条路径和所述至少一条路径对应的实时路况确定所述筛选规则；
所述确定单元还用于：根据所述司机终端的历史行程数据、司机评价数据、地理位置数据和对应的权重比，确定所述抢单规则。
14.根据权利要求12所述的网约车订单处理装置，其特征在于，
所述接单失败提示信息具体包括所述历史行程数据对比分析、所述司机评价数据对比分析以及所述地理位置数据对比分析中的至少一项，
其中，所述数据对比分析为与所述第二司机终端的数据对比分析。
15.根据权利要求10至14中任一项所述的网约车订单处理装置，其特征在于，还包括：
所述接收单元还用于接收任意一个所述第一司机终端发送的抢单失败咨询信息；
所述订单处理装置还包括：
解析单元，用于解析所述抢单失败咨询信息中的预设关键词信息；
生成单元：用于生成所述预设关键词信息对应的反馈信息，并发送至任意一个所述第一司机终端。
16.一种网约车订单处理装置，适用于司机终端，其特征在于，包括：
发送单元，用于向服务器发送接单请求；
接收单元，用于接收所述服务器反馈的接单失败提示信息；
显示单元，用于根据所述接单失败提示信息生成接单失败提示卡片，并显示在所述司机终端的界面上，
其中，所述接单失败提示信息包括历史行程数据对比分析、司机评价数据对比分析以及地理位置数据对比分析中的至少一种，所述数据对比分析为与接单成功的司机终端的数据对比分析。
17.根据权利要求16所述的网约车订单处理装置，其特征在于，
所述历史行程数据具体包括历史行程区域和历史行程距离的累积值；
所述司机评价数据具体包括订单完成率、订单应答率和服务分；
所述地理位置数据具体包括所述司机终端的实时位置与载客点之间的行程距离和路况。
18.根据权利要求16所述的网约车订单处理装置，其特征在于，还包括：
转换单元，用于获取用户针对所述接单失败提示卡片上指定区域的操作指令，并将所述操作指令转换为抢单失败咨询信息；
所述发送单元还用于：将所述抢单失败咨询信息发送至所述服务器，并接收所述服务器发送的反馈信息。
19.一种服务器，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求1至6中任一项所述的网约车订单处理方法的步骤。
20.一种移动终端，其特征在于，包括存储器、处理器及存储在所述存储器上并可在所述处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现如权利要求7至9中任一项所述的网约车订单处理方法的步骤，和/或包括如权利要求16至18中任一项所述的网约车订单处理装置。
21.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1至9中任一项所述的网约车订单处理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710585026.0A CN109272368A (zh) | 2017-07-18 | 2017-07-18 | 订单处理方法、装置、服务器、移动终端和存储介质 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201710585026.0A CN109272368A (zh) | 2017-07-18 | 2017-07-18 | 订单处理方法、装置、服务器、移动终端和存储介质 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN109272368A true CN109272368A (zh) | 2019-01-25 |
Family
ID=65152419
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201710585026.0A Pending CN109272368A (zh) | 2017-07-18 | 2017-07-18 | 订单处理方法、装置、服务器、移动终端和存储介质 |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109272368A (zh) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110020923A (zh) * | 2019-04-12 | 2019-07-16 | 北京嘀嘀无限科技发展有限公司 | 订单匹配方法及系统、计算机可读存储介质、电子设备 |
| CN110458487A (zh) * | 2019-07-02 | 2019-11-15 | 天津五八到家科技有限公司 | 货运数据处理方法、设备及存储介质 |
| CN112070570A (zh) * | 2020-07-17 | 2020-12-11 | 盛威时代科技集团有限公司 | 智能化的司机端网约车操作方法 |
| CN113361910A (zh) * | 2021-06-04 | 2021-09-07 | 哈尔滨商业大学 | 任务完成质量的评价方法及装置、电子设备和存储介质 |
Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN201181988Y (zh) * | 2008-03-31 | 2009-01-14 | 杭州义盛祥通信技术有限公司 | 出租车即时呼叫分派管理系统 |
| CN101520950A (zh) * | 2008-03-31 | 2009-09-02 | 杭州义盛祥通信技术有限公司 | 出租车即时呼叫分派管理系统及呼叫分派管理方法 |
| CN103996290A (zh) * | 2014-06-09 | 2014-08-20 | 北京东方车云信息技术有限公司 | 一种提供叫车服务的方法、服务器及系统 |
| CN104183118A (zh) * | 2014-08-19 | 2014-12-03 | 北京嘀嘀无限科技发展有限公司 | 基于拍卖模式获得乘客最优接驾司机的派单系统 |
| CN204528270U (zh) * | 2015-03-04 | 2015-08-05 | 郑州西普德节能科技股份有限公司 | 一种基于互联网的区域滴滴打车环保终端 |
| CN105005816A (zh) * | 2015-04-13 | 2015-10-28 | 北京嘀嘀无限科技发展有限公司 | 订单处理方法及装置 |
| CN105956908A (zh) * | 2016-05-13 | 2016-09-21 | 深圳市永兴元科技有限公司 | 订单分配方法及系统 |
| CN106204220A (zh) * | 2016-07-13 | 2016-12-07 | 深圳市拓源天创实业发展有限公司 | 一种订单自动分配方法及系统 |
| CN106254360A (zh) * | 2016-08-12 | 2016-12-21 | 北京东方车云信息技术有限公司 | 出车中接单失败原因分析方法、服务端及接单失败司机端 |
| CN106296086A (zh) * | 2016-08-04 | 2017-01-04 | 温泉 | 一种商家参与配送员抢单的方法及系统 |
| CN106373387A (zh) * | 2016-10-25 | 2017-02-01 | 先锋智道（北京）科技有限公司 | 一种车辆调度方法、装置及系统 |
-
2017
- 2017-07-18 CN CN201710585026.0A patent/CN109272368A/zh active Pending
Patent Citations (11)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN201181988Y (zh) * | 2008-03-31 | 2009-01-14 | 杭州义盛祥通信技术有限公司 | 出租车即时呼叫分派管理系统 |
| CN101520950A (zh) * | 2008-03-31 | 2009-09-02 | 杭州义盛祥通信技术有限公司 | 出租车即时呼叫分派管理系统及呼叫分派管理方法 |
| CN103996290A (zh) * | 2014-06-09 | 2014-08-20 | 北京东方车云信息技术有限公司 | 一种提供叫车服务的方法、服务器及系统 |
| CN104183118A (zh) * | 2014-08-19 | 2014-12-03 | 北京嘀嘀无限科技发展有限公司 | 基于拍卖模式获得乘客最优接驾司机的派单系统 |
| CN204528270U (zh) * | 2015-03-04 | 2015-08-05 | 郑州西普德节能科技股份有限公司 | 一种基于互联网的区域滴滴打车环保终端 |
| CN105005816A (zh) * | 2015-04-13 | 2015-10-28 | 北京嘀嘀无限科技发展有限公司 | 订单处理方法及装置 |
| CN105956908A (zh) * | 2016-05-13 | 2016-09-21 | 深圳市永兴元科技有限公司 | 订单分配方法及系统 |
| CN106204220A (zh) * | 2016-07-13 | 2016-12-07 | 深圳市拓源天创实业发展有限公司 | 一种订单自动分配方法及系统 |
| CN106296086A (zh) * | 2016-08-04 | 2017-01-04 | 温泉 | 一种商家参与配送员抢单的方法及系统 |
| CN106254360A (zh) * | 2016-08-12 | 2016-12-21 | 北京东方车云信息技术有限公司 | 出车中接单失败原因分析方法、服务端及接单失败司机端 |
| CN106373387A (zh) * | 2016-10-25 | 2017-02-01 | 先锋智道（北京）科技有限公司 | 一种车辆调度方法、装置及系统 |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN110020923A (zh) * | 2019-04-12 | 2019-07-16 | 北京嘀嘀无限科技发展有限公司 | 订单匹配方法及系统、计算机可读存储介质、电子设备 |
| WO2020207065A1 (zh) * | 2019-04-12 | 2020-10-15 | 北京嘀嘀无限科技发展有限公司 | 订单匹配方法及系统、计算机可读存储介质、电子设备 |
| CN110458487A (zh) * | 2019-07-02 | 2019-11-15 | 天津五八到家科技有限公司 | 货运数据处理方法、设备及存储介质 |
| CN112070570A (zh) * | 2020-07-17 | 2020-12-11 | 盛威时代科技集团有限公司 | 智能化的司机端网约车操作方法 |
| CN112070570B (zh) * | 2020-07-17 | 2023-11-07 | 盛威时代科技集团有限公司 | 智能化的司机端网约车操作方法 |
| CN113361910A (zh) * | 2021-06-04 | 2021-09-07 | 哈尔滨商业大学 | 任务完成质量的评价方法及装置、电子设备和存储介质 |
| CN113361910B (zh) * | 2021-06-04 | 2023-08-25 | 哈尔滨商业大学 | 任务完成质量的评价方法及装置、电子设备和存储介质 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN109272368A (zh) | 订单处理方法、装置、服务器、移动终端和存储介质 | |
| US7376495B2 (en) | Fuel information messaging system | |
| CN108765741A (zh) | 一种基于云端的加油管理方法、装置及服务器 | |
| US20050267673A1 (en) | Multiple fueler operations for fuel information messaging system | |
| CN110704083B (zh) | 一种汽车在线升级方法、装置、系统及可读存储介质 | |
| CN109840987A (zh) | 加油信息推送方法及装置 | |
| US9863392B1 (en) | Systems and methods for providing driving insurance for an individual driver | |
| CN108230044A (zh) | 评价方法和评价装置 | |
| CN106355762A (zh) | 一种自助支付的加油方法及装置 | |
| CN110782588B (zh) | 一种信息提示方法、服务器和可读存储介质 | |
| CN105760990A (zh) | 一种客票变更系统和方法 | |
| CN107182042A (zh) | 短信通道质量评估方法、装置、介质和系统 | |
| KR20200117799A (ko) | 대여용 차량의 운용 기록 관리 장치 및 방법 | |
| CN111539715B (zh) | 车辆电子标签支付生成方法 | |
| CN109544976A (zh) | 基于app的云智能共享停车系统及方法 | |
| CN108376429A (zh) | 停车场管理方法、停车场管理装置以及可读存储介质 | |
| CN108009406A (zh) | 一种账号冻结方法、账号解冻方法及服务器 | |
| CN106297016A (zh) | 一种用于无人智能加油站管理的控制系统 | |
| CN108447532A (zh) | 一种医疗信息管理方法、电子设备、存储介质及系统 | |
| US20220156397A1 (en) | Business official email box based b2b service security verification method, apparatus, and server | |
| CN108689379B (zh) | 一种加油信息同步的方法、移动终端及装置 | |
| CN106203993A (zh) | 一种支付方法及相关设备 | |
| CN113837580B (zh) | 一种实验设备管理系统、方法及其计算机装置 | |
| CN110543498A (zh) | 一种基于事件触发的多方数据关联查询方法和装置 | |
| CN105913247A (zh) | 一种esim卡的空间管理方法及装置 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20190125 |
|
| RJ01 | Rejection of invention patent application after publication |