JP2023542361A - Method and apparatus for insurance management system - Google Patents

Abstract

The system provides a method and apparatus for tracking and managing insurance coverage for businesses. In one embodiment, the system provides an automated report that includes all types of coverage within a single report with a visual display that fully informs the reader of the status and areas of risk and concern. The reports are fully sortable and can provide a single resource for managing all of a company's insurance policies and coverages. In one embodiment, the system presents data in a unique grid that provides important information at a glance to enhance management of the system. [Selection diagram] Figure 1

Description

This patent application claims priority to U.S. Provisional Patent Application No. 62/901,389, filed September 17, 2019, which is incorporated herein by reference in its entirety.

Many businesses need to obtain and maintain extensive insurance coverage to protect against loss. It is important that businesses not be over-insured, which increases overhead and expenses. It is also important that businesses are not underinsured, which can lead to uninsured losses. In some cases, not having the correct insurance may be prohibited by either regulations, conventions, contractual agreements, trade association requirements, and the like. Tracking multiple types of insurance and multiple insurance policies presents a problem for many businesses.

In the prior art, companies may manually maintain a database and/or spreadsheet for each compensation type, as well as a master consolidated spreadsheet for all compensations. Changes or updates must be made correctly across all databases and spreadsheets, which can introduce errors that affect compensation. The spreadsheet may be periodically sent to the company's insurance agent to verify coverage by issuing insurance policies and premium invoices based on the spreadsheet. If the spreadsheet is incorrect, the insurance agent may issue incorrect or insufficient insurance policies and/or coverage.

The system provides a method and apparatus for tracking and managing insurance coverage for businesses. In one embodiment, the system provides an automated reporting system that includes all types of coverage within a single report with a visual display that fully informs the reader of the status and areas of risk and concern. The reports are fully sortable and can provide a single resource for managing all of a company's insurance policies and coverages. In one embodiment, the system presents data in a unique grid that provides important information at a glance to enhance management of the system.

1 is a block diagram of one embodiment of the present system. FIG. FIG. 6 illustrates an example of an interface on a dashboard in one embodiment when a client tab is selected. FIG. The client tab 202 is shown with the client edit option selected. Shows the summary page for client reports. 4A shows the PD report from 401 of FIG. 4A. 3 illustrates a vehicle tab in one embodiment. 3 illustrates a vehicle view filtered by a client in one embodiment. The interface is shown when "driver" is selected in FIG. 4, FIG. 5, or FIG. 6. 3 illustrates an example of an insurance policy issued by the system in one embodiment. This is a homepage in one embodiment of this system. The view after selecting RN(V) is shown. The view after selecting an item is shown in FIG. 9B. FIG. 2 is a flow diagram illustrating the operation of the system in one embodiment. FIG. 3 is a flow diagram illustrating a response to a request for action in one embodiment. It is an example of a computer system in one embodiment of this system.

The system can be used to accomplish several operations related to commercial insurance. One industry that requires particularly complex insurance is the transportation industry. A transportation company may employ a large number of drivers, either as employees or independent contractors, and may use a large number of vehicles, either owned, leased, or contracted. It is extremely important that all insurance obligations are properly satisfied to avoid over- and under-insured situations. The Company provides a variety of insurance policies, including auto liability, physical damage, non-trucking liability, workers' compensation, contingent liability, cargo insurance, general liability, passenger accident liability, and the like. Must have insurance coverage type. Although the system is described with respect to a trucking company, it is understood that it is equally applicable to any company that has insurance.

FIG. 1 is a functional block diagram of one embodiment of this system. System 100 includes a processing engine/database 101 that provides the intelligence of the system and stores data related to elements of the insurance management system. This data includes coverage, policy information, renewal date, premium, vehicle (asset type, ID, price, driver type, lien information), sponsored and non-sponsored coverage. , employee/independent contractor status, driver information (including any personally identifiable information that is encrypted), and the like.

The system communicates with the outside world via an import/export engine 102 and/or a user interface 107. The import/export engine 102 can be used to send reports, alerts, communications, and the like as needed. Additionally, the import/export engine 102 can receive communications from transportation management systems (TMS), agency management systems (AMS), insureds, insurance companies, customers, and the like. The system includes the ability to import and export vehicle lists to and from spreadsheets (eg, Excel) and provide alerts when the data is incomplete. Multi-user audit tracking is implemented to maximize data reliability and accuracy. Client access is provided to allow direct changes while maintaining an audit trail for accountability.

