This section contains brief descriptions of stand alone systems, methods and programs that we have installed over the years. Some of these systems, or approaches, were created years ago, and some quite recently. My first instinct was to stick with the new stuff, on the theory that everybody will have thought of the old ones, but experience tells me otherwise. One of the first things I saw at AIL in 1975 was a clerk penciling the name of the applicant onto the tab of the paper policyholder file. A simple program change and the computer printed the labels from the submit information. The hardest part was finding the right size sticker to fold over the tab. So what was one of the first things I saw at AA 25 years later? It was easier finding the right sticker size this time.

Notes

Discussion

Hiring forms for employees and new agents should be available from the web site, and allow repetitive items to typed once and propagated throughout the pages. If the forms are to be completed on paper, these items should be entered before printing.

If an applicant must write his name, address, social security number, and so on 8 times on your forms, you not only look ancient and ineffective, but you show you have no respect for the person's time. These forms are easy to create in a number of vehicles. I prefer Adobe Acrobat, where once the form with the propagating blanks is created, only the free Reader is necessary on the machines where the forms are filled in. While you are doing this, take some time to update the forms themselves. Most have not been read by anyone but an applicant in 20 years or more and are embarrassing, if not illegal.

If you have a paper policy filing system and are not ready to convert to image storage, you can create a computer tracking system that will give you many of the advantages. The key is that files are ordered from the pc or terminal of the user, so the computer always knows where a file is. The system designed at American Income Life is detailed at Mike Dragoo's expert page.

In the described system, the user orders the file by number on the terminal, and if the file is in the file room it is ordered, otherwise the user is told where it is. The main computer periodically sends a set of orders to the printer in the file room, where the files are pulled, the out card placed in the file's location, and the file delivered to the desk of the user. When the file returns it is substituted in the place of the out card, and the bar code on the out card is read, advising the computer the file is now in the file room. This system is very effective for storage. It is much cheaper to store paper files in boxes forever than to decide what to throw away, or to scan. The computer can tell you what box the file is in, and even print a list in order to help you find it.

Everybody had a good correspondence system 15 years ago. Generally these were based upon standard letters with automatic fill with data from the master file. The user usually had the option of changing the standard letter or adding paragraphs. Printing and mailing was usually automatic. A lot of these excellent systems are still there, but have fallen into disuse with the introduction of PCs and Word. Given the option people will type their own letters, possibly inserting paragraphs copied from stored letters, even though it means printing and stuffing the letters.

You lose quality control and efficiency when everyone can make their own letters. The PC makes it easy and whole departments can decide the previous correspondence system "doesn't work anymore". There are usually some shortcomings with the former system, or lack of things like spell checker. You will usually find that it is easy to fix whatever problems there are with the old system, and fairly difficult to get people using it again. In one situation I was told that "it took programming" to change a letter form, the programmers didn't have time, so they were all out of date. Of course, it didn't "take programming" to change words in form letters. It was just that nobody had ever looked to see how it was done.

There may have been some efforts to build a correspondence system based on Word. A better and easier approach would now be to make the process web based.

Check your reinsurance system. The function never seems to fit anywhere and I have never yet seen one that worked properly. Universal life can get tricky with the changing net amount at risk, but even without that, cessions don't get made, the master file isn't accurately marked, and matching to the reinsurance company bills if even tried is a nightmare. If the presence of reinsurance is properly marked on the master file, it should be fairly simple to produce a bill that essentially matches the one from the reinsurer, and therefore very easy to compare and update.

How hard can this be? An inventory of the master file compared with historical retention limits will produce a suspect list of problems. If the net amount at risk is on the file, recapture becomes straightforward, but someone has to do it. In one example, the master file did not identify the presence of reinsurance in every case, and the paper file was only examined by the claims person if the face exceeded the current retention limit. A clerk who had never been involved in reinsurance or claims was assigned to make sure the master file was marked for every case on the bill from the reinsurance company. In a matter of days she identified dozens of cases terminated for death claims, but on which no claim had been made to the reinsurance company. In another company, where cessions were the problem, the company owed the reinsurer over $60,000 in premiums.

Each direct monthly premium billing costs about $.50 . An ACH monthly premium debit costs between $.02 and $.05, and you get all the other advantages of bank draft over direct billing. It is worth a continued intense effort to switch all direct bills to ACH. A notice on the billing or an insert is all most companies do, and it is worth a lot more effort than that.

