Abstract:
A system for performing insurance policy audits electronically. The system optimizes service selection by tailoring an audit to an insured&#39;s business category and state(s) in which the insured does business. Initially, the insured is sent a letter and password to enter the system website. Once online, the insured is prompted to answer questions to complete the audit in a self-driven manner. Insureds can save work in progress and return to the audit later. The interactive process drives the methodology for insureds to complete the audit online, resulting in a more accurate audit at a lower average cost.

Description:
RELATED APPLICATIONS 
     This application claim priority to U.S. Provisional Patent Application Ser. No. 61/436,054, filed Jan. 25, 2011, the disclosure of which is incorporated herein by reference. 
    
    
     BACKGROUND 
     In an insurance policy audit, certain records of the insured are ‘audited’ to verify that they match what appears on the insured&#39;s insurance application, and what the insurance carrier believes the insured&#39;s risk to be. Previous insurance policy audits have presented insureds with a predetermined list of questions regardless of the insured&#39;s type of business. These questions are determined-in-advance and thus do not allow tailoring an audit to an insured&#39;s specific type of business. A method is therefore desired that will increase the accuracy of the determination of the insured&#39;s exposure base. 
     SOLUTION/SUMMARY 
     The present system comprises a web-driven system designed to perform insurance policy audits electronically. The system optimizes service selection by tailoring an audit to an insured&#39;s business category and state(s) in which the insured does business. 
     Initially, the insured is sent a letter and password to enter the system website. Once online, the insured is prompted to answer questions to complete the audit in a self-driven manner. Insureds can save work in progress and return to the audit later. The interactive process drives the methodology for insureds to complete the audit online, resulting in a more accurate audit at a lower average cost. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a diagram showing exemplary components of one embodiment of the present system; 
         FIG. 2  is a flowchart showing exemplary steps performed by the present system in one embodiment; and 
         FIG. 3  is a flowchart showing, in greater detail, exemplary steps performed by the present system in one embodiment. 
     
    
    
     DETAILED DESCRIPTION 
       FIG. 1  is a diagram showing exemplary high-level components of the present auditing system  100 . As shown in  FIG. 1 , in an exemplary embodiment, the present system comprises a processor  101  coupled between a web server  102  and a database server  103 . Web server  102  communicates with a client (user) browser  106  via the Internet  105 . Database server  103  is coupled to an insurer database  110 , an audit database  111 , and a document database  112 . I/O interface  130  includes input interface  133  and output interface  134 , which provide communication between databases  110 ,  111 , and  112 . 
     The input interface  133  responds to requests from controller  115  to get data from management system database  110 . Controller  115  runs on processor  101  and is aware of the API and/or database queries required to communicate with database server  103 . Controller  115  coordinates actions between the client browser  106  and other system modules. In particular, there are three data flows managed by the controller:
         1. Initial launch: Initially, a user launches the browser and navigates to a URL which provides a connection to web server  102 . Controller  115  then requests a unique user ID (previously sent to the user), gathers known user data from the insurer database  110  via input Interface  133 , queries the results store  123  for partially completed audit results, and requests the appropriate starting audit screen from screen selector  116 .   2. Audit progress: As the user proceeds through the audit process, controller  115  takes the latest user input, analyzes it for correctness, sends it to results store  123 , requests the next screen from the screen controller, and sends the screen to the client browser  106 .   3. Audit completion: Once the user has completed entering data into all of the screens, controller  115  sends the results to document database  112  by piping the data in results store  123  through output interface  134 .       

     The present audit system is dynamic, in that the flow of questions is determined by user (insured) responses as the user proceeds through the audit. A screen selector  116 , which, in one embodiment is an application controlled by controller  115 , provides the appropriate next (or previous) screen for the controller to send to the client browser  106 . Screens  104  are the ‘pages’ of the audit flow which are displayed via client browser  106 . These screens are forms which can be implemented and modified by a front-end developer. 
     Screen selector  116  incorporates a simple state machine  117  which takes the current state including the current screen and other variables such as ‘business type’—and maps the current state to a next state, in which the next screen to display on client browser  106  is indicated. State machine  117  determines each successive state based on the previous state and one or more answers to questions supplied by the insured. The screen selector also provides a previous state if, for example, the user needs to go back to an earlier screen in the flow. This functionality may be implemented, for example, as a script with logic, a database lookup table, or a combination of both. 
     Database  110  is used for managing all audit process assignments to be performed, hereinafter termed “work orders”. Each work order contains specific information on the insurance policy being audited, such as the policy number, policy period, class codes, policyholder info, etc. This data is used to complete the work orders. Once a work order is received in database area  121 , a subset of the work order information that is necessary for the insured (who is also a “user” of the present system) to complete the corresponding audit is sent to a work order data store  124  in database  111 . Document repository area  125  in document database  112  stores completed audit documents and any attachments that are submitted by the insured to support the audit information provided. 
     When the audit is complete, controller  115  sends the results from results store  123  to document repository  125  via output Interface  134 . The output interface understands the database queries and/or APIs (application programming interfaces) for storing the audit results into the document repository  125 . 
     In one embodiment, in order to get feedback on the design and usability of the online audit, an analytics data collector application (or script)  114  is used to track user activity throughout the audit process. Online user behavior is monitored in an effort to refine the procedural flow. In one embodiment, client-side scripts running on the client browser send event notifications to the server. These event notifications are sent as packets which may include the user ID, the current screen ID, an event code, a question ID, a timestamp, and other parameters. Event types may include navigation between screens, navigation between fields, and exiting the audit process. The analytics data collector script  114  on web server  102  receives these events and records them in the analytics database  122 . 
       FIG. 2  is a flowchart showing exemplary steps performed by the present system in an exemplary embodiment. The steps shown in  FIG. 2  represent actions taking place, via the Internet  105  and web server  102 , between a controller/screen selector application  115  and an insured to be audited, running client browser  106 . Controller/screen selector application  115  coordinates actions between the client browser  106  and other system modules. The steps shown in  FIG. 2  are performed by system  100 . 
     At step  205 , the system requests an insured&#39;s industry type. At step  210 , the insured selects the industry type from a list of types of industries, such as non-profit organization, hospitality industry, transportation industry, etc. The industry type determines which subsequent questions the insured is asked, and the insured response drives further subsequent questions to be asked related to that specific industry for workers compensation or general liability purposes. The industry type also drives various exposure base adjustments that are particular to the selected industry type. For example, certain questions, such as those pertaining to the insured&#39;s product, can drive subsequent questions related to installation, service, and repair, etc. 
     At step  215 , the system requests the name of each state in which the insured operates, and the insured responds by entering the state name(s), at step  220 . The state selection drives subsequent actions, including additional questions, related to various exposure base adjustments that may be applicable for each individual state selected by the insured. The state selection, industry type selected, plus the insured&#39;s answers to questions presented during the present audit, determines the exposure base adjustment entries that populate an exposure spreadsheet. 
     At step  225 , the system begins an iterative process of requesting and receiving information from the insured. The requested information is entered by the insured at step  230 , and the system verifies that the data entered by the insured is responsive to the corresponding questions at step  235 . If, at step  237 , the data entered by the insured is not acceptable (e.g., if the requested information has not been completely supplied), then, at step  238 , the system requests re-entry (or complete entry) of the data requested in step  225 . 
     If (at step  237 ) the data entered by the insured is acceptable, then, at step  239 , a check is made to determine whether all requests for information have been made by the system and answered by the insured, and steps  225 ,  230 ,  235 , and  237 - 239  are repeated as necessary. Finally, at step  240 , the system performs the insurance policy audit using the information entered by the insured. 
       FIG. 3  is a flowchart showing, in greater detail, exemplary steps performed by the present system in one embodiment. As shown in  FIG. 3 , at step  305 , the user enters a URL, using browser  106  to request initiation of the audit process. Web server  102  receives the request and sends the request to controller  115 , which uses screen selector application  116  to select an initial web page to be sent to the user&#39;s system. At step  307 , the selected web page (hereinafter “screen”) is then sent to the user&#39;s browser  106 , and the user enters a secure access code to initiate the audit process. 
     At step  310 , the next screen is sent to browser  106  and the insured selects their industry type from one of multiple industry ‘tracks’. The industry track selection determines the appropriate questions to ask for that particular industry, which will drive subsequent data entry screens. At step  315 , the next screen is sent to browser  106 , and the user selects the state or states in which the insured&#39;s business operates. The state selection determines the exposure base adjustment entries that populate columns in an exposure spreadsheet according to a chart of state exceptions. 
     Some general questions are then asked, and then in step  320 , industry specific questions are sent to browser  106  that are determined based upon the industry selection above. The insured also provides a description of operations in a text box. The number of employees the insured has will drive the setup of the exposure worksheet. In response to subsequent screens sent to browser  106  the insured then enters officer/principal information. 
     At step  325 , the insured is provided with a selection of class codes to enter, based on policy information. The insured selects the appropriate class code that matches each exposure type that was entered. At step  330 , in response to questions on one or more additional screens, the insured enters all necessary exposure adjustments for the industry type and state(s) selected. At step  335 , the system requests, and the insured then enters, non-employee exposure, if any. 
     A summary screen is then sent to the user, who then verifies the information that was entered. The user must check a box to confirm that all data entered was accurate to the best of their knowledge, and then submits the audit to system  100 , at step  340 . At step  345 , once the audit is submitted, all data entered by the insured is transferred to an auditing application  151  executing on processor  150 . A mapping application under control of the auditing application  151  extracts the information from fields in the various screens submitted by the user, and then automatically transfers the information into the appropriate field within the auditing application. A completed audit file  127  is then generated, without any human intervention, by auditing application  151  using information entered by the insured, and the audit file is stored in document repository  125 . 
     At step  350 , the audit file  127  is then returned to the insurer via a system-to-system feed into an insurer&#39;s computer system  160  (using an Internet connection, for example). In one embodiment, at step  360 , information in the audit file is directly populated into the insurer&#39;s policy billing system  161 , via either the system-to-system feed or by insurer&#39;s computer system  160 . A billing statement for the insurer is automatically generated, for example, by the insurer&#39;s billing system  161 , using the information from the audit file, at step  365 . 
     Having described the present system and method in detail and by reference to specific embodiments thereof, it will be apparent that modifications to the system and method, and variations thereon, are possible without departing from the scope of the invention defined in the appended claims. It is therefore contemplated that the present system is not limited to the specifically-disclosed aspects thereof.