Reporting engine 103 is used to generate automatic and custom reports for the system. When triggered, the reporting engine receives commands to the processing engine/database 101, including deadlines for report execution, and generates the required reports. Reporting engine 103 may also generate communications (eg, texts, emails) with clients, generate invoices, and the like as desired. The system provides reporting for periodic (eg, monthly) charges (eg, monthly PD and NT charges). The system stores reports of corporate status in accordance with insurance policy requirements for reporting. For example, if an insurance policy requires a report to be run on the 5th of each month, the system automatically saves the report on that day. The system allows customization of all aspects of reporting and data analysis.

The certificate engine 104 can generate and issue vehicle certificates individually and in batches, and can do so based on price, ownership, lienholder, and the like. The system can, for example, batch all securities to a lienholder and email them at the same time. In one embodiment, the system can issue physical damage (PD) and non-truck transportation (NT) securities. It can also issue Occupational Accident (OA) securities and PD, NT and OA consolidated into a single security. The system allows generation of batches of vehicles and batches of multiple vehicle securities (eg, for all units with the same lienholder).

VIN decoder/analyzer 105 checks the accuracy of the VIN input to the system. The VIN decoder/analyzer 105 has multiple levels of checking for a correct VIN, including parsing the VIN itself for the correct number of digits, redisplaying the vehicle description associated with the VIN, and updating the system. Including making sure it matches your vehicle. The VIN decoder/analyzer 105 also automatically checks for duplicate VINs to avoid errors in many parts of the system. VIN decoder/analyzer 105 finds mistakes within VIN entries to avoid downstream problems.

The audit engine 106 tracks which users have made changes to any data or metadata within the system, along with timestamps and date codes. Audit engine 106 also tracks client changes made by users accessing the system via user interface 107. Efficiency and accuracy are promoted by the system by allowing users to make changes while maintaining an audit trail. User interface 107 communicates with user dashboard 108.

User dashboard 108 is used by a number of entities to track a number of metrics, including agents (eg, insurance agencies), insureds (eg, trucking companies), or others. In one embodiment, the user dashboard 108 allows the user to view policies that are about to expire, recent vehicle transactions, recently added vehicles, recently deleted vehicles, non-sponsored insurance policies, and recent insurance policy transactions. , and the like.

Dashboard 108 also includes a Client Overview page where agents can add clients, initiate client overview export, policy counts (with links to parent and grandparent clients, child and grandchild clients, etc.), unit clients, etc. Transactions, coverage types and driver insured unit summaries may be presented, and the like.

The dashboard also includes a vehicle page for each client with sortable columns, the ability to add and remove vehicles, manage securities, respond to calls to action, track lienholders/owners/drivers/transactions, etc. including.

Unit coverage can be determined at first glance. In some situations, companies may have independent contractors for both sponsored and non-sponsored plans. The present system allows easy tracking of such situations.

The present system has several advantages over prior art systems. The system provides a consolidated vehicle list, provides multiple user access and audit trails, can issue insurance policies, provides employee access to online policies, and reports at a frequency selected by the user. I will provide a. The system presents a color-coded icon-based grid of unit compensation that allows users to understand conditions at a glance. The system includes response and action item counters, allowing easy sorting to arrive at only those items that require action. This precludes manual searches for action items.

FIG. 2 shows an example of an interface on a dashboard in one embodiment. Dashboard 200 has multiple tabs 201-209, each representing an interface. The tabs include home 201, client 202, insurance policy 203, vehicle 204, insurance company 205, policy 206, lienholder 207, agency 208, and settings 209. The system may have additional, different, or fewer tabs as desired.

In FIG. 2, client tab 202 is selected. The dashboard presents clients, in this example an insurance agency. The client 202 interface includes name 201 (the name of the insured), agent 211 (the insurance agent working with the insured to obtain the insurance contract), and producer 212 (the agent working with the insured). Contains several columns, including Store Agent), CSR 213 (Customer Service Representative), and Insurance Policy 214. The "M" next to a policy represents a "master" or "parent" client policy. In one embodiment, the light blue color represents a clickable link, so when the user clicks on a number in this column, the system redirects to the client policy list. The numbers on the left represent child client insurance policies. The system can also manage grandchild/child/parent insurance policy logic.