A program to persuade direct bill policyholders to switch to ACH, or to combine billings, is extra work in the day to day crunch, so do not assume anyone is doing anything about it. Notices on the bill and inserts will only get a few to switch. Programs that rely on the policyholder to take the initiative can only get so far, because many who wouldn't mind switching never get around to it. It makes sense to get assumptive, and notify direct billing policyholders that you are switching them to ACH to save both of your money, and to reduce the modal load on their premium, and to let you know if that is a problem for them. Then switch the ones that don't object. If the drafts don't clear your system will put them back on direct, so you shouldn't have lost anything. And most policies will remain on ACH.

ACH. Each class of transactions where a paper check is coming in or going out of the company should be reviewed and converted to electronic payment to the extent possible. The largest volume will be premiums received from policyholders.

ACH is always faster and more convenient, and about 1/5 the direct cost of a paper check. Postage is a big item. Automatic processing of returned items is particularly important on premium payments. This should include not only the reversal of the update of the paid to date made when the ACH was generated, but the generation of standard notices. Opportunities in addition to premium payments are agent advances and commissions, benefits on policies, and licensing fees.

The cost per transaction for ACH should not more than 3 cents, although the banks asking price will be higher. With volume, you will want to process ACH yourself, directly with the Federal Reserve by wire. That should reduce your cost to about 1 cent per item, plus small fixed fees.

To wire transactions directly and to make and receive payments requires a "depository institution", i.e. a bank. However, transactions can be processed by any entity that is registered as the data processing facility of a depository institution. A local bank that has no significant volume of ACH transactions for other customers will be happy to register you with the Federal Reserve as their data processor for ACH. That will allow you to process transactions directly by wire with the Fed. The bank will receive the cash credits on the Fed accounts. American Income pioneered that approach, as far as I know, and paid the bank 1/2 cent per ACH simply for using their "franchise" with the Fed. The Fed makes an additional charge per item, but that has decreased over time and is now less than a 1/2 cent. If you have trouble finding a bank that doesn't have other ACH customers (that you don't want to handle), try a local credit union. They are unlikely to be processing ACH transactions for anyone else, and would value the fee income.

Another advantage of ACH for premium collection is the ability to automatically handle the processing of returned items. They come back from the Fed over the wire and can be fed directly into your computers, with no need to reduce anything to paper.

At a minimum a returned item should cause the computer to reverse the premium and generate appropriate correspondence. It should schedule the redeposit of the ACH at the time your studies have indicated is the most effective.

For policyholders who remain on monthly direct and have more than one policy, or multiple policies paid by the same person, combined billings should be made wherever possible. Hopefully notices that habitually pay with one check have already been combined. The next step is to complete the detail work cleaning the data on the master file so the prospects can be identified. Then you write the sets and tell them you have identified a money saving opportunity for both of you, and that you will send a combined billing next month unless that will be a problem for them.

You would think that most companies would have already combined all possible billings, but many don't because of the detail work that needs to be done first. How do you know who is the same person, much less who is in the same family? A single letter or number difference in the name or address will prevent the computer from identifying a match. The computer thinks "third" and "third ave" are different addresses. A good procedure is to first run the post office address standardization software on your master file, then list policies in sets of common phone numbers, and after correcting name and address deviations, run more sets of common social security numbers, common names, common addresses and any other matching criteria available, in each instance correcting other fields. You can speed up the manual work by populating a web page with the sets and allowing matches to be identified with a click, and a second click to pick which line of data should be the common data. After that process the computer can identify same persons and persons who live at the same address.

Monthly direct premium billing is expensive, and keeps getting more so as postage escalates. Your policyholder has the same postage cost to mail back a check, and possibly a charge for the check. Many would be delighted to receive the bill by email, and to pay simply by clicking the PAY button. That button authorizes an ACH charge.

A number of companies offer a variation of this service. As you might expect, I think one of the best is American Income Life's Online Billing Program. The site explains the process well and provides clickable examples of billing and pay acknowledgment, so the policyholder can run through the process to see how it works before committing to anything. The total cost of this collection should be about 3 cents, as opposed to at least 50 cents for paper mailing and bank charges. And no handling involved.

