服务提供者分配系统及服务提供者分配方法

文档序号:6546723阅读:159来源:国知局
服务提供者分配系统及服务提供者分配方法
【专利摘要】本发明提供服务提供者分配系统及服务提供者分配方法。现有技术中存在以下课题:在计算各服务提供者(服务资源)的能力值,每次服务提供请求到来时,将能力值最高的服务提供者分配给该服务提供请求的情况下,若能力高的人派出,则在有重要的服务提供请求(顾客为重要顾客的情况等)的情况下,不能分配能力高的人。本发明在以案件为单位进行的服务提供者的对象案件的分配处理中,计算用于延缓分配处理的延缓期间,在该延缓期间中,控制与下述状况相应的针对包含所述对象案件的案件的分配,该状况是与其他案件的分配相关且反映了包含其他服务提供者与利用者的契合性的服务请求水准的状况。
【专利说明】服务提供者分配系统及服务提供者分配方法

【技术领域】
[0001]本发明涉及在组织对利用者(例如企业对消费者)提供各种服务的情况下用于分配适合的服务提供者的技术。

【背景技术】
[0002]当前,在从企业等对利用者提供服务时,分配作为负责者的服务提供者来应对。例如,在保险公司中,对加入者(或预期加入者)分配推销员等服务提供者以应对支付、更新、加入等商谈。服务提供者存在多个,其能力由其是擅长领域也多种多样。此外,利用者也存在多个,其需求也各种各样,且随着时间而需求改变的情况也较多。这样的情况下,分配哪个服务提供者成为问题。
[0003]作为应对这样的问题的本【技术领域】的【背景技术】,有美国专利公报USP8126135号(专利文献I)。在该公报中,记载了 “对各服务资源来说,至少确立一个服务提供路径。月艮务路由器能够通过多个交流通道,受理多个服务提供请求。各服务提供请求基于服务提供请求的特征量而被分析。服务提供请求的特征量被与路由基准比较。各服务提供请求至少部分地基于所述比较结果而被自动地转发至所选择的服务资源。路由基准的值基于反馈而动态地接受变更”。
[0004]专利文献1:美国专利公报USP8126135号
[0005]在专利文献I中,计算各服务提供者(服务资源)的能力值,每当服务提供请求到来时,将能力值最高的服务提供者分配给该服务提供请求。但是,存在以下课题:若能力高的人派出,则在有重要的服务提供请求(顾客为重要顾客的情况等)的情况下,不能分配能力闻的人。


【发明内容】

[0006]为了解决上述课题,本发明在以案件为单位进行的服务提供者的对象案件的分配处理时,计算用于延缓分配处理的延缓期间,在该延缓期间中,控制与关于其他案件的分配且反映了服务请求水准的状况相应的针对包含所述对象案件在内的案件的分配,该服务请求水准包含其他服务提供者与利用者的契合性。
[0007]此外,分配的控制中,(a)在所述延缓期间中,在服务请求水准比对象案件更高的案件持续的情况下,将对象案件的分配设为保留状态,(b)在所述延缓期间中,在检测到服务请求水准比对象案件更高的案件没有持续的情况下,也将对象案件包含在内地执行分配处理,(C)在任一个案件中成为分配截止时刻的情况下,执行分配处理。
[0008]作为本发明的更详细的结构,采用例如权利要求书所述的结构。本申请包含多个用于解决上述课题的手段,但若举其一例,则为:
[0009]“一种服务提供者分配系统,具备:
[0010]用于受理来自顾客的服务提供请求的服务提供请求接收装置;
[0011]能够对服务提供者的个人信息进行保存、编辑及参照的服务提供者管理装置;
[0012]能够对顾客的个人信息进行保存、编辑及参照的顾客管理装置;
[0013]能够对多个服务提供请求的请求内容和进展状况进行保存、编辑及参照的分配管理装置;以及
[0014]针对服务提供请求进行服务提供者的分配的分配执行装置;
[0015]所述服务提供请求接收装置将所述服务提供请求组的请求内容和进展状况保存在所述分配管理装置中,
[0016]所述分配执行装置参照所述服务提供者管理装置内的服务提供者的个人信息、所述顾客管理装置内的顾客的个人信息、以及所述分配管理装置内的服务提供请求的请求内容和进展状况,
[0017]所述分配执行装置针对所述服务提供请求组的部分集合,汇总进行多人的服务提供者的分配”。
[0018]发明效果
[0019]根据本发明,能够对接受服务提供的利用者更适当地分配服务提供者。