Area 215 within client tab 202 shows numerical information associated with the column headings. In other tabs, the area may show icons and/or graphical representations of information. Area 215 includes AL (Automobile Liability), CG (Cargo), PD (Physical Damage), NT (Non-Truck Transport), OA (Occupational Accident), PA (Passenger Accident), Driver, Report and Options. shows multiple columns related to vehicles, including (including Edit Vehicle, Delete Unit, and Transaction/Audit Trail).

FIG. 3 shows the Client tab 202 when the Edit Client option is selected. Upon selecting a client in the name 201 column, the interface 300 shown in FIG. 3 appears. Area 301 includes fields for the client's name, address, contact information, and other information, including DOT# (Department of Transportation). Area 302 includes a list of client contacts, titles, and contact information (eg, email). Client contacts may also include contact roles and rights and permission logic for defining access to monthly reports, auditing emails, and the like.

FIG. 4A shows a summary page for client reports. The interface is what appears, in one embodiment, when the report icon is selected in area 215 of FIG. Interface 400 shows report summaries for PD insurance contract 401, OA insurance contract 402, AL insurance contract 403, NT insurance contract 404, PA insurance contract 405, CG insurance contract 406, and vehicle insurance contract summary 407. The report summary may include policy term, policy number, average price, monthly fee, monthly average, and the like. Each report may have different summary information. For example, the OA report 402 includes average driver counts, and the AL report includes average units, power units, and non-power units.

FIG. 4B shows a detailed report if the user selects summary 401 of FIG. 4A, for example. The client is shown in area 410 with the type of report (eg, PD insurance policy) in area 411. Policy details are provided in area 412 and include reporting date, price, monthly fee, monthly total, +/- reporting, and regeneration. The monthly summary view provides two report types for each month: a PDF of the invoice unit summary of expenses, and an Excel type report that shows the addition/deletion of units/drivers with a net summary of changes. yields information, important to the department's insurance company billing reporting requirements.

FIG. 5 shows a vehicle tab 204 in one embodiment. The system provides a unified, integrated vehicle list that facilitates real-time asset management for clients. The system has built-in logic to reduce omissions, data entry errors, and misidentification of vehicles. The system includes a VIN decoder to ensure the vehicle has the proper number of digits and the make and model is accurate. This interface 500 includes columns for unit 501, VIN 502, year 503, manufacturer 504 date added 505, price 506, client name 507, model 508, status area 509, driver 510, and owner 511.

Area 509 implements a practical system for displaying information that can be quickly digested and understood by the user. Area 509 includes information regarding DT, AL, CG, PD, NT, OA, PA, and options. Columns typically include one item per row, but in one embodiment, a circled "F" indicates that a future policy selection exists. Selecting F maps to a new future policy and any active policy. The system uses symbols and colors to provide status information in each column. For example, a red circle with an exclamation point inside indicates that action is required. This icon is a call to action, meaning that action is required. In one embodiment, this icon is the default icon alert for units with no known compensation information. This is done by someone to determine whether the unit has sponsor-supported coverage or whether securities need to be issued to the unit, or whether the unit has non-sponsor-supported coverage. It means that you need to take action.

A green check means the vehicle is verified for Sponsored Coverage. Compensation is entered and/or verified through the client's sponsored sponsorship program. Insurance policies are available for display. A blue check means the vehicle is confirmed for non-sponsored coverage. Although securities are not available, one embodiment of the system tracks coverage dates and expiration dates. As mentioned above, the circled green "F" refers to future insurance contracts. A green check+F is displayed if the unit is mapped to a current/valid Sponsored Policy and a future policy. If it is a new client and/or a new policy, there is no policy in force, so the "F" designation is useful to know that it maps well to a policy with a future effective date. , a security icon is available for future insurance proofs. If active and future ones exist, clicking on the policy icon will generate both policies, one for the active policy and one for the future policy.

The option columns in area 509 are: Generate Certificate (green circle), Email Certificate (dark blue email symbol), Edit Vehicle gold icon, Transaction/Audit Trail (opposite arrow) and Delete Unit (gold). (X) included. The policy generation icon, when selected, displays one or more insurance policies for the unit. The e-mail icon creates an e-mail with the security attached.