Monthly premium checks that match the return document, the "paid as billed", constitute the great majority of payments received, and the process of applying the payment is generally well automated. However, many companies still use a lockbox service, left over from the days when it made economic sense to get the checks deposited as quickly as possible. That required not only a fairly large average premium, but interest rates that made it worthwhile. Most companies can realize a significant cost reduction by applying paid as billed premiums internally.

COMMENT: Mike Dragoo, CIO American Amicable Life. The system we use to handle paid as billed premiums has not evolved much in the last 15 or 20 years. We use a hand held scanner, a keyboard wedge, connected to a PC. The PC program is an Access program that creates a text file for the mainframe collection system. The scanner, currently a Symbol Technologies LS1000, reads a bar code of the collection number which was assigned sequentially as the MF prints the premium notice return document. The only items that go into the batch are those the clerks have determined match the exact amount, so you really don't need the amount or the due date in the bar code, those being unique to the collection number. When I wrote the first PC program and the MF interface we were still on an impact printer, so we struggled with an OCR line. I think it took a month to get it working right. When the laser printers that could do bar codes came along, it got simpler and easier to read accurately. We also found we needed a Standard Register encoder/endorser, see the Bankers Exchange.

Any time a clerk has to match a payment with an amount due the computer should help. On a new application the CWA check has to match the amount the computer says is due when the case is submitted. One check may cover multiple applications on the applicant or family members, multiple months, or be for the wrong amount due to age or other miscalculations by the agent. Entering the check amount and the number of applications associated with it at the start of submit will allow the computer to "use" the money as the apps are submitted and produce error messages and amounts if amounts are left over or short. The entered app count also allows the reservation of sequential policy numbers for the set.

The same principle applies to premium payments received. Checks that match the amount billed are applied by scanning the return document. Amounts that don't match or don't include the return document, sometimes called "odds", must be manually processed. The clerk must first ascertain what the policyholder intended to pay, and then make entry on a payment screen. With computer assistance, the clerk scans the return document (or enters data from the check) to identify the policyholder and enters the amount of the check. The computer applies the premium according to the payment scenario matches the check, or shows all matching scenarios for the clerk to choose.

The simplest common scenario is a premium for which the return document was not included. Another is multiple premiums on the same policy or one premium on all policies on that individual. A payment may also be intended for all associated policies, i.e. on individuals in the same household.

When a policyholder pays on multiple policies, that is your tip off to combine the billing on those policies.

When money is received which cannot be matched exactly to amounts due, the company may blow off minor amounts, maybe up to a dollar or more, to the "overs and shorts" account. A surprising amount of shorts can pile up. A far better system is the policy side fund, which may be considered a premium deposit fund, as long as you enable it to carry a negative balance. That way the policyholder that figures out he can short you a dollar every month just builds up a negative balance which you can ask him for later, or get when there is a claim or cash surrender. The PDF is also a mechanism for accepting odd modes, like weekly or biweekly, when your system will only apply monthly.

Worse than overs and shorts is the suspense account. When you receive money you don't know what to do with, in it goes, often never to be seen again, or maybe never to be identified. If you know the policy involved, the PDF or other side fund is a much superior vehicle. If the policy is suspended, a big cause of suspense account deposits, you can structure the PDF to accept deposits independently. In some systems the PDF is not actually carried on the policy record, but in a side DB.

When you don't know what policy money should be applied to, putting it in a suspense account implies that later someone else will be able to figure it out better than you can today. Today you have the envelop. Most money that hits the suspense unassociated with a policy does so because the clerk is too busy to properly research the item. A better system would be to send unassociated checks to a single desk whose primary duty is to associate the money. Failing that, the desk would leave the best trail possible, and set the money up for pending escheat. The idea is to avoid having suspense accounts.

Knowing that there is more than one policy on an individual, or in a household, is important for multiple reasons, and it should be visible on the screens to everyone handling the policies. For example, a address change may affect all policies in the home, or it may not. You have to know to ask.

The process of making the master file data uniform described above will allow the computer to create side file that sorts all policies by address so that a screen request for one produces links to the other policies in the household. This not only notifies the clerk, but provides one click access to the others.

