The Agency Database

THE AGENCY DATABASE

by Tripp Leach

Are your computers a fundamental part of your agency or just desk ornaments? Do they provide you with a competitive edge or a convenient excuse? Do they add to your bottom line or subtract from it?

You can consider automation an integral part of your agency's business plan only if you're using it to increase sales, implement marketing programs, improve productivity, and contain or decrease expenses.

The key to every full-function agency management system is the database. A database is the sum of the information an agency needs to conduct business with its clients and companies. In the non-automated agency, the database consists of paper files: the manual logs, rolodexes, invoices, accounts receivable, accounts current, and so forth.

Each agency's database is unique. It normally contains information in the following areas:

• clients
• policy details
• prospects and suspects
• policy rating
• billing and accounting data
• claim details

A computer system with this information serves as a single source of support for all of the agency's activities. But how do you load the data into the system?

The easiest, fastest, and most accurate method is 'downloading.' To download is to transmit data from one system to another. (It's also the key to benefitting from interface and a major step toward SEMCI, or single-entry multi-company interface.) Downloading is a proven way for your agency to build a full policy database quickly and at low cost. It processes renewals and policy changes without re-entering data, diminishing the chance for inaccuracies to creep in. The staff's workload is greatly reduced, even if you want to add more data later.

Say, for instance, you want to transfer records from the company database to your agency's. The company will send your agency an electronic record for each policy you have with that company. The first time the company sends you the policy records is called initialization. Each record you receive contains, at a minimum, the information that would normally appear on the policy declarations page. Moreover, any time a company changes its policy, it will send you the changed record, which you can download into your database.

A company can send the information in its initial download via telephone line or disk. Obviously, your system vendor will need to be involved in this process. The two communicating computer systems must be compatible. Use of ACORD standards greatly simplifies the transferal. Once the data has been downloaded to the agency's database, the job is not over. The database will probably require some additional information before your agency can use the information.

A company might not include information you need for underwriting, prospecting, marketing, or management. For example, information on a customer might include only mailing data, whereas you want spouse names, occupations, dates of birth, home/office telephone numbers, information on other family members besides the named insured, and references to other policies you provide the customer.

A company might also be unable to download all the lines of business you write for that company. You would therefore have to enter the details manually for non-automated lines and non-downloading companies. Consistency of data also can be a problem with download. You will probably not get the same data from all companies, and if you do, it might not arrive in the same format. This, too, will become your manual task.

Although downloading is the best way to acquire a policy database, it's not yet available for every line of business, nor from every company. When this is the case, you can fall back on manual data entry. Two methods of manual entry are used by most agencies: occurrence and crash loading.

After loading, the paper file should be marked in some way to indicate that the account is on the system and must be accessed electronically. This is usually done by stamping the policy with the word 'loaded.' Once an account has been loaded, it should be kept up to date. If it isn't, you will have created a monster for yourself, since you won't know which database (the agency system or the paper file) is correct.

Personal and Commercial lines files do not need to be loaded at the same time. Even when they are loaded simultaneously, the activities that trigger them may be different. The most common activities to trigger occurrence loading are:

Occurrence loading has advantages and disadvantages, which must be weighed before you can settle on the best method. The advantages are:

The disadvantages are:

The advantages of crash loading are:

The disadvantages of crash loading are:

Crash loading is generally accomplished by either agency staff or temporary personnel. Agency employees are most familiar with the accounts, of course, so they are best suited for deciding how to handle exceptions. Crash loading also helps them to gain valuable experience working with the system. Crash loading by department CSRs or producer-CSR teams allows problems to be contained and adjustments made easily.

Special times should be set aside for database loading: Mornings before the agency opens, evenings after the agency closes, and weekends are good times. To avoid overtime or to shorten the loading period, you may even consider closing the office one afternoon a week (with appropriate notice to your clients, of course).

The advantages of crash loading by agency personnel are:

The disadvantages of crash loading with agency personnel are:

Temporary personnel hired to crash load will require training on the agency system; they will normally perform better if they also receive some insurance training, too. Since the keyers need to know where to find the information in the paper file to fill in the agency system screens, it may also be beneficial to have them begin by spending a few days matching declaration pages to system screens.

As an alternative, they can use an input sheet. The basis for the input sheet is a printout of each database input screen. A CSR reviews the file to be entered and fills in the input sheets with the appropriate information. This technique allows the CSR most familiar with the account to make the important decisions while a temporary worker keys in the data. This may be especially practical for Commercial Lines, but requires additional work by CSRs.

When the keyer is ready to begin, files may be input in any order logical for your agency's organization. The keyer's speed will increase with experience. Once familiar with the system, the keyer should be able to enter 50 to 60 Personal Lines policies daily. Input of Commercial Lines policies is harder to predict because of their complexity.

The disadvantage of using a production keyer is that you are dealing with someone unskilled in insurance. The keyer will need close supervision to ensure that data are properly entered. Another drawback of using temporary keyers is that CSRs may take longer to feel comfortable with the system, since they haven't gone through all the loading.

The advantage of crash loading with temporary personnel is:

The disadvantages of crash loading with temporary personnel are:

Obviously, there is no single best way to convert paper files to electronic files. In addition to system parameters and agency objectives, factors such as agency size, mix of business, and premium volume will affect how you load the database. Many agencies combine the methods discussed here to meet their needs: For example, they may download a significant portion of Personal Lines accounts, crash load the rest of the Personal files, and occurrence load the Commercial files.

Before setting up your database, you must determine how you want to use your system and what you intend to get from it. Most agency principals say they intend to use every function in their agency management system to its fullest potential-that is why they bought the system. However, every system-utilization survey I've seen indicates that people actually use less than 50% of their systems' capabilities (the only exceptions are accountants, who use around 80%). Some of the ways to use your system's database are:

• customer service
• cross-selling
• production analysis
• management reporting
• loss control
• company interface
• new business prospecting
• account rounding
• target marketing
• claims analysis
• risk management
• cash flow management
• proposal generation
• account surveying

The basic framework for database design is set by the system vendor, but within that framework, you have a number of decisions to make about what data to enter and how to enter it. These decisions will serve as the basis for the overall use and productivity of your database. The decision-making team should be composed of top management, the sales production group, the agency accounting group, claims staff, and the customer service/policy processing staff. This team should work with the agency's operations manager to plan how the database will be created, implemented, maintained, and used.

When reviewing the paper files, the design team should determine what information the paper files currently contain, what additional information should be included in the files, and what information you do not have (or do not use) today but will be able to use because of the computer's superior ability to assemble data.

To accomplish your objectives in creating the database, you must be able to retrieve the information after it is entered. For this to be possible, everyone should enter data in the same way, in the same place on the screens, every time. Before data entry begins, the design team should make the necessary decisions concerning the standardization of information, which is the single most important factor determining the success or failure of your agency's use of its database. Some of the items you will want to standardize are:

• numeric entries
• customer name format
• coverage codes
• dollar amounts
• policy number format
• date format
• line of business codes
• department codes
• coverage codes
• claim cause codes

Management should also decide in advance who will be responsible for consistent input. Consistent checks and tracking mechanisms must be designed and put in place to maintain data integrity.

The following example may help you understand the importance of determining which data to input into your database. Years ago, when we were first loading our database (we used occurrence loading until approximately 80% of our files were loaded, and then crash loaded the balance-all with agency staff), we reviewed AMS' Homeowners screens and found that we had the ability to input not only the fire protection class code (ISO codes 1 through 10) but also the responding fire departments' names. We made the decision to load both because we thought we might need the responding fire department's name sometime in the future. Several years later, one of our bedroom communities experienced an improvement in their fire protection class from 8 to 6. This presented a problem and an opportunity.

We decided to endorse our Homeowners policies in the community to reflect this change and reduce their premiums. In addition to serving our customers, we hoped to use the endorsement as a marketing tool to obtain referrals from existing clients. It became our challenge to use the system to accomplish both objectives. This bedroom community, although it was a different city, did not have a distinct ZIP code or use the community's name in its mailing address. The only way to locate the policies was by responding fire department name-which, fortunately, we had entered when initially loading our database.

Because we had the information in our database, we were able to locate the policies automatically, merge the information to both policy-change requests to the various writing companies and in individual letters to our clients congratulating them on the improvement, advising them that we were already endorsing their policies (so they didn't have to call us to ask for the change and return premium), and also asking them to tell their neighbors what we were doing and to call us to find out how much we could save for them.

The result: We wrote over $50,000 in new Homeowners premiums in the community directly form this one change. Not a bad payback for having the right information in the right place and knowing how to use it!

According to ACORD, a database is your agency's power plant. Fill it and use it completely, and you will be handsomely rewarded.

Portions of this article are reprinted with permission from 'Your Agency Database,' published by ACORD.