A user can select a filter on the vehicles tab 204 to display only vehicles for a particular client. One embodiment of that interface 600 is shown in FIG. In this view, the client is shown within area 601. A compensation summary is shown in area 602, and area 603 indicates the required response. The user can click on the call to action within area 603 and the system will display only those units that require action.

The objective is to have a Required Action (RN) value of zero, meaning that all vehicles have sponsor-sponsored coverage, non-sponsored coverage, or coverage denial. In one embodiment, the user can click on the RN number on the home tab 201, which displays only the clients that require attention. When the user selects one of those clients, the system displays the RN for that client. When a user selects a client's RN number, the system displays only the rows for client vehicles that require attention. This allows the user to quickly take necessary action.

FIG. 7 shows the interface when "driver" is selected in FIG. 4, FIG. 5, or FIG. 6. Interface 700 includes a field 701 for the client's name, and field 702 indicates the total number of drivers currently employed by the company. Area 703 indicates the total number of OA drivers. Field 704 is the average age of the drivers, field 705 is the average years of experience of the drivers, and field 706 is the geographic location of the drivers (eg, by state).

Area 708 provides information regarding each driver. This area can be reduced to a more limited number of columns as desired. For example, the area may simply indicate vehicle unit, driver name, OA information, and option fields. In the expanded view, in one embodiment, area 708 includes the vehicle unit number (if the driver is assigned to multiple units, no unit number is shown for that driver), name, date of employment, date of birth (and Age), CDL original date (with years), license state, license number, address, contact information (address, email, phone, etc.), OA addition date, and optional fields. The optional fields, in one embodiment, may include icons that provide security, edit, delete, and audit trails.

If the RN field 707 has a non-zero number, the system can isolate the driver with the RN condition when the user clicks on the number in the field 707. The system only displays drivers that require some action.

The RN area within all interfaces provides a practical way to identify and isolate the actions that need to be taken to ensure that requirements are met and the enterprise is compliant. So powerful. This practical solution allows users to manually track action items or perform multiple sort operations to ensure that all action items are found, addressed, and updated. This has advantages over prior art spreadsheet-based systems that require implementation.

As mentioned above, one of the things that needs to be addressed is that coverage is missing from the insurance policy. In one example embodiment, the system is used in the insurance industry, specifically for truck fleet insurance. FIG. 8 shows an example of an insurance policy issued by the system in one embodiment. Securities 800 can be automatically generated by this system. The policy includes an issue date 801, an issuing agent 802, a named insured 803, and a vehicle owner 804, which may be different from the client depending on the circumstances.

Policy 800 includes vehicle 805, unit number 806 (defined by insured 803), and VIN 807 (the VIN is duplicated by a VIN decoder/analyzer to ensure that VIN 807 matches vehicle 805). automatically generated).

Coverages are listed, such as auto liability coverage 808 and physical damage coverage 809. Coverage includes policy number, effective date (which may be different from issue date), end date, limits, deductibles, and actual insurance company. Area 810 contains disclaimer text, and the system expects an electronic signature area 811. This is a specific signature by an authorized licensed producer of the agency attached to the system. If no producer is selected, no signature is required, but in one embodiment, the agency should have a producer selected.

FIG. 9A is an example of a home 201 interface 900 in one embodiment of the present system. The interface 900 includes an RN field 901 showing the RN(V) for the vehicle and the RN(D) for the driver, power units 902, non-power units 903, number of drivers 904, insurance policies about to expire 905, and recent vehicle transactions 906. include. In one embodiment, the home tab may also show recently added vehicles and recently deleted vehicles. The system automatically generates important reports that track net changes in vehicles (new additions vs. new deletions) so that appropriate bill corrections can be made. For example, in some situations, the charge is a monthly "per power unit" fee. Therefore, positive or negative changes in the number of vehicles are used to calculate changes in tolls. For example, if there is a net increase of 7 power units, the billing would be adjusted by increasing the monthly charge per power unit by a factor of 7.

When the user selects RN(V) (one RN is shown in this example), the system displays an interface as shown in FIG. 9B. This is a filter to display only client rows with RN(V) greater than zero (and similarly for RN(D)). The interface includes area 905, which is a filter set to display the RN (but the user can change the filter to display other data). An area 906 indicates clients, and an RN(V) column 907 indicates the number of responses required.

