网约车服务评价方法及系统、以及派单方法
技术领域
本发明涉及通信技术领域,尤其涉及一种网约车服务评价方法及系统、以及派单方法。
背景技术
近年来,随着网约车的日益普及,通过网络平台预约车辆出行成为人们主要的出行方式之一,使得人们出行的便利性得到了很大的改善。但是,网约车在方便人们出行的同时,也存在一定的问题。其一,乘客对网约车驾驶员的身体状况、驾驶行为倾向、是否存在路怒情绪等并不知情。其二,乘客在预约平台上下单,并没有选择网约车驾驶员的权利,只能被动接受。
因此,对网约车驾驶员驾驶行为的评价和类别划分、以及给予乘客选择权对网约车行业的发展具有重要意义。
发明内容
本发明提供了一种网约车服务评价方法及系统、以及派单方法,能够有效形成对网约车驾驶员的综合评价。
第一方面,本发明实施例提供一种网约车服务评价方法,所述网约车服务评价方法包括:
接收设置于网约车的氛围监控设备发送的氛围值;
根据所述氛围值形成智能评价标签;
获取双向评价标签;
获取乘客评价信息;以及
根据所述智能评价标签、所述双向评价标签、以及所述乘客评价信息形成综合评价结果。
第二方面,本发明实施例提供一种网约车服务评价系统,所述网约车服务评价系统包括氛围监控设备、以及与所述氛围监控设备电连接的主控制设备,所述主控制设备包括处理器、以及存储器,所述存储器用于存储网约车服务评价程序指令,所述处理器用于执行所述网约车服务评价程序指令以实现如上所述的网约车服务评价方法。
第三方面,本发明实施例提供了一种基于网约车服务评价方法的派单方法,所述派单方法包括:
接收来自乘客端的订单;
随机将若干根据如上所述的网约车服务评价方法所形成的综合评价结果推送至所述乘客端;
将与所述综合评价结果相对应的自定义评价标签或人设标签推送至所述乘客端;
获取所述乘客端的选择标签,其中,所述选择标签从所述自定义评价标签或所述人设标签中选择形成;以及
将所述订单派送给与所述选择标签相匹配的驾驶员。
第四方面,本发明实施例提供了一种基于网约车服务评价方法的派单方法,所述派单方法包括:
接收来自乘客端的订单;
获取所述乘客端的偏好标签;
获取根据如上所述的网约车服务评价方法所形成的综合评价结果;
根据所述偏好标签匹配所述综合评价结果中的自定义评价标签或人设标签;
根据匹配结果将相对应的驾驶员按所述综合评价结果进行排序;以及
根据所述排序结果和系统派单规则将所述订单派送给匹配的所述驾驶员。
上述网约车服务评价方法及系统、以及派单方法,利用氛围监控设备获取氛围值,根据氛围值形成智能评价标签,综合智能评价标签、双向评价标签、以及乘客评价信息形成综合评价结果,通过不同维度的数据,能够有效形成对网约车驾驶员的综合评价。同时,最终形成的综合评价结果具有高度的真实性。
附图说明
为了更清楚地说明本发明实施例或现有技术中的技术方案,下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍,显而易见地,下面描述中的附图仅仅是本发明的一些实施例,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图示出的结构获得其他的附图。
图1为本发明实施例提供的网约车服务评价方法的流程图。
图2为本发明实施例提供的网约车服务评价方法的第一子流程图。
图3为本发明实施例提供的网约车服务评价方法的第二子流程图。
图4为本发明实施例提供的网约车服务评价方法的第三子流程图。
图5为本发明第一实施例提供的派单方法。
图6为本发明第二实施例提供的派单方法。
图7为本发明实施例提供的网约车服务评价方法的应用场景示意图。
图8为本发明实施例提供的网约车服务评价系统的结构示意图。
元件符号说明
标号 名称 标号 名称
1000 网约车服务评价系统 20 氛围监控设备
99 网约车 30 驾驶员端
10 主控制设备 40 乘客端
11 处理器 A 驾驶员
12 存储器 B 乘客
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”、“第四”等(如果存在)是用于区别类似的对象,而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换,换句话说,描述的实施例根据除了这里图示或描述的内容以外的顺序实施。此外,术语“包括”和“具有”以及他们的任何变形,还可以包含其他内容,例如,包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于只清楚地列出的那些步骤或单元,而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
需要说明的是,在本发明中涉及“第一”、“第二”等的描述仅用于描述目的,而不能理解为指示或暗示其相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者多个该特征。另外,各个实施例之间的技术方案可以相互结合,但是必须是以本领域普通技术人员能够实现为基础,当技术方案的结合出现相互矛盾或无法实现时应当认为这种技术方案的结合不存在,也不在本发明要求的保护范围之内。
请结合参看图1和图7,其为本发明实施例提供的网约车服务评价方法的流程图、以及应用场景示意图。网约车服务评价方法包括但不限于用于对网约车驾驶员的服务质量、专业性等进行评价。在当前场景中,网约车99上包括驾驶员A和乘客B两个人。下文将以此场景为例进行详细描述。网约车服务评价方法具体包括如下步骤。
步骤S102,接收设置于网约车的氛围监控设备发送的氛围值。具体地,本方法利用主控制设备10接收氛围监控设备20发送的氛围值。在本实施例中,氛围监控设备20设置于网约车99内。其中,氛围监控设备20用于监控网约车99内驾驶员A与乘客B之间的沟通氛围并形成相应的氛围值。具体地,氛围监控设备20获取驾驶员A与乘客B之间的沟通数据,其中,沟通数据包括但不限于行为数据、生理数据、以及环境数据等。行为数据包括但不限于驾驶员A和乘客B的面部表情、肢体动作、沟通内容、语气、语调等;生理数据包括但不限于驾驶员A和乘客B的心率、体温、呼吸频率等;环境数据包括但不限于温度、湿度等。氛围监控设备20将沟通数据输入至量化模型中,量化模型对沟通数据进行量化并输出相应的氛围值。氛围监控设备20获取氛围值,并将氛围值发送至主控制设备10。氛围值用于表示驾驶员A与乘客B之间的沟通情况。在本实施例中,氛围值越高说明沟通氛围越差,驾驶员A与乘客B在沟通过程中可能出现纠纷、冲突等。氛围值适中说明沟通氛围良好。氛围值越低说明沟通氛围较差,驾驶员A与乘客B可能处于“尬聊”或者没有交流的状态。在一些可行的实施例中,可以是氛围值越低沟通氛围越差,氛围值越高沟通氛围越好。当然,氛围值与沟通情况之间的关系也可以根据实际情况进行设置,在此不做限定。
步骤S104,根据氛围值形成智能评价标签。具体地,本方法利用主控制设备10根据氛围值形成智能评价标签。在本实施例中,主控制设备10先将氛围值输入分析系统中,并获取分析结果。主控制设备10再根据分析结果形成智能评价标签。其中,分析系统可以根据氛围值的具体数据自动分析识别驾驶员A的服务质量、以及存在的问题等,并形成相应的分析结果。主控制设备10根据分析结果自动与评价标签进行匹配,选取与分析结果相匹配的评价标签作为智能评价标签。
步骤S106,获取双向评价标签。具体地,本方法利用主控制设备10获取双向评价标签。其中,双向评价标签通过驾驶员A和乘客B共同形成。双向评价标签的具体形成方式将在下文进行详细描述。
步骤S108,获取乘客评价信息。具体地,本方法利用主控制设备10获取乘客评价信息。其中,乘客评价信息由乘客B通过乘客端40形成。乘客B可以根据自己的乘车感受、以及对驾驶员A的印象等在乘客端40输入相应的评价信息。其中,乘客端40可以为手机、智能手表、平板电脑等电子设备,在此不做限定。
步骤S110,根据智能评价标签、双向评价标签、以及乘客评价信息形成综合评价结果。具体地,本方法利用主控制设备10根据智能评价标签、双向评价标签、以及乘客评价信息形成综合评价结果。其中,综合评价结果可以根据自定义算法进行计算形成。即是说,将智能评价标签、双向评价标签、以及乘客评价信息输入自定义算法中,自定义算法即可输出相应的综合评价结果。在本实施例中,主控制设备10根据智能评价标签、双向评价标签、以及乘客评价信息的重要程度赋予相应的权重,并根据权重进行计算,从而形成综合评价结果。形成综合评价结果之后,主控制设备10将综合评价结果推送至乘客端40,以供乘客B查看。
上述实施例中,利用氛围监控设备监控网约车内驾驶员与乘客之间的沟通氛围形成氛围值,根据氛围值形成智能评价标签,综合智能评价标签、双向评价标签、以及乘客评价信息形成综合评价结果,通过不同维度的数据,能够有效形成对驾驶员的综合评价。由于智能评价标签是根据氛围值形成的,是基于真实的沟通数据分析形成的,因此有效规避了评价的不真实性、以及失效性,使得最终形成的综合评价结果具有较高的可信度。
请结合参看图3,执行步骤S106之前,网约车服务评价方法还包括如下步骤。
步骤S1052,获取驾驶员端的自定义评价标签。具体地,本方法利用主控制设备10获取驾驶员端30的自定义评价标签。其中,自定义评价标签由驾驶员A通过驾驶员端30自定义形成。驾驶员A可以根据自己的个性、特长等,自定义与自己适配的专属标签,即自定义评价标签。举例来说,驾驶员A可以为自己设置“暖男”、“段子手”、“美食控”、“地理通”等自定义评价标签。在当前场景中,驾驶员A通过驾驶员端30为自己设置的自定义评价标签为“路路通”,表示自己对道路交通非常熟悉。其中,驾驶员端30可以为手机、智能手表、平板电脑等电子设备,在此不做限定。
步骤S1054,将自定义评价标签和若干随机标签推送给乘客端。具体地,本方法利用主控制设备10将自定义评价标签和若干随机标签推送给乘客端40。其中,随机标签为主控制设备10自动随机生成的标签,随机标签可以与自定义评价标签相同,也可以与自定义评价标签不同。当随机标签与自定义评价标签相同时,选取自定义评价标签推送给乘客端40。自定义评价标签和随机标签用于供乘客B选择以形成服务评价标签。在本实施例中,当驾驶员A将乘客B送至指定地点,结束行程后,主控制设备10会将自定义评价标签和随机标签推送至乘客端40。在当前场景中,结束行程后,主控制设备10自动生成的随机标签包括“暖男”、“幽默”、以及“沉稳”。则,主控制设备10将“暖男”、“幽默”、“沉稳”、以及“路路通”推送至乘客端40。
请结合参看图4,步骤S106具体包括如下步骤。
步骤S1062,接收来自乘客端的服务评价标签。具体地,本方法利用主控制设备10接收来自乘客端40的服务评价标签。其中,服务评价标签由乘客B通过乘客端40从自定义评价标签和随机标签中选取,或者服务评价标签由乘客自定义形成。举例来说,乘客B根据自己的感受在自定义标签和随机标签中选取用于评价驾驶员A的标签作为服务评价标签。当乘客B认为自定义评价标签和随机标签中均没有符合用于评价驾驶员A的标签时,乘客B可以通过乘客端40输入符合驾驶员A的标签作为服务评价标签。在一些可行的实施例中,乘客B可以在自定义标签和随机标签中选取用于评价驾驶员A的标签作为服务评价标签,还可以通过乘客端40输入其它标签作为服务评价标签,在此不做限定。在当前场景中,乘客B在“暖男”、“幽默”、“沉稳”、以及“路路通”四个标签中选取“路路通”作为服务评价标签。
步骤S1064,判断服务评价标签与自定义评价标签是否相同。具体地,本方法利用主控制设备10判断服务评价标签与自定义评价标签是否相同。
步骤S1066,当服务评价标签与自定义评价标签相同时,将服务评价标签或自定义评价标签标记为双向评价标签。具体地,当服务评价标签与自定义评价标签相同时,本方法利用主控制设备10将服务评价标签或自定义评价标签标记为双向评价标签。当服务评价标签与自定义评价标签相同时,表示驾驶员A对自己的评价、以及乘客B对驾驶员A的评价相同。即是说,双向评价标签为驾驶员A与乘客B均认可的评价标签。在当前场景中,由于乘客B选取了“路路通”作为服务评价标签,驾驶员A的自定义评价标签也为“路路通”,则“路路通”为双向评价标签。
上述实施例中,通过增加驾驶员自定义评价标签,拓展了原有单一的评价体系,使得最终形成的综合评价结果更加多元化。此外,乘客能够通过乘客端进行即时评价,还能够自定义形成服务评价标签,使得评价方法更加开放。
请结合参看图2,执行步骤S1066之后,网约车服务评价方法还包括如下步骤。
步骤S202,记录双向评价标签的标记次数。具体地,本方法利用主控制设备10记录双向评价标签的标记次数。
步骤S204,判断标记次数是否达到预设值。具体地,本方法利用主控制设备10判断标记次数是否达到预设值。其中,预设值可以根据实际情况进行设定。当标记次数达到预设值时,执行步骤S206。当标记次数没有达到预设值时,执行步骤S208。
步骤S206,将双向评价标签标记为驾驶员的人设标签。具体地,本方法利用主控制设备10将双向评价标签标记为驾驶员A的人设标签。即是说,当驾驶员A的自定义评价标签被乘客B认可时,乘客B会选择相同的标签作为服务评价标签,当驾驶员A的自定义评价标签被乘客B认可达到一定的次数,即预设值后,驾驶员A的自定义评价标签,即双向评价标签就会变成驾驶员A的人设标签。在当前应用场景中,若驾驶员A的自定义评价标签“路路通”与乘客B的服务评价标签相同次数达到预设值,则“路路通”为驾驶员A的人设标签。
步骤S208,将标记次数和预设值推送至乘客端。具体地,本方法利用主控制设备10将标记次数和预设值推送至乘客端40。其中,主控制设备10可以但不限于通过进度条或者比值等方式将标记次数和预设值推送至乘客端。举例来说,若预设值为50,当前标记次数为45,则主控制设备10可以将45/50这个数值推送至乘客端。
上述实施例中,驾驶员的人设标签只有经过乘客达到一定次数的认可后,才能正式成为人设标签,能够实现对驾驶员的正向激励。通过进度条或者比值等方式将标记次数和预设值推送至乘客端,可以形象地告知乘客该驾驶员的评价情况,还能够对驾驶员的成长进行相应的规划。此外,形成的综合评价结果还能够与驾驶员的考核、派单等挂钩。
请结合参看图5,其为本发明第一实施例提供的派单方法的流程图。第一实施例提供的派单方法基于上述实施例所述的网约车服务评价方法形成。第一实施例提供的派单方法具体包括如下步骤。
步骤S302,接收来自乘客端的订单。具体地,本方法接收来自乘客端40的订单。其中,乘客B通过乘客端40形成订单。
步骤S304,随机将若干综合评价结果推送至乘客端。具体地,本方法随机将若干综合评价结果推送至乘客端40。其中,综合评价结果根据上述实施例的网约车服务评价方法形成。
步骤S306,将与综合评价结果相对应的自定义评价标签或人设标签推送至乘客端。具体地,本方法将与综合评价结果相对应的自定义评价标签或人设标签推送至乘客端40。在本实施例中,当与综合评价结果相对应的驾驶员A具有人设标签时,优先将驾驶员A的人设标签推送至乘客端40。当与综合评价结果相对应的驾驶员A还没有专属的人设标签时,将驾驶员A的自定义评价标签推送至乘客端40。在一些可行的实施例中,将自定义评价标签推送至乘客端40时,可以同时将相应的标记次数和预设值推送至乘客端40。
步骤S308,获取乘客端的选择标签。具体地,本方法获取乘客端40的选择标签。其中,选择标签从自定义评价标签或人设标签中选择形成。在本实施例中,乘客B可以根据自己的喜好对推送至乘客端40的自定义评价标签或人设标签进行选择,从而形成选择标签。
步骤S310,将订单派送给与选择标签相匹配的驾驶员。具体地,本方法将订单派送给与选择标签相匹配的驾驶员A,即,将订单派送至驾驶员端30。
请结合参看图6,其为本发明第二实施例提供的派单方法的流程图。第二实施例提供的派单方法基于上述实施例所述的网约车服务评价方法形成。第二实施例提供的派单方法具体包括如下步骤。
步骤S402,接收来自乘客端的订单。具体地,本方法接收来自乘客端40的订单。
步骤S404,获取乘客端的偏好标签。具体地,本方法获取乘客端40的偏好标签。在本实施例中,当乘客B在乘客端40注册时便根据自己的喜好设置好相应的偏好标签。在一些可行的实施例中,乘客B可以在每次登录乘客端40时设置相应的偏好标签,乘客B也可以在形成订单后再进行偏好标签的设置,在此不做限定。
步骤S406,获取综合评价结果。具体地,本方法获取综合评价结果。其中,综合评价结果根据上述实施例的网约车服务评价方法形成。
步骤S408,根据偏好标签匹配综合评价结果中的自定义评价标签或人设标签。具体地,本方法根据偏好标签匹配综合评价结果中的自定义评价标签或人设标签。即是说,本方法在综合评价结果中选取与偏好标签相匹配的自定义评价标签或人设标签。
步骤S410,根据匹配结果将相对应的驾驶员按综合评价结果进行排序。具体地,本方法根据匹配结果将相对应的驾驶员A按综合评价结果进行排序。
步骤S412,根据排序结果和系统派单规则将订单派送给匹配的驾驶员。具体地,本方法根据排序结果和系统派单规则将订单派送给匹配的驾驶员A。在本实施例中,系统派单规则包括但不限于在排序结果相同的情况下优先派单给距离乘客B较近的驾驶员A。
上述实施例中,基于驾驶员的人设标签,乘客在下单时能够实现个性化的选择,实现根据乘客自己的需求选择相应的驾驶员。本方法可以根据乘客的选择结合系统派单规则进行针对性派单,实现差异化服务,实现专属定制化服务,提升服务水平的同时实现派单业务模式的创新。同时,由于将评价和驾驶员的综合服务能力结合,将乘客评价和自主选择结合,使得驾驶员和乘客双方都有意愿和动力进行评价。
请结合参看图8,其为本发明实施例提供的网约车服务评价系统的结构示意图。网约车服务评价系统1000包括氛围监控设备20、以及与氛围监控设备20电连接的主控制设备10。主控制设备10包括处理器11、以及存储器12。存储器12用于存储网约车服务评价程序指令,处理器11用于执行网约车服务评价程序指令以实现网约车服务评价方法。
其中,处理器11在一些实施例中可以是一中央处理器(Central ProcessingUnit,CPU)、控制器、微控制器、微处理器或其它数据处理芯片,用于运行存储器12中存储的网约车服务评价程序指令。
存储器12至少包括一种类型的可读存储介质,该可读存储介质包括闪存、硬盘、多媒体卡、卡型存储器(例如,SD或DX存储器等)、磁性存储器、磁盘、光盘等。存储器12在一些实施例中可以是计算机设备的内部存储单元,例如计算机设备的硬盘。存储器12在另一些实施例中也可以是外部计算机设备的存储设备,例如计算机设备上配备的插接式硬盘,智能存储卡(Smart Media Card,SMC),安全数字(Secure Digital,SD)卡,闪存卡(FlashCard)等。进一步地,存储器12还可以既包括计算机设备的内部存储单元也包括外部存储设备。存储器12不仅可以用于存储安装于计算机设备的应用软件及各类数据,例如实现沟通网约车服务评价方法的代码等,还可以用于暂时地存储已经输出或者将要输出的数据。
在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。
该计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行该计算机程序指令时,全部或部分地产生按照本发明实施例的流程或功能。该计算机设备可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。该计算机指令可以存储在计算机可读存储介质中,或者从一个计算机可读存储介质向另一计算机可读存储介质传输,例如,该计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。该计算机可读存储介质可以是计算机能够存储的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。该可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如固态硬盘Solid State Disk(SSD))等。
所属领域的技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的系统,装置和单元的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再赘述。
在本申请所提供的几个实施例中,应该理解到,所揭露的系统,装置和方法,可以通过其它的方式实现。例如,以上所描述的装置实施例仅仅是示意性的,例如,该单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,例如多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
该作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
另外,在本申请各个实施例中的各功能单元可以集成在一个处理单元中,也可以是各个单元单独存在,也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现,也可以采用软件功能单元的形式实现。
该集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时,可以存储在一个计算机可读取存储介质中。基于这样的理解,本申请的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或者网络设备等)执行本申请各个实施例方法的全部或部分步骤。而前述的存储介质包括:U盘、流动硬盘、只读存储介质(ROM,Read-Only Memory)、随机存取存储介质(RAM,Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。
需要说明的是,上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。并且本文中的术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、装置、物品或者方法不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、装置、物品或者方法所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、装置、物品或者方法中还存在另外的相同要素。
显然,本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样,倘且本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内,则本发明也意图包含这些改动和变型在内。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。