Some companies provide agents notebook computers to take electronic applications. AFLAC agents do this in group settings where potential applicant data is acquired from the employer and preloaded, and it appears to reduce the time invested in completing the application. Outside of the worksite situation it is hard to see the advantage over the traditional paper app. Laptops are expensive and unfamiliar to many agents, and if the agent is happy with the paper application, why go through the training and trauma? The paper app can be scanned in the agency office and transmitted over the internet. In the absence of preloaded data, the paper app will be faster for 9 out of 10 agents.

Scanning applications in the field office is the easiest way to shave several days off the time it takes to issue a policy, to pay an agent, and to eliminate postage. While you can just email the scans, to do it right you need a scanning program that identifies the application documents in sets and handles documents in the order that facilitates submitting the business. At the home office the images queue up as they come in over the internet and are viewed on the submit operators' monitors. Dual monitors have proved to be the most workable, one for the image of the documents and one for the data entry. For a detail discussion of field scanning and home office electronic processing, see the Bill Fleming expert page.

While some agencies will jump on scanning, others will continue sending you paper. An app scanned at a home office station is indistinguishable as far as the system is concerned from one scanned in the field. The scan station is just another "field location". Whether the agency scans or mails paper, it is all a scan by the time it reaches the submit operator. For the agent the advantage to scanning goes beyond the day or two saved by instant transmission and the postage. If he is using fed ex, he bunches apps for several days (for more delay) to get enough to be worth sending. To know something is amiss on the app or the associated paperwork the same day is also a big advantage.

The electronic application (as opposed to scanning paper) would be expected to reduce the amount of information that has to be manually submitted, as the data can be imported, something not available when the app is scanned in the field as an image.

Experience indicates that reduction of submit time by importing fields from the electronic app may be surprisingly difficult to realize. At American Income when the volume made it impossible to submit everything before the cutoff for advance, we resorted to a "short" submit, entering just the data required for advance. The expected reduction in final submit time due to the already completed fields did not materialize. The operators spent as much time checking the previously completed fields as they would have entering them in the first place.

When a check is collected with an application that is scanned to the home office, keeping the money with the check requires a form of check truncation, and a clear explanation to the applicant.

Here is one set of agent instructions I have used, and a suggested combination back draft authorization form. Note that the applicant is authorizing a one time ACH for the initial premium. The attaching of the voided check is a usual practice, but has a very special purpose here. Writing out the full check for the CWA is an important psychological step for the applicant that you do not want to short cut. The writing of the check makes it clear to the applicant that he is parting with money for the first premium.

COLD is defined by Webopia as the "Acronym for Computer Output to Laser Disk.The storage of data on optical disk, such as CD-ROMs. Storing large volumes of data on laser disk, as opposed to microfiche or microfilm, lets the user access and search this information on a computer, avoid the duplication and security costs of protecting physical documents or film, and more readily distribute information.

Microfiche once looked like an effective way to store the mass of data produced by the mainframe, when compared to paper, but it became a huge expense when compared to COLD, computer output to laser disk. With the internet and web technology, COLD has evolved from search and display on internal terminals to the same availability on customer's remote PCs. A quote from the linked article:
Like most technologies that manage and distribute information, these solutions are migrating toward the Internet. Intranets and extranets are commonplace in most companies. And, they use a standard browser that allows people to work in a common interface. "A true thin client requires you to use HTML, XML (extensible markup language), or a similar standard. Now, we can deliver COLD data through a standard browser in a standard format," ...

Computer edits can save a lot of input errors, and are simple to create, but you seldom see them used to their full capacity. The secret is to find matches. Two independent items that have to match. A simple example is the agent number, which is easy to enter incorrectly. If you also enter the first two letters of the last name, and have the computer tell you if that combination does not exist in the agent file, the odds against a bad entry become enormous.

Edits that come with commercial software usually test conditions, e.g. whether an agent is licensed, whether a policy is approved in a state, or whether a premium amount meets the policy minimums. These are examples of error detection using parameters in the plan description file. Occasionally you can create a useful edit on a single input, such as requiring so many digits or a letter in this place, but the real opportunities lie in matching, such as a policy number against several letters of a name. It usually pays to create databases just for that purpose.

A related technique is to facilitate entry by completing fields automatically from a controlling field, such as the city and state from the zip code. Likewise when multiple applications are received on the same person, or in the same household, selected common data should be acquired from the first entry screen and used to populate subsequent screens.