【专利附图】

【附图说明】
[0020]图1表示本发明的一实施例中的与批量分配相关的技术思想的例子。
[0021]图2表示本发明的一实施例中的分配系统的效果例。
[0022]图3表示本发明的一实施例中的分配延缓期间、非分配期间等在本实施例中使用的用语的说明图。
[0023]图4表示本发明的一实施例中的批量分配的例子。
[0024]图5表示本发明的一实施例中的分配方式的流程图。
[0025]图6表示本发明的一实施例中的分配系统的结构图(其一)。
[0026]图7表示本发明的一实施例中的分配管理装置内存储的表的例子。
[0027]图8表示本发明的一实施例中的顾客管理装置内存储的表的例子。
[0028]图9表示本发明的一实施例中的服务提供者管理装置内存储的表的例子。
[0029]图10表示本发明的一实施例中的分配管理装置的功能结构。
[0030]图11表示本发明的一实施例中的分配系统的结构图(其二)。
[0031]附图标记说明:
[0032]600 分配执行装置;601分配计算功能;602 分配通知分发功能;604 服务提供者;607服务提供者管理装置;608分配管理装置;609顾客管理装置;615服务提供请求接收装置。

【具体实施方式】
[0033]以下,使用【专利附图】
附图
【附图说明】本发明的一实施例。在实施例中,以人寿保险领域中的业务活动为例进行说明,但还能够应用于这以外的服务。
[0034]人寿保险领域的业务活动多数为“主动推销”。即,不是从顾客对人寿保险公司询问后销售保险商品,而是通过被称为业务员或人寿保险小姐的业务负责者联系顾客从而开展保险销售的方式。在本实施例中,设想为人寿保险公司通过检测顾客的生活事件从而带来“业务机会”的情景。例如,若人寿保险公司具有与顾客的家族结构相关的信息,能够知道顾客的小孩明年4月小学入学,则在能够开展学资保险提案方面成为“业务机会”。作为其他例,设为人寿保险公司检测到由于顾客工作的公司的业绩差,所以明年4月起减薪的可能性高。人寿保险公司设想到顾客最近要解约保险而转移至其他便宜的保险公司的风险,先发制人而向顾客提案保险的重新评估,从而能够使顾客稳定于本公司服务。这虽然不是积极的含义,但也能够理解为“业务机会”。
[0035]在这样从业务员对顾客开展业务活动的情况下,人寿保险公司事先掌握顾客的情况。在上述的例子中,“明年4月小孩小学入学” “明年4月顾客会减薪的可能性高”相当于顾客的情况。在通过掌握这样的情况从而有必要开展业务活动的情况下,后文中将一个一个该业务活动称为“案件”。在人寿保险公司中,时时刻刻产生案件,一般为多个案件并行存在。对人寿保险公司来说,从有限的数目的业务员之中将谁分配给各案件成为问题。
[0036]图1是表示本实施例中的业务员的分配的技术思想的图。图1的101概念性地表示顾客的服务请求水准,102表示各业务员的能力值。服务请求水准高是指服务提供的难易度是否高或顾客是否为重要顾客的某一个或其双方。103为时间轴,104表示在不同的时刻产生三个案件的情形。105表示被共通(pool)化的多个案件。106表示被共通化的未分配的业务员。107表示对各案件分配未分配的业务员的情形。
[0037]图2概念性地表示通过进行本实施例而得到的效果。曲线图的横轴201是案件平均分配时间。即,是在全部案件中关于从案件产生时至分配业务员为止所花费的时间取得的平均值。纵轴202相当于取得全部顾客的顾客在服务提供后感到的满意度的合计值。满意度能够通过对顾客的调查问卷等计测,但也可以采用其他计测结果。203为曲线图的曲线例,204表示得到曲线图的最大值的案件平均分配时间。案件平均分配时间成为零的点表示现有技术的分配方式。即,在案件产生后立即分配业务员的“实时分配”。在本实施例中如图1所示那样不立刻分配业务员,而是将多个案件共通化,在后述的“适当定时”进行使多个案件与多个业务员匹配的“批量分配”。由于能够通过进行批量分配,针对服务请求水准更高的案件分配能力值更高的业务员,所以成为人尽其才的分配,能够减少分配的不匹配。即有助于提高顾客满意度。另一方面,在批量分配中,存在使顾客等待的副作用。但是,人寿保险的业务活动多数是“主动推销”,不要求应对来自顾客的询问或应对抱怨那样的即时应对,针对案件的分配有一些延缓时间。即,直至案件平均分配时间达到某值为止,由批量分配产生的人尽其才的优点比由分配延期产生的缺点更大,结果提高了顾客满意度。其结果,表示顾客满意度的曲线图成为203那样的形状,204成为最佳的案件平均分配时刻。问题是怎样决定最佳值204(前述的“适当定时”)。在图3以后说明决定“适当定时”的算法。
[0038]图3定义在本实施例中使用的用语。图3的301是表示产生了案件的时刻的新案件化时刻或分配延缓开始时刻,302是能够使业务员的分配延期的分配延缓期间,303是能够延缓业务员的分配的极限时刻、即对该案件至该时刻为止必须分配业务员中某一人的分配截止时刻,304为实际分配了业务员的分配时刻,305为由于业务员正在应对案件所以不能分配其他业务员的非分配期间,307为由于过了非分配期间,所以能够向其他业务员再分配的分配延缓开始时刻,308为能够使业务员的再分配延期的分配延缓期间。309表示时间轴。
[0039]如图3所示,只要没有完成报告则案件永远持续。如非分配期间305那样,在过了一定期间后案件也没有完成的情况下,案件由其他业务员接手的可能性变高(其中,若在分配延缓期间308中,在进行再分配前有案件的完成报告,则不接手)。在接手的业务员也不能在预定期间内完成案件的情况下,同案件进一步由其他业务员接手。案件最终在有案件完成报告的时机结束。反之,只要没有案件完成报告,则分配延缓期间302和非分配期间305被交替重复。
[0040]图3下部的图表示多个案件并行的情形。310表示当前时刻,312表示时间轴。313至319相当于各案件。在此,将分配延缓开始时刻比其他案件稍早的案件置于上方的位置。将这些多个案件具有的分配截止时刻之中的、从当前时刻310来看时间上最早的分配截止时刻称为最临近分配截止时刻。进而,将案件的集合体如下定义。将全部案件的集合体定义为LO (t)。由于新案件产生而引起的对集合的案件追加、以及由于案件完成而引起的从集合的案件删除时时刻刻发生,所以L0(t)成为时间的函数。在图中相当于包含从案件313至案件319为止的集合320。接着,在最临近分配截止时刻311的时刻,将处于分配延缓期间的阶段的案件或到达了分配截止时刻的案件定义为L(t)。L(t)是L0(t)的部分集合。在图中包含从案件313至案件318为止的集合321相当于L(t)。案件319被包含于LO (t),但不包含于L (t)(集合322)。接着,将在L (t)中包含的案件之中的、在当前时刻(t)310的时刻处于分配延缓期间的阶段的案件定义为LY(t)。在图中仅案件313属于LY(t)。接着,将在L(t)中包含的案件之中的、在当前时刻(t)310的时刻处于非分配期间的阶段的案件定义为LB⑴。在图中从案件314至案件318属于LB (t)。另外,L(t)是LY(t)和LB(t)的并集,LY(t)和LB(t)的交集为空集合。
[0041]图4表示在作为具体例而有四个案件的情况下的、进行批量分配的定时例。图4的403为时间轴,404为服务请求水准是7点的案件,405为服务请求水准是5点的案件,406为服务请求水准是9点的案件,407为服务请求水准是3点的案件。408为案件404从到达分配延缓开始时刻起至批量分配被执行为止的“等待”的期间,409为案件405从到达分配延缓开始时刻起至批量分配被执行为止的“等待”的期间,410为当前时刻(t),411为对案件404、405、406执行了批量分配的时刻,413为案件406的分配延缓开始时刻,415为案件407的分配延缓开始时刻,416为案件407中执行了分配的时刻。417为最临近分配截止时亥IJ。如图4所示,对案件404、405、406进行同时分配三名业务员的批量分配。另一方面,对案件407进行分配一名业务员的实时分配。按照图3中说明的案件集合的定义,则在当前时刻位于410的位置的情况下,案件404至案件407所属于LO (t),案件404至案件407所属于L (t),案件404所属于LY (t),案件405至案件407所属于LB (t)。另外,在此的“同时”是作为处理单位而汇总分配即可,也可以不是时间上完全一致。
[0042]以下,叙述如上述那样进行业务员的分配的技术思想。在图4中,设为有未分配的业务员A、B、C、D4人,各自的能力值为75点、50点、85点、35点。在四个案件之中的、最初到达分配延缓开始时刻的案件为404。此时,其他三个案件处于非分配期间的阶段。案件404为四个案件之中的服务请求水准第二高的案件。服务请求水准最高的案件为案件406。因此,若在案件404的分配延缓开始时刻的时刻将能力值最高的业务员C实时分配给案件404,则在案件406到达分配延缓开始时刻时,不能确保业务员C的可能性高。因此作为下一个方案,考虑对案件404实时分配能力值第二高的业务员A。但是在案件406在到达分配延缓开始时刻之前就完成的情况下,案件404能够得到能力值最高的业务员C。这是因为,在案件406完成的时刻服务请求水准最高的案件成为案件404 (其中,仅限于途中未产生服务请求水准高的新案件的情况)。
[0043]若这样考虑,则合理的是:案件404只要未到达分配截止时刻就不分配业务员,而监视案件406是否完成。其监视的期间为期间408。案件405中也能够适用同样的技术思想。案件405的服务请求水准的高度是四个案件之中的第三个。其中,若有案件406的完成报告,则能够得到能力值第二高的业务员A。进而,若案件404也完成,则能够得到能力值最高的业务员C。因此,合理的是:只要未到达分配截止时刻就不分配业务员,而监视案件406或404是否完成。其监视的期间为期间409。案件404在期间408的期间持续监视的状态,案件405在期间409的期间持续监视的状态,其结果,到达案件406的分配延缓开始时刻413。由于在该时刻案件406为服务请求水准最高的案件,所以能够得到能力值最高的业务员C。此外,案件407在该时刻未到达分配延缓开始时刻,但该案件与其他案件相比服务请求水准最低,所以针对案件404和案件405的业务员的分配结果不受案件407的影响。从而,服务请求水准的高度为第二的案件404能够得到能力值第二高的业务员A,服务请求水准的高度为第三的案件405能够得到能力值第三高的业务员B。即在时刻411的定时执行批量分配,对案件404、405、406分别分配业务员A、B、C。最后在案件407到达分配延缓开始时刻415的时刻,由于不存在其他案件(除了过程中产生了新案件的情况),执行实时分配。由于在该时刻仅业务员D为未分配,所以业务员D被分配给案件407。
[0044]图5是将图4的技术思想以流程图而一般化的图。501表示产生了案件的开始节点。502表示当前时刻(t)是否与最临近分配截止时刻(tl) 一致的条件分支。在条件分支502为“是”的情况下,接着到达处理504。在处理504中,对所属于L(t)的全部案件执行批量处理。即,将能力值较高的未分配的业务员(在未分配之中比较高的)分配给服务请求水准较高的案件。若实施分配,则所属于L (t)的全部案件转移到非分配期间。最临近分配截止时刻也被复位到将来的值。从而,由于各案件所属于哪个集合改变,所以再定义L0(t)、L(t)、LY(t)、LB(t)的要素(处理506),返回监视位置507。另一方面,在条件分支502为“否”的情况下,转移到条件分支503。条件分支503判定在LY(t)内的服务请求水准(Sn(An))的最小值是否比在LB(t)内的服务请求水准(Sn(An))的最大值大。
[0045]以图3的例子来说,判定案件313的服务请求水准是否比案件314至案件318的服务请求水准的最大值大。以图4的例子来说,由于在当前时刻(t)位于410的位置的情况下,所属于LY⑴的案件404的服务请求水准(7点)比所属于LB⑴的案件405至407的服务请求水准的最大值(9点)小,所以对条件分支503给予“否”。若条件分支503返回“否”,则流程图返回监视位置507。其中,在图4的当前时刻⑴从410的位置向右侧前进,到达了 411的位置的情况下,所属于LY (t)的是案件404至案件406,所属于LB (t)的仅是案件407,所以在该时刻条件分支503返回“是”,转移至处理505。在处理505中,对所属于LY(t)的全部案件执行批量处理。即,将能力值较高的未分配的业务员分配给服务请求水准较高的案件。若实施分配,则所属于LY (t)的全部案件转移到非分配期间。最临近分配截止时刻也被复位到其他值。从而,由于各案件所属于哪个集合改变,所以再定义L0(t)、L(t)、LY(t)、LB(t)的要素(处理506),返回监视位置507。以上是本实施例中的处理流程。
[0046]图6以及图11是本实施例的业务员分配系统的结构例。图6以及图11的601是用于实施处理504或处理505的分配计算功能。602是从分配计算功能601接受作为分配计算功能的输出的分配计算结果,并对各业务员分发分配消息通知的分配通知分发功能。604是以业务员为代表的服务提供者。607是用于管理业务员的个人信息的服务提供者管理装置。608是用于管理当前进行中的案件信息的分配管理装置,609是用于管理顾客的个人信息的顾客管理装置。
[0047]另外,分配计算功能601在实施处理504或处理505时,以降序对对象案件的“月艮务请求水准”的值以及未分配的业务员的合计能力值(后述)进行排序,以各自的值由大到小的顺序(也就是说,所排序的顺序)匹配。分配计算功能601从案件管理表701获得案件的“服务请求水准”的值。另一方面,分配计算功能601以以下的流程计算各业务员的合计能力值。即,提取服务提供者管理表900的“状态”成为未分配的“业务员ID”,从服务提供者管理表900提取该“业务员ID”的能力值(后述),将“顾客ID”和“业务员ID”的信息代入契合性表802而提取“契合性得分”,对上述能力值和上述“契合性得分”进行合计而设为“业务员ID”的合计能力值。另外,在例如案件的“案件类别”为医疗保险提案的情况下,能力值与服务提供者管理表900的“医疗保险知识水平”的值对应。
[0048]图7表示分配管理装置608所管理的全部表。分配管理装置608所管理的表是案件管理表701、难易度定义表702、服务请求水准定义表704、以及期间定义表705。另外,将难易度定义表702、服务请求水准定义表704、期间定义表705称为案件参数。案件管理表701能够通过系统管理者访问案件管理表管理功能1014(后述)而事先设定。难易度定义表702、服务请求定义表704、期间定义表705能够通过系统管理者访问后述的案件参数管理功能1012而事先设定。
[0049]案件管理表701由下述的数据项目构成。即,由用于识别案件的“案件ID”、用于识别保险重新评估提案/死亡保险提案/医疗保险提案/学资保险提案等案件的种类的“案件类别”、用于识别顾客的“顾客ID”、被数值化的“服务请求水准”、用于识别业务员的“业务员ID”、用于识别各案件在当前时刻是分配延缓期间还是非分配期间的“当前分配状况”、“下次分配延缓开始时刻”、“下次分配截止时刻”、用于判定是否是具有最临近分配截止时刻的案件的“最临近分配截止时刻?”、赋予各案件所属的集合的“所属集合”、以及表现各案件中的进展的“进展度为刚开始,100%为完成)构成。这些数据项目由以下的结构决定。针对“案件ID”,服务提供请求接收装置615在接收案件后设定比上次最后的案件ID大一个数字的序号。针对“案件类别”,服务提供请求接收装置615从期间定义表705的案件类别组之中设定案件内容最相近的类别。
[0050]针对“顾客ID”,服务提供请求接收装置615从案件内容提取顾客名,设定与顾客管理表800的“姓名”对应的“顾客ID”。针对“服务请求水准“,服务提供请求接收装置615从案件管理表701的“案件类别”和难易度定义表702提取“难易度”,从案件管理表701的“顾客ID”和顾客管理表800提取“顾客级别(rank) ”,设定将“难易度”和“顾客级别”代入服务请求水准定义表704而得出的值。针对“业务员ID”,分配计算功能处理601将作为处理504或处理505的批量分配的结果的“案件ID”和“业务员ID”的组合,设定到案件管理表701。针对“当前分配状况”、“下次分配延缓开始时刻”、“下次分配截止时刻”、“最临近分配截止时刻”、“所属集合”以及“进展度”,由后述的案件信息编辑功能1006设定值。
[0051]难易度定义表702由下述的数据项目构成。即,由案件管理表701中说明的“案件类别”以及表示完成各案件类别的难度的“难易度”构成。
[0052]服务请求水准定义表704由“难易度”、“顾客级别”这两个被决定的“服务请求水准”构成。这两个的含义与难易度定义表702的“难易度”和顾客管理表800的“顾客级别”相同。
[0053]期间定义表705由下述的数据项目构成。即,由难易度定义表702中说明的“案件类别”、决定图3的分配延缓期间所需的参数即“标准分配延缓期间”、以及决定图3的非分配期间所需的参数即“标准非分配期间”构成。分配延缓期间和非分配期间如下决定。在服务提供请求接收装置615接收到新案件的情况下,“标准分配延缓期间”和“标准非分配期间”的值被设定为分配延缓期间以及非分配期间的值。在再分配(对相同案件的第二次以后的分配)的情况下,分配延缓期间或非分配期间(例如分配延缓期间308)以下式(数学式I以及数学式2)决定。
[0054]非分配期间=标准非分配期间* (I 一进展度/100)……(数学式I)
[0055]分配延缓期间=非分配期间* (标准分配延缓期间/标准非分配期间)……(数学式2)
[0056]上述的“进展度”与案件管理表701的“进展度”相同。其中,上式是用于计算分配延缓期间以及非分配期间的一例,也可以是其他计算式。
[0057]图8表示顾客管理装置609所管理的全部表。顾客管理装置609所管理的表是顾客管理表800、交涉履历表801以及契合性表802。
[0058]顾客管理表800由下述的数据项目构成。即,由用于识别顾客的“顾客ID”、表示顾客的名字的“姓名”、数字越大表示越是重要顾客的“顾客级别”、以及用于识别各业务员对同一顾客进行的过去的全部业务活动(交涉履历)的“交涉ID”。针对“顾客ID”,服务提供请求接收装置615在顾客管理表800内未找到顾客姓名的情况下设定新的序号。针对“顾客级别”,系统管理者手动设定值或顾客管理装置自动设定与基于同一顾客的销售贡献度(以交涉履历表801的“销售实际业绩”为基础计算)成比例的值。针对“交涉ID”,分配计算功能601在每次对各案件分配业务员时设定新的值。另外,在顾客管理表800中,作为表示顾客属性的信息仅包含“姓名”,但也可以在表中包含住址、电话号码、性别、年龄等其他属性,也可以通过其他表管理。
[0059]交涉履历表801由下述的数据项目构成。即,由顾客管理表800中说明的“交涉ID”、用于识别业务员的“业务员ID”、表示交涉的产生时刻的“交涉日期时间”、表示通过该交涉得到的业务成果(实际业绩)的“销售实际业绩”、以及作为业务员的评价点的“反馈点”构成。“交涉ID”的决定方式与顾客管理表800中说明的方式相同。针对“业务员ID”,分配计算功能601设定案件管理表701的“业务员ID”的值。针对“销售实际业绩”,业务员设定实际业绩值。针对“反馈点”,以业务员自身输入从顾客得到的评价结果(例如“顾客言及‘希望关于其他保险商品继续商谈’ ”等)或输入其他业务员对顾客实施的调查问卷结果(顾客满意度等)的任一个方法而设定值。
[0060]契合性表802由下述的数据项目构成。即,由顾客管理表800中说明的“顾客ID”、交涉履历表801中说明的“业务员ID”、以及表示顾客和业务员之间的契合性的高度的“契合性得分”构成。针对“顾客ID”,服务提供请求接收装置615设定与顾客管理表800相同的值。针对“业务员ID”,分配计算功能601设定分配给案件的“业务员ID”。如图所示,在过去对特定顾客有多个业务员应对的情况下,对相同的“顾客ID”的值关联多个值的“业务员ID”。针对“契合性得分”,顾客管理装置609设定交涉履历表801的“销售实际业绩”的合计值和“反馈点”的合计值的加权总和。即,顾客管理装置609将“顾客ID”的值作为关键词从顾客管理表800提取“交涉ID”列表,将“交涉ID”和“业务员ID”作为关键词从交涉履历表801提取“销售实际业绩”和“反馈点”的值,针对由“顾客ID”和“业务员ID”所成的对合计“销售实际业绩”和“反馈点”。另外,上述的加权的值事先由系统管理者设定到顾客管理装置609。
[0061]图9是服务提供者管理装置607所管理的服务提供者管理表900。
[0062]服务提供者管理表900由下述的数据项目构成。即,由用于识别业务员的“业务员ID”、表示该业务员是否已经被分配给某案件的“状态”、表示业务员的工作年数的“勤务年数”、列举了业务员能够说的语言的“可会话语言”、表示业务员具有什么程度与死亡保险商品相关的知识的“死亡保险知识水平”、表示业务员具有何种程度的与医疗保险商品相关的知识的“医疗保险知识水平”、以及表示各业务员的能力值的上述以外的多个参数项目构成。针对“业务员ID”,系统管理者在每次业务员入职时,设定新的序号。针对“状态”,在分配执行装置600实施分配后将值设定为“分配中”,分配管理装置608在案件刚完成之后将值设定为“未分配”。针对“工作年数”,服务提供者管理装置607持续地自动更新从入职时刻起的值。针对表示与“死亡保险知识水平”以及”医疗保险知识水平”以及其他保险商品相关的知识水平的参数组,系统管理者基于公司内测试等的结果,进行设定/更新。
[0063]图10是分配管理装置608内的硬件构造。图中的1001是CPU等控制部,1002是RAM等存储部,1003是网络接口等通信部。
[0064]控制部1001由下述的功能组构成。即,由对分配计算功能601指示分配执行计算开始的分配执行指示功能1010、用于管理案件管理表存储部1008中存储的案件管理表701的案件管理表管理功能1014、以及用于管理案件参数存储部1009中存储的案件参数的案件参数管理功能1012构成。
[0065]存储部1002由下述的功能组构成。即,由用于存储案件管理表701的案件管理表存储部1008、以及用于存储案件参数的案件参数存储部1009构成。
[0066]案件管理表管理功能1014由下述的功能组构成。即,由用于判定后述的最临近结束时刻是否与当前时刻一致的最临近结束时刻判定功能1004、用于编辑案件管理表701的全部数据项目的案件信息编辑功能1006、以及用于判定条件分支503和条件分支504的处理流程条件判定功能1005构成。
[0067]以下说明各功能的细节。另外,各功能通过程序而实现,作为计算机而实现的各装置读入并据此执行信息处理。
[0068]最临近结束时刻判定功能1004由用于存储最临近结束时刻的微小存储域1015、以及实时执行当前时刻的存储/更新的定时器1016构成。最临近结束时刻表示:关于全部案件,处于分配延缓期间的阶段的案件中的该期间的结束时刻和处于非分配期间的阶段的案件中的该期间的结束时刻之中的、与当前时刻最相近的时刻。最临近结束时刻判定功能1004从定时器1016获得当前时刻,从微小存储域1015获得最临近结束时刻,在控制部1001内实时地依次判定两者的值是否一致。最临近结束时刻判定功能1004在两者的值不一致的情况下不执行。在两者的值一致的情况下,最临近结束时刻判定功能1004启动案件信息编辑功能1006。
[0069]案件信息编辑功能1006是访问案件管理表存储部1008并编辑案件管理表701的全部数据项目的功能。此外,该功能具有用于服务提供者604编辑案件管理表701的CTI功能。案件信息编辑功能1006在从服务提供请求接收功能615接收了新案件(案件追加)、或从服务提供者604接收了案件完成的通知(案件删除)、或从最临近结束时刻判定功能1004接受了启动通知(到达最临近结束判定时刻)、或服务提供者604编辑了案件管理表701的一部分的情况下,更新全部案件的信息,将案件管理表701之中的属于L(t)的案件的全部信息转交给处理流程条件判定功能1005后,更新微小存储域1015的最临近结束时刻的值。
[0070]处理流程条件判定功能1005是用于判定图5的条件分支502和条件分支503的功能。在从案件信息编辑功能1006取得了属于L(t)的案件信息的情况下,实施条件分支502。在条件分支502的判定结果为“否”的情况下,转移到条件分支503。在条件分支502的判定结果为“是”的情况下,将属于L(t)的案件信息分发给分配计算功能601。实施了条件分支503的结果是判定结果为“否”的情况下,什么都不执行。在条件分支503的判定结果为“是”的情况下,将属于作为L(t)的部分集合的LY(t)的案件信息分发给分配计算功能 601。
[0071]案件参数管理功能1012是访问案件参数存储部1009并编辑难易度定义表702或服务请求水准定义表704或期间定义表705的功能。此外,该功能具有用于服务提供者604编辑这些表的⑶I功能。
【权利要求】
1.一种服务提供者分配系统,用于针对利用者分配与规定的组织相关联的多个服务提供者中的某一个服务提供者,其特征在于,具有: 将针对所述利用者的服务提供请求作为案件受理的部件; 关于所受理的案件,计算用于延缓分配处理的延缓期间的部件;以及在该延缓期间中,对与下述状况相应的针对包含对象案件在内的案件的分配进行控制的部件,该状况是与其他案件的分配相关且反映了服务请求水准的状况,该服务请求水准包含其他服务提供者与利用者的契合性。
2.如权利要求1所述的服务提供者分配系统,其特征在于, 对所述分配进行控制的部件为: 在所述延缓期间中,在服务请求水准比对象案件高的案件持续的情况下,将对象案件的分配设为保留状态, 在所述延缓期间中,在检测到服务请求水准比对象案件高的案件未持续的情况下,将对象案件也包含在内地执行分配处理, 在所述案件中的任一个案件到了分配截止时刻的情况下,执行分配处理。
3.如权利要求1所述的服务提供者分配系统,其特征在于, 对所述分配进行控制的部件针对所述案件,将多人的服务提供者的分配汇总并作为批量处理来分配。
4.如权利要求3所述的服务提供者分配系统,其特征在于,还具有: 更新针对所述案件的分配的部件;以及 在进行了所述更新的情况下,决定成为分配对象的案件的集合的部件; 所述服务提供者分配系统还具有: 将所述案件的集合向对所述分配进行控制的部件进行通知的部件。
5.如权利要求4所述的服务提供者分配系统,其特征在于, 该服务提供者分配系统还具有控制部,该控制部存储所述更新的时刻和当前时刻, 该控制部依次判定所述更新的时刻与当前时刻是否一致。
6.一种服务提供者分配方法,用于利用信息处理装置针对利用者分配与规定的组织相关联的多个服务提供者中的某一个服务提供者,其特征在于, 将针对所述利用者的服务提供请求作为案件受理; 关于所受理的案件,计算用于延缓分配处理的延缓期间; 在该延缓期间中,对与下述状况相应的针对包含对象案件在内的案件的分配进行控制,该状况是与其他案件的分配相关且反映了服务请求水准的状况,该服务请求水准包含其他服务提供者与利用者的契合性。
7.如权利要求6所述的服务提供者分配方法,其特征在于, 对所述分配进行控制的处理为: 在所述延缓期间中,在服务请求水准比对象案件高的案件持续的情况下,将对象案件的分配设为保留状态, 在所述延缓期间中,在检测到服务请求水准比对象案件高的案件未持续的情况下,将对象案件也包含在内地执行分配处理, 在所述案件中的任一个案件到了分配截止时刻的情况下,执行分配处理。
8.如权利要求6所述的服务提供者分配方法,其特征在于, 对所述分配进行控制的处理针对所述案件,将多人的服务提供者的分配汇总并作为批量处理来分配。
9.如权利要求8所述的服务提供者分配方法,其特征在于,进而, 更新针对所述案件的分配; 在进行了所述更新的情况下,决定成为分配对象的案件的集合; 将所述案件的集合向对所述分配进行控制的部件进行通知。
10.如权利要求9所述的服务提供者分配方法,其特征在于, 所述信息处理装置具有控制部,该控制部存储所述更新的时刻和当前时刻, 该控制部依次判定所述更新的时刻与当前时刻是否一致。
【文档编号】G06Q50/10GK104184718SQ201410208295
【公开日】2014年12月3日 申请日期:2014年5月16日 优先权日:2013年5月27日
【发明者】上杉忠兴, 大泽哲, 寺滨幸德 申请人:株式会社日立制作所
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1