At the core of the system are the Products. Each product is a collection of resources and settings that defines the user interface, rates, and rules for creating a submission and booking a policy.
The Workflow is the user interface for the product, providing multiple screens of forms and tables for the user to create a submission. Each workflow is comprised of fields as the smallest component, which are collected into panels, which are grouped into screens, which are attached to steps in the workflow definition. Special tabbed workflows can be created and assigned to grids, providing a series of tabbed screens for entering large amounts of data into grids.
The Master Cover is the definition of the product, where the resources and workflow are attached, and settings are defined.
Resources are the building blocks for workflows and products. They can be reused across multiple products.
|
Premium Types |
A premium type defines a single source of calculated premium. Each type may represent a separate type of charge on the final invoice. |
|
Clauses |
Clauses are blocks of text that can be pulled into the policy. These clauses may be legal information, notices or warnings, or just additional details on the coverage. |
|
Triggers |
Triggers are conditional structures used throughout the system. Each trigger can have one or more conditions based on system or submission data, and will evaluate as True if the conditions are met, or False if they are not. Triggers can be set to control many aspects of the system, such as the availability of content in the workflow or optional text in printed documents. |
|
Reference Data |
Certain features and fields require lists of options or entire tables of data. |
|
|
Option Lists are simple lists used to define the choices available in dropdown fields, checkbox groups, or radio button groups. |
|
|
Lookup Tables are grids of data ranging from simple two-dimensional tables to complex data structures with layers and versioning. These are used in special searchable fields or advanced calculations. |
|
Document Templates |
The system can send out emails and produce printed documentation. These use templates that can pull in system, policy, billing, and claims data at the time the email or document is generated. |
|
Payment Plans |
A range of payment plans can be configured and made available to users. |
Workflows are assembled from the following components.
|
Fields |
Each field is a single element in the workflow where the user can provide information or select from available options. There are a variety of field types such as text and number fields, date fields with built-in calendars, and fields where the user can select one or more options. |
|
|
Certain types of field can contain formulas that may simply display system information, or may perform complex calculations using functions and conditional logic. These are referred to as Calculated Fields. |
|
Panels |
Fields are grouped together in panels. A panel may be simple form that displays the fields in a specific order, or may be a grid that can accept multiple entries added through a pop-up window. |
|
|
Grids can be structured in hierarchies, where selecting an entry will open additional grids for related data. |
|
Screens |
Each screen is an individual page in the workflow, containing one or more panels. |
|
Workflows |
This is the top level of the workflow configuration. Screens are added to the workflow and can be organized into steps. The user navigates through the screens to complete the submission. |
|
|
A workflow must be published to make it available within the system. If any component of the workflow is changed, the workflow must be published again for the changes to take effect. |
|
Integrations |
The Bridge system can integrate with external systems. These can be configured to activate at specific points in the submission process. |
|
Overrides |
Within a workflow, all fields, panels, and screens have default settings that define how the component behaves, including whether it is displayed or hidden and whether it can be edited. Overrides can be created to change the default settings depending on factors such as triggers, the status of the submission, or even the user's account settings. |
The Master Cover is the definition of the product. The related companies, resources, and workflow are attached to the master cover, and all supporting settings are configured. Once complete, the users can create submissions for the insurance product.
A new master cover will be in Draft status, where the initial configuration is done. The master cover can be set to Test status, allowing sample submissions to be created in order to test the configuration. All settings can still be edited in Test status, allowing adjustments without returning to Draft status. Setting the master cover to Live status deletes all test submissions and makes the product available for users.
The master cover configuration is divided into pages, accessed through a navigation widget to the left of the page. The settings include the following areas:
•Distributor and Insurer companies are attached to the master cover. The Distributor for a submission is selected during the initial creation of the submission, while Insurer companies are assigned during the quoting process, depending on their settings in the master cover.
•At least one Quote Option must be defined, but additional options can be created to provide the user with a range of choices. Quote options can have different settings including rates, limits, and deductibles, or even different insuring companies. Payment plans can be associated to quote options, to be selected by the user when choosing a quote. Quote options can be organized into groups with special controls on how to present the options to the user.
•Rates are defined to calculate the appropriate premium for the submission. Multiple rates can be defined per premium type, allowing flat rates, percentages, multipliers, and other adjustments to be combined, producing a final total premium.
•Taxes and Fees can be applied to collect additional premium for taxes and various fees.
•Limits, Deductibles, and Insuring Conditions can be defined for the product.
•The submission process takes input from the user, and can pass through several stages and statuses before eventually being bound as a policy. The rules to assess the data and guide the changes are created as Validations. For example, a validation may just display a warning, or could send the submission into referral, requiring review by a user from the insuring company. A range of controls are available.
•The email and document templates can be attached to the master cover with additional settings that control when they will be available to the user, or even created automatically.
•Finally, for Pay-As-You-Go business, a payment page can be configured for the user to make credit card payments on binding the policy.
Other pages include general settings that control policy numbering and dates (ranges, backdating tolerance, etc.), calculations and rounding, option lists for use with various features, among others.