When the user selects a number in column 907, the system presents an interface as shown in FIG. 9C. Area 909 indicates that the filter "needs action." Area 910 graphically depicts the compensation that needs to be addressed. In this example, it is the PD insurance policy that requires action.

Another advantage of the system is the ability to interface with third parties, including the Department of Transportation (DOT). This allows the system to obtain DOT information, FMCSA information, safety inspections, and the like. The system can also integrate transportation management systems and agency management systems. All of these systems have the ability and permission to add vehicles, delete vehicles, and edit vehicles, providing a single system that replaces multiple prior art systems.

FIG. 10 is a flow diagram illustrating the operation of the system in one embodiment. The steps of FIG. 10 may be performed on a client basis, agency basis, etc. At step 1001, the system checks for insurance policies that are about to expire. At step 1002, the system checks for net changes in the vehicle. At step 1003, the system checks for driver changes and updates, including unit assignments. At step 1004, the system checks the security.

In step 1005, the system updates icons associated with system data based on the results of steps 1001-1004. For example, insurance policies and missing coverage that are about to expire will have a red action icon associated with that data. In one embodiment, the dashboard also displays insurance policies that are scheduled to expire soon (eg, within some user-determined time period). Expired insurance policies are displayed within the inactive insurance policies page for access by the user. Attached reports for those expired insurance policies are also accessible. In step 1006, the system updates the action required counter as necessary (based on the deficiency action) and displays the data in step 1007.

FIG. 11 is a flow diagram illustrating a response to a request for action in one embodiment of this system. In step 1101, the user selects an icon indicating that action is required. As mentioned above, such an icon would be a red exclamation point in a circle. At step 1102, the system provides the appropriate interface to take the desired action. For example, the system may provide certificates of completion, reports to generate, emails to send, and the like. At step 1103, the user performs an action.

Decision block 1104 determines whether the procedure is complete. If not, the system returns to step 1103. If the procedure is complete, the icon and RN counter will be updated accordingly.

computer system example

FIG. 12 depicts an example system 1200 that may implement the present system. Electronic system 1200 in some embodiments may be a mobile device. Electronic systems include various types of machine-readable media and interfaces. The electronic system includes a bus 1205, processor(s) 1210, read only memory (ROM) 1215, input device(s) 1220, random access memory (RAM) 1225, output device(s) 1230, and network components 1235. , and permanent storage 1240.

Bus 1205 communicatively connects internal devices and/or components of the electronic system. For example, bus 1205 communicatively connects processor(s) 1210 with ROM 1215, RAM 1225, and permanent storage 1240. Processor(s) 1210 obtain instructions from memory devices to execute the processes of the present invention.

Processor(s) 1210 may be implemented with one or more general purpose and/or special purpose processors. Examples include microprocessors, microcontrollers, DSP processors, and other circuits capable of executing software. Alternatively, or in addition to one or more general purpose and/or special purpose processors, the processor may include, by way of example, one or more FPGAs (Field Programmable Gate Arrays), PLDs (Programmable Logic Devices), controllers, state machines, gates. It may be implemented in dedicated hardware, such as gated logic, discrete hardware components, or any other suitable circuitry or combination of circuitry.

Many of the features and applications described above are implemented as software processes in computer programming products. A process is specified as a set of instructions recorded on a machine-readable storage medium (also called a machine-readable medium). When these instructions are executed by one or more of processor(s) 1210, they cause processor(s) 1210 to perform the operations indicated in the instructions.

Further, software shall be broadly construed to mean instructions, data, or any combination thereof, whether referred to as software, firmware, middleware, microcode, hardware description language, or otherwise. . Software may be stored on or transmitted over as one or more instructions or code on a machine-readable medium. Machine-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. Storage media may be any available media that can be accessed by processor(s) 1210. By way of example and without limitation, such a machine-readable medium may include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or a device that carries the desired program code in the form of instructions or data structures. It may include any other medium that can be used for transport or storage and that can be accessed by a processor. Also, any connection is properly termed a machine-readable medium. For example, the software may be transmitted from a website, server, or other remote source using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared (IR), radio, and microwave. When transmitted over coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Discs herein include compact discs (CDs), laser discs, optical discs, digital versatile discs (DVDs), floppy discs, and Blu-ray discs. -ray® discs, which typically reproduce data magnetically, while discs reproduce data optically using lasers. Thus, in some aspects, machine-readable media can include non-transitory machine-readable media (eg, tangible media). Additionally, for other aspects, machine-readable media may include transitory machine-readable media (eg, a signal). Combinations of the above should also be included within the scope of machine-readable media.

