Patent Application
20150356475
In a variety of contexts existing workflows may be streamlined, made more efficient, conducted in a more user-friendly fashion, focused to more effectively achieve a particular goal, or otherwise improved. Different workflows for a particular task develop over time for a number of reasons. For example, developments in technology can bring about new workflows for accomplishing various tasks. Sometimes the new workflows compliment the existing ones, whereas in other situations a new workflow may be preferred.
Often for tasks that may be accomplished in different ways, the various participants may prefer certain of the workflows that may be used. One example task in the insurance industry is that of submission of data to an insurance carrier, e.g., submission of endorsement data to an insurance carrier (or like data) to obtain a quote.
This traditionally involved communicating with the insurance carrier relevant data such that the insurance carrier could provide a quote for the requesting insurance agent. As technology progressed, the mechanisms used to communicate such data also progressed. For example, with the advent of the Internet, insurance carriers began taking data submissions via a web portal. Eventually more custom data management systems were developed for insurance agents such that the insurance agent could enter data once to receive quotes from many insurance carriers, e.g., for a specific individual or business, by entering this data into a data management system for submission to multiple insurance carriers.
In this example environment, it may be appreciated that the different mechanisms of data communication between insurance agent and insurance carrier have different attributes or features. Here, it may occur that a particular insurance carrier prefers that data submissions be made by an insurance agent using the data management system, e.g., for consistency of input, streamlined processing, efficiency, etc. On the other hand, an insurance agent may prefer or simply have a habit of using a legacy mechanism, e.g., a web portal.
In summary, an embodiment includes a method of providing feedback for insurance workflow optimization. The method may include an easy to understand indication, e.g., a visual such as a light bulb that changes hue, which is representative of a metric regarding how workflows are being managed. In an example embodiment, insurance agent data submissions may be processed to categorize each of the plurality of insurance agent data submissions, e.g., as preferred workflow type and non-preferred workflow type. On this basis, a metric may be determined to reflect a proportion of preferred workflow type and non-preferred workflow type in the insurance agent data submissions received. This metric may in turn be formed into an instruction that reflects the metric, with the instruction being communicated to a device at an insurance agency, e.g., a device including a light bulb of changing hue that provides an indication of the metric.
Additional embodiments are described, including other methods, as well as devices/apparatuses, systems including multiple devices, and products.
The foregoing is a summary and thus may contain simplifications, generalizations, and omissions of detail; consequently, those skilled in the art will appreciate that the summary is illustrative only and is not intended to be in any way limiting.
For a better understanding of the embodiments, together with other and further features and advantages thereof, reference is made to the following description, taken in conjunction with the accompanying drawings. The scope of the invention will be pointed out in the appended claims.
It will be readily understood that the components of the embodiments, as generally described and illustrated in the figures herein, may be arranged and designed in a wide variety of different configurations in addition to the described example embodiments. Thus, the following more detailed description of the example embodiments, as represented in the figures, is not intended to limit the scope of the embodiments, as claimed, but is merely representative of example embodiments.
Reference throughout this specification to “one embodiment” or “an embodiment” (or the like) means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” or the like in various places throughout this specification are not necessarily all referring to the same embodiment.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments. One skilled in the relevant art will recognize, however, that the various embodiments can be practiced without one or more of the specific details, or with other methods, components, materials, et cetera. In other instances, well known structures, materials, or operations are not shown or described in detail to avoid obfuscation.
As described herein, there may be more than one workflow or process for completing a task. In the example of an insurance data submission, e.g., by an insurance agent to an insurance carrier for a quote or like response, an insurance agent may choose to submit the data via a carrier proprietary (web) portal or via an agency data management system. Further, the various types of data submissions or communication may have sub-types. For example, in using a data management system, a user may choose to log in with an identification (ID) and password or may choose to utilize a single sign on (token based process).
In the case where an insurance agent chooses to use the web portal, the data submission will be limited to a single insurance carrier as the web portals are insurance carrier specific. In contrast, should the insurance agent choose to submit the data via the data management system, it may be submitted to multiple insurance carriers simultaneously or in parallel. Thus for example an insurance agent will not need to recall an insurance carrier specific password for logging into a web portal if the data management system is used, and the insurance agent will not have to re-enter data for each new submission if the data management system is used.
Over and above this consolidation, the receiving insurance carriers may in fact prefer that the insurance agents and insurance agencies use the data management system for such submissions, as the insurance carriers often have built in systems that are compatible with the data management system, whereas the legacy web portals may or may not be compatible with other systems of the insurance carriers. Among other difficulties, this use of the web portal rather the data management system leads to duplication of efforts, e.g., data entry and processing, form handling, etc., that may be avoided if the data management system is utilized by the insurance agent for the data submission. Additionally, the data management system may be more secure, particularly if a single sign on process is utilized. Thus, from the perspective of the insurance carriers and the insurance agents, there is some advantage to using the data management system workflow rather than the web portal workflow.
A difficulty arises, however, in the persistence of the legacy workflows in that many workers, e.g., insurance agents, are in the habit of utilizing the same. Conventional efforts to encourage such insurance agents to resort to a preferred workflow type may be made but these are often ineffectual for a variety of reasons. For example, incentives, whether monetary or otherwise, are often not linked in time such that those seeking the incentives may not make a positive association between workflow choice and incentive receipt. Additionally, standard communication such as discussions in meetings and the like tend to lose effectiveness over time and are otherwise inefficient.
Accordingly, an embodiment provides feedback for insurance workflow optimization. A method may include an easy to understand indication, e.g., a visual such as a light bulb that changes its hue (which includes color change) based on performance. This indication, which is representative of a metric regarding how workflows are being managed by a site such as an insurance agency provides immediate or intermittent feedback that conveniently notifies and reminds workers of their performance with respect to a metric of interest, in this case use of a preferred insurance workflow type.
In an example embodiment, insurance agent data submissions may be processed to categorize each of the plurality of insurance agent data submissions, e.g., as preferred workflow type and non-preferred workflow type. The insurance carrier receiving the data submissions via various mechanisms such as web portals and data management systems may accomplish this categorization.
On this basis, a metric may be determined to reflect a proportion of preferred workflow type and non-preferred workflow type in the insurance agent data submissions received. This metric, while useful to the insurance carrier, may also in turn be formed into an instruction that reflects the metric, with the instruction being communicated to a device at an insurance agency, e.g., a device including a light bulb of changing hue that provides an indication of the metric. In this way, feedback regarding uses of or adherence to a preferred workflow may be provided, e.g., in real time or periodically/intermittently, such that the insurance agents remain apprised of performance in this regard on an on-going basis.
The illustrated example embodiments will be best understood by reference to the figures. The following description is intended only by way of example, and simply illustrates certain example embodiments.
While various other circuits, circuitry or components may be utilized in information handling devices, an example illustrated in
There are power management circuits(s) 130, e.g., a battery management unit, BMU, which manage power as supplied for example via a rechargeable battery 140, which may be recharged by a connection to a power source (not shown). In at least one design, a single unit, such as 110, is used to supply BIOS like functionality and DRAM memory.
System 100 typically includes one or more of a WWAN transceiver 150 and a WLAN transceiver 160 for connecting to various networks, such as telecommunications networks and wireless Internet devices, e.g., access points. Additional devices 120 are commonly included. Commonly, system 100 will include a touch screen/controller 170 for data input and display. System 100 also typically includes various memory devices, for example flash memory 180 and SDRAM 190.
Information handling device circuitry, as for example outlined in
In an embodiment, referring now to
In any event, the data submissions are received at the insurance carrier device 203 such that a processor of the insurance carrier device 203, e.g., operatively connected to the database and/or the network interface, may execute instructions stored in a memory to receive and process the submissions from the insurance agents 201, 202.
As a specific and non-limiting example, an insurance carrier device 203 may receive, over a network connection facilitated by the network interface such as 150 and/or 160 of
As described herein, this processing may include categorizing the plurality of insurance agent data submissions to assign a type and/or sub-type to each of the plurality of insurance agent data submissions for inclusion into a group or sub-group, e.g., preferred workflow type and non-preferred workflow type. By doing this, the insurance carrier device 203 creates data that may be used to determine a metric that reflects a proportion of preferred workflow type and non-preferred workflow type of the plurality of insurance agent data submissions. As such, the insurance carrier device 203 may form an instruction, such as computer or device code, which reflects the metric. This instruction may then be communicated by the insurance carrier device 203, e.g., using a network connection such as the Internet, to a device 204 at the insurance agency, e.g., from which the data submissions originated.
Thus, the system may further include a device 204 of an insurance agency configured with an application that receives the instruction and provides an indication of the metric. In the example of
As may be appreciated, other agency device(s) 204 may be used in lieu of or in addition to a light bulb. For example, a visual notification such as an icon (e.g., virtual light bulb, etc.) may be provided on a device screen, e.g., a mobile device running an application that accesses the instructions provided by the insurance carrier device 203, such as a tablet device used by insurance agents 201, 202. As another example, the insurance agency device 204 may be a manager's device at the insurance agency such that he or she is apprised of workflow performance. As another example, the insurance agency device 204 may be a group device, such as one visible to a group of employees to encourage or incentivize the group with visual feedback (and/or other modality) regarding performance or compliance with workflow preferences of an insurance carrier. Combinations of insurance agency devices 204 may likewise be used.
In
An embodiment may determine a metric at 303, e.g., to reflect a proportion of preferred workflow type and non-preferred workflow type of the plurality of insurance agent data submissions. This permits an insurance carrier device 203 to monitor and determine if there has been a change in the workflow metric for an insurance agency at 304. Optionally, if no change to the metric has been determined at 304, the insurance carrier device 203 may not form and issue a new instruction, but rather may await further submissions that change the metric, e.g., by some predetermined amount. Alternatively, even if the metric has not changed, an instruction (e.g., the same instruction that was previously used) may be formed and communicated to the agency device(s) 204.
If a change in the metric is determined at 304, e.g., over a predetermined threshold, an insurance carrier device 203 may form, at 305, an instruction that reflects the metric. This instruction, as indicated, may be formed in a way such that it is mapped to a signal or instruction for a particular insurance agency device 204. In the example of the light bulb 204, an instruction may include information for directing a light bulb such as a mapped signal indicating a hue value for the light bulb with respect to the current metric value.
It is worth noting at this point that the metric value may take a variety of forms. The term proportion is used throughout as a representative term for a relative degree of workflow type usage. This may be a true proportion based only on a single agency's data submissions, on a single agent's data submissions, and/or may be scaled in some fashion, e.g., relative to a geographic region (such as a state or city), relative to a type of data submission or types of data submissions, etc.
Having formed an appropriate instruction or signal given the type of metric and/or the type of agency device(s) 204 to be modified, an embodiment may then communicate, at 306, the instruction to a device 204 at an insurance agency. Again, the device 204 may take a variety of forms, including a distributed form such that multiple agency devices 204 are used, so long as the device 204 of the insurance agency is configured with an application and/or component that receives the instruction and provides an indication of the metric.
Turning to
Computing device 410 may include a display 430, e.g., displaying graphics such as workers at the agency 440. The data for inclusion in the display 430 may be output from the computing device 410, e.g., using a processor and a display interface 414. Computing device 410 may also include a peripheral interface 412, e.g., for outputting an instruction reflecting the metric to a peripheral device, e.g., a device such as device 204 including a light bulb of changing hue.
By way of example, and referring now to
Within the display 500 are rows of each column populated with data. In the example of
The display 500 may also include a metric indicator 510 that is assigned to the workflow type or sub-type, the location, and/or the agency user. In the example of
A scaled or aggregated value, such as daily trend 550 also may be included. In this example, the daily trend 550, e.g., for the location “call center xx—cubes 7-12”, is “Hue 1-2”, indicated in row 560. This quickly apprises the reviewing employee of the performance trend (which may be another unit of time, e.g., current, weekly, monthly, yearly, etc.). Thus, for each such collection in the display 500, a trend may be compiled. In the example of
It will be understood then that the metric indicator 510 may be formed into, or a reflection of, the current instruction sent to the agency device 204. For example, the metric indicator 510 of
As will be appreciated by one skilled in the art, various aspects may be embodied as a system, method or device program product. Accordingly, aspects may take the form of an entirely hardware embodiment or an embodiment including software that may all generally be referred to herein as a “circuit,” “module” or “system.” Furthermore, aspects may take the form of a device program product embodied in one or more device readable medium(s) having device readable program code embodied therewith.
Any combination of one or more non-signal device readable storage medium(s) may be utilized. A storage medium may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples of a storage medium would include the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a storage medium is not a signal and “non-transitory” includes all media except signal media.
Program code embodied on a storage medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, et cetera, or any suitable combination of the foregoing.
Program code for carrying out operations may be written in any combination of one or more programming languages. The program code may execute entirely on a single device, partly on a single device, as a stand-alone software package, partly on single device and partly on another device, or entirely on the other device. In some cases, the devices may be connected through any type of connection or network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made through other devices (for example, through the Internet using an Internet Service Provider), through wireless connections, e.g., near-field communication, or through a hard wire connection, such as over a USB connection.
Example embodiments are described herein with reference to the figures, which illustrate example methods, devices and program products according to various example embodiments. It will be understood that the actions and functionality may be implemented at least in part by program instructions. These program instructions may be provided to a processor of a general purpose information handling device, a special purpose information handling device, or other programmable data processing device to produce a machine, such that the instructions, which execute via a processor of the device implement the functions/acts specified.
It is worth noting that while specific blocks are used in the figures, and a particular ordering of blocks has been illustrated, these are non-limiting examples. In certain contexts, two or more blocks may be combined, a block may be split into two or more blocks, or certain blocks may be re-ordered or re-organized as appropriate, as the explicit illustrated examples are used only for descriptive purposes and are not to be construed as limiting.
As used herein, the singular “a” and “an” may be construed as including the plural “one or more” unless clearly indicated otherwise.
This disclosure has been presented for purposes of illustration and description but is not intended to be exhaustive or limiting. Many modifications and variations will be apparent to those of ordinary skill in the art. The example embodiments were chosen and described in order to explain principles and practical application, and to enable others of ordinary skill in the art to understand the disclosure for various embodiments with various modifications as are suited to the particular use contemplated.
Thus, although illustrative example embodiments have been described herein with reference to the accompanying figures, it is to be understood that this description is not limiting and that various other changes and modifications may be affected therein by one skilled in the art without departing from the scope or spirit of the disclosure.