Also, in some embodiments, multiple software inventions can be implemented as sub-parts of a larger program while remaining separate software inventions. In some embodiments, software inventions may also be implemented as separate programs. Any combination of separate programs that together implement the software invention described herein is within the scope of the invention. In some embodiments, the software program defines one or more specific machine implementations that perform and perform the operations of the software program when installed to operate one or more electronic systems 1200.

ROM 1215 stores static instructions needed by processor(s) 1210 and other components of the electronic system. ROM may store instructions necessary for processor(s) 1210 to execute processes provided by the system. Permanent storage 1240 is non-volatile memory that stores instructions and data when electronic system 1200 is on or off. Permanent storage 1240 is a read/write memory device, such as a hard disk or flash drive. A storage media may be any available media that can be accessed by a computer. By way of example, ROM can be used as EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or to carry or store desired program code in the form of instructions or data structures, It can also be any other medium that can be accessed by a computer.

RAM 1225 is volatile read/write memory. RAM 1225 stores instructions needed by processor(s) 1210 during execution, and RAM 1225 may also store real-time video or still images obtained by the system. Bus 1205 also connects input and output devices 1220 and 1230. Input devices enable users to communicate information and select commands to electronic systems. Input device 1220 can be a keypad, an image capture device, or a touch screen display capable of receiving touch operations. Output device(s) 1230 displays images generated by the electronic system. Output devices may include display devices such as printers or monitors.

Bus 1205 also couples electronic systems to network 1235. An electronic system may be part of a local area network (LAN), wide area network (WAN), the Internet, or an intranet through the use of network interfaces. The electronic system may also be a mobile device connected to a mobile data network provided by a wireless carrier. Such networks may include 3G, HSPA, EVDO, and/or LTE.

It is understood that the particular order or hierarchy of steps within the disclosed processes is one illustration of the example approach. It is understood that based on design preferences, the particular order or hierarchy of steps within the process may be rearranged. Additionally, some steps may be combined or omitted. The accompanying method claims present elements of the various steps in a sample order and are not intended to be limited to the particular order or hierarchy presented.

Various aspects of the disclosure are provided to enable any person skilled in the art to practice the invention. Various modifications to the exemplary embodiments presented throughout this disclosure will be readily apparent to those skilled in the art, and the concepts disclosed herein may be extended to other instruments, devices, or processes. . Accordingly, the claims are not intended to be limited to the various aspects of this disclosure, but are to be accorded the full scope consistent with the language of the claims. All structural and functional equivalents to the various components of the exemplary embodiments described throughout this disclosure that are known or later become known to those skilled in the art are incorporated herein by reference. is expressly incorporated herein and intended to be covered by the claims. Furthermore, nothing disclosed herein is intended to be made available to the public whether or not such disclosure is expressly recited in the claims. Unless the element is explicitly recited using the phrase "means for," or, in the case of method claims, the element is recited using the phrase "step for," No claim element shall be construed pursuant to 35 U.S.C. 18(f).

Claims (7)

Within the processing system,
a processing engine;
an import/export engine coupled to at least one source of data about vehicles, drivers, insurance policies and policy coverage;
a vehicle identification number (VIN) decoding system for verifying vehicles obtained by the import/export engine;
a database for storing data regarding the vehicle, driver, insurance policy, and insurance policy coverage;
and a dashboard for displaying information and status regarding said data. The integrated insurance management system of claim 1, further comprising a graphical representation of the state of data associated with a vehicle and a driver. 3. The integrated insurance management system of claim 2, further comprising response required (RN) logic for identifying a required response and displaying a call to action regarding the required response. The integrated insurance management system of claim 1, wherein a call to action is presented to the user to update coverage for a vehicle. 5. The integrated insurance management system of claim 4, further comprising a policy engine for updating coverage for a vehicle and providing a policy of coverage. The integrated insurance management system of claim 1, further comprising an audit engine for tracking operations within the system. The integrated insurance management system of claim 1, further comprising a reporting engine for automatically generating reports associated with the system.

Images