COMPULIFE ® Software, Inc.            Canada Homepage            (800) 798-3488


                      Click Here to Print This Bulletin

Update News for November 2012    


Here is a quick run-down on what you will find in this bulletin:

These topics will be dealt with in more detail throughout this bulletin.


Price Changes in U.S.

Everything about price changes in this bulletin applies to price changes in the U.S. and NOT in Canada.

The introduction of Partner pricing ONLY applies in the U.S. Canadian agents already pay $149 per year, whereas U.S. agents pay $199. The new partner pricing allows U.S. agents to get the same price as Canadians if they buy 2 systems.

The listing price for www.term4sale.ca remains unchanged at $12 per year. We don't feel we have had as much success with google and yahoo adwords for Canada and do not think it is the right time to ask our Canadian subscribers to put more into the pot.

We are providing you with the following information so you don't think we are asleep at the wheel. Even so, it is a nice review of what we are thinking and for that reason you may find it informative.


Compulife Introduces "Partner Pricing" in U.S.

Currently a personal use U.S. subscription to Compulife is $199 per year. The standard license (for agencies) is $299. The software is the same, the difference is simple.

Agents get a "personal use discount" if they agree that they will NOT give quotes to other agents. To deter an agent from violating the discount agreement, and in addition to the agency name which is locked in and appears in the top left corner of all printouts, the agent's name is also LOCKED into the software.

In the standard license the agent name is left open and any agent name can be filled in and quotes provided to multiple agents. IMPORTANT: The licensee cannot give the software to other agents. The quote produced by the software can be given to other agents.

A standard license is LOCATION bound, and can be placed on up to 5 computers in that single LOCATION. That also includes laptops, which can have the software on them, providing that the laptop remains in the office. We have extended permission for ONE laptop (of the 5 total) to be used out of the office when that is requested in writing, but we will ONLY do that for one laptop.

If the agency needs more than 5 computer, it can purchase a sub-license for $199, which will allow another 5 computers.

A personal use license is AGENT bound and may be installed on any computer that that agent uses or that is used by an un-licensed support person to that agent. The software is not location bound meaning that the agent can use it anywhere and everywhere as long as it is used to benefit that one agent alone.

The new partner pricing allows two personal use subscriptions to be purchased at the standard license pricing. If you have a partner who is a licensed agent, then the two of you can have two personal use editions for the same as the standard license price, a savings of 50% on the second license. The discounts compound if you purchase more than a single year subscription.

In order to receive the "Partner Pricing" discount, the invoice for the two systems must be to one of the two partners - we do not invoice individually. The two personal use editions will be treated as separate personal use accounts for all other purposes.

Each agent (partner) will receive two free zip code listings at www.term4sale.com. Each agent partner can buy additional zip codes in their name. Each agent partner can load on as many computers as they each use or that are used on their behalf. If they have a single staff member who does work on both, then the two personal use editions can both be put on the same staff members computer. Each partner will have their own mobile editions (FREE), each with their own control panel and limit of 3 devices (each).

Existing subscribers, who are partners, can take advantage of the pricing at the next renewal of either individual. We will need to adjust the second partner's subscription so that both have the same billing anniversary. At that point you will determine which agent is the person being invoiced. How you divide the billing is between you.

Our hope is that agents will recognize the opportunity to cut their pricing in half, by finding another agent to share the cost. Without a partner your price is $199 per year. With a partner your price drops to $299 divided by two, which is $149.50. When you take into consideration that both get two free listings to www.term4sale.com (a value of $30 each per year) then the effective cost of software is just under $10 per month.

The thrust of the new pricing is to increase the number of individual agent users. If lowering prices will increase our subscriber volume, we are happy to lower prices. If lower pricing only translates into the same volume of customers, with merely a reduction in revenue, then it's the wrong direction and we will need to re-evaluate.


U.S. Term4Sale - $15 Listing Prices For 2013

Earlier this year we announced that we would be increasing listing fees for Term4Sale. Our original proposal was to raise the prices for zip code listings where a subscriber was buying listings in states outside the state where they were actually located. We heard from some who labeled that unfair. They said it was unfair because we were proposing a 50% increase in listing fees from $12 to $18 per year, and it was unfair because those in smaller states, who did business in multiple states, would be impacted more than agents who reside in larger population states.

We took that criticism seriously and so we decided that we will simply increase listing fees across the board by 25%. Paid listings will be going from $12 a year to $15 per year. When we first announced that increase last month, we did not have any of the same reaction that we had to our first proposal.

While no one will be happy that there is a price increase, and while 25% may seem high, we would like to remind everyone that we have not raised the fees a penny since the paid listing program was first introduced in the late 1990's. In fact if you go to the monthly bulletin archive and you go back to the U.S. Update New for July 2000, you will find the following (remember, this is from July 2000):

So while this is a 25% price increase, it amounts to less than 2% per year from the time we first allowed agents to buy additional listings at www.term4sale.com.


Term4Sale - Important To Some, Not To Others

In raising the prices we realize that some agents will not renew their paid listings, or may cut down on the number of paid listings that they have. But that has become necessary anyway. If you use the Term4Sale Zip Code Analyzer, and start looking for available zip codes near you, you will see that for the most part the best zip codes have been taken and have 3 people listed. If someone else wants to get in to a better zip code they can't.

Because the fees are so nominal, the price is no longer a way to determine if the agent buying the listing is doing so because term4sale is really valuable to their business, or it is just such a no-brainer bargain that it doesn't really matter. The cost is so nominal (really token), that even if a subscriber got one sale every 3 years from a single listing, that is still highly profitable.

And we know that leads can typically cost $30 to $40. We also know that the consumer contacts generated by Term4Sale are superior to leads that agents buy. So even one sale every 3 years (cost of $36 at the old price) was just too fair.

Then there is the flip side of the coin. From time to time we hear from agents who complain that they are not getting the insurance buyer contacts that they used to get, or think that they should get, from their listings. Part of the problem is the increased volume of actual listings which subscribers have bought. It's like taking a roulette wheel, and adding more numbers. Your chances of hitting your number goes down when there are more spots on the board.

If the higher price reduces the total number of listings, then the same number of consumers using term4sale will result in more contacts for subscribers. Looking for agents from a smaller group of listings means more contacts per listing. We believe that for agents who really value the service, getting more contacts is more important than paying more for zip code listings. We'll certainly find out with this price increase.

Which takes us to another point that we have tried to make from the beginning. We would prefer that ALL subscribers benefit equally from listings at www.term4sale.com. Remember, every subscriber to Compulife gets two or three free listings at Term4Sale, as part of the price that they pay for their software subscription. We always wanted those free listings to generate the odd insurance sale for our subscriber, with the hope that it became just one more reason to subscribe to Compulife.

And with listing prices increasing to $15, it means that a personal use copy of Compulife now comes with $30 worth of listings in the $199 price (which is NOT increasing). The Agency subscription to Compulife, which costs $299 (price is not increasing) now comes with $45 worth of zip code listings. So if there are fewer paid listings it means more chances of business for each of the subscribers who do not buy additional listings, which reinforces the benefit of being a subscriber. And in case anyone has forgotten, we rely upon the sale of software to be in business, which was what TermSsale was all about in the beginning: adding value to being a Compulife subscriber.


Term4Sale - A New Method Of Advertising

We have completed some experiments with Google and Yahoo adwords by both increasing our monthly budget and increasing the bid amounts that we offer to have our ads appear on Google and Yahoo. Both companies were quite happy to spend that additional money, but we really didn't see much "pop" in terms of increased consumer requests for agents.

We are not sure why, but we think that that we have hit the "laws of diminishing returns" meaning that paying twice as much does NOT create twice the benefit. When your advertising budget is limited (remember, zip codes are only $12 each per year) it leaves you handicapped at what sorts of advertising you can do. It is plain to us that while the adwords are good value at the current budget, we just don't think boosting them is going to do that much good

As we have thought about what else we can do to promote the site, we think we have hit upon a potentially great way to generate more consumer contacts for subscribers. We are calling this the "Term4Sale - Financial Professionals Referral Program".

In regard to that, we have come up with a DRAFT email promoting the new service. Here it is:

We say this is a "DRAFT" because we would invite your comments with respect to the idea. Please email your thoughts to service@compulife.com. Do you think it will work? Should we modify the idea?

Once the service is ready to go, we will begin doing mass emails to financial professionals. We'll see if we can get participation in the idea.


Can You Help Us Promote Term4Sale?

But there is a way for you to also participate in promoting this to financial professionals in your area. And in conjunction with that, we have a referral offer for you.

If you are instrumental in getting a financial professional to join our www.term4sale.com/referraloffer program, we will give you 3 free zip codes for one year. That's $45 worth of zip codes. Find two professionals, get 6 zip codes - etc. There is no limit. 3 free zip codes for each financial professional that adds our quotes to their websites. And yes, we will check to make sure it's a bonafide site.

But don't just do it for the free zip codes. REMEMBER - YOU are listed at www.term4sale.com/referraloffer. If you get your local CPA or Financial Planner to add the quoter to their website, and one of their visitors goes looking for an agent to buy life insurance from; BINGO - it's you.

Why shouldn't you just try to get them to refer people to your website? Remember, www.term4sale.com is to the life insurance industry what Kelly Blue Book is to used cars. Compulife does not sell life insurance. Term4Sale is an objective, unbiased source of comparative pricing information about term life insurance. These are claims YOU can't make, these are claims that we can make.

Further, because Compulife does not sell life insurance, we can engage in promotional activity and pay referral fees that you may not have the liberty to do because of licensing restrictions. Compulife does not sell life insurance - we aren't licensed.

Can you help us help you?

Remember, 3 free listings for 2013 (a $45 value) for each professional that you refer to Compulife who places the "Instant Term Life Comparisons" on their website.


Introducing New User Interface To Data Entry Tool

Work continues on the following, which we published last month.

This month, before beginning step two in our data conversion process (see last month's discussion which follows) we took some time out to review some of the new user interface tools that have been more recently introduced into the market. We felt it was important, before investing a lot of time and effort into this big new project, to see what other products language vendors are offering for creating user interfaces.

Our basic quote engine is written in C++, which is a very common, very power development tool for computer software. All our various and current product offerings, Windows, Linux, Windows Server, Palm and Windows Mobile, rely upon the same fundamental C++ language code in order to do the lookups and calculations in our software. C++ language compilers, for different operating system, are widespread. The C++ language is the most generic way for us to provide software for these different hardware systems.

The C++ part of the software is what we refer to as the Compulife "engine". When someone purchases our internet "engine" for use on either a Linux or Windows based server, they are for the most part getting the engine. The only thing that is added and compiled into the code is a thin layer of additional code that lets it interface with the html pages that talk to it. The engine can be called from a web based user interface (html) which passes to the engine the client variables. The engine then returns the results formatted by another user interface file called the template (more html).

The user interface that talks to the internet engine is written in html code, which is the same code that is displaying this bulletin. That code can either be plain and simple, or it can be a lot more exotic, all determined by the developer who is designing and manipulating the pages that talk to the internet engine. We developed our internet engine so that the most basic html code will work. While there is more exotic web development software than html, such software all respects and can talk in html, which makes our internet software super flexible and something that will work with just about anything a web developer wants to program with.

When we develop our own applications, that rely upon the internet engine, such as Term4Sale or the mobile or web quote options that we provide, the interface is always html based. For more sophisticated work we use PHP which is a more interactive, stepped up version of html. We keep it as simple as we can to ensure that the web based software will work well on all browsers in the market.

The problem with folks who develop with more exotic web based tools, and who create much more complicated web pages, is that all browsers may not run the pages the same way, or in some cases may not run them properly. The simpler the code, the better your chance of not having problems with different browers.

The html code is essentially what is used to create the "user interface", the part the user sees and works with. When someone clicks a "submit" or "compare now" button, the code calls our interet engine and passes to the engine the information it needs to calculate results. None of that is visible to the user, and because it is not visible, the user interface is external to our software. The part you don't see is what we call the engine.

All that to say that we are completely devoted to doing our engine work in C++; that is not changing. What we have been studying are tools for creating user interfaces.

In that regard the Compulife Windows software actually is a combination of both the engine and the user interface which is also developed by us. The Windows based user interface is compiled and combined with the engine into a single program file. That program file (GOWIN.EXE) will only work on the computer operating system that it was built for, in this case Windows XP or a newer version of Windows such as Windows 7. That same software cannot and will not work on another operating system, such as Apple or Linux. The only exception is for the user of an Apple or Linux computer who has installed a Windows run-time emulator that permits Windows software to be run on that computer.

When we build the Palm and Windows Mobile versions of our software, we had to stop and create user interfaces for those operating systems. Those programs do not work on anything but those operating systems and devices that use those operating systems. Of course no new devices being sold in the market use those operating systems, making that software defunct. We still support it (for now) because some customers still have those devices, but we will not be making any changes or improvements to that software.

And while Palm and Windows Mobile operating systems still exist in the market for new devices, those new devices are using new operating systems that do not work with the old software.

Which brings us to Apple. If we wanted to program for an Apple, the problem is that we would have to develop a completely different user interface than the one that we now use for Windows. But if we did all that work, and got a product for Apple, we would be in trouble is Apple changed their operating system and it no longer ran the old program. We would have some customers who have the old Apple computers, still wanting to run that software, and other customers wanting new software for the new Apple computers. And Apple, unlike Windows, doesn't feel it needs to have old software run on their new computers.

The only alternative to having to do all that, would be to use a language tool for the user interface that could take the same user interface code that we wrote for Windows, and allow it to be re-compiled for an Apple. Our current tools do not allow that.

So the question we have asked ourselves is whether or not some other language vendor has created such a development tool that we could upgrade to. The answer is that there are several which purport to offer such tools. The next question is how good are those tools and how well do they work. Of course the sales folks will all say that their tools are great and work perfectly, but you really don't know until you actually spend some time messing with them and testing to see if they perform according to advertising. From our experience few ever live up to the advertising promises which is not surprising. Why do people buy Consumer Reports magazine? They buy it to find out which coffee makers actually make good coffee. Unfortunately Consumer Reports is not reviewing language tools.

And so that is what we spent some time doing in March. Our conclusion is that none of the most promising tools really do a better job than those that we are currently using. While some show promise for the future, at this point we have decided to stick with what we have.


First Small Step Completed
In Data Entry Conversion

This bulletin, and the next few monthly bulletins, may be of little importance for many subscribers. We are currently focussed on making changes to the software that we use to maintain the data in our system. If all goes well you should not notice anything for the next few months, perhaps a year.

So why bother you with any this? The reason is that we don't want you to think that we have slipped into a coma or gone on an extended vacation. We remain quite busy advancing and improving the software. The problem is that the work that we are doing now is not something that you will see any benefits from for a longer time, perhaps a year. So for those who are curious, we will try to let you know how it's going. For those who don't care; please carry on. If we do make a change to the software you use, it will be at the front of future bulletins.

In that regard the first small step of the data entry overhaul has been completed. We have taken our old DOS rate entry tool, and have now re-compiled it and have it running in a Windows 32 / Windows 64 environment.

That's right, I said our old "DOS" rate entry tool.

As we have tried to explain previously, most of our work over the past 15 years has been to enhance and modernize the quotation program(s) that our subscribers use. The main program is Windows based (GOWIN.EXE) and already runs quite nicely on Windows 32 (Windows XP and Windows 7) and Windows 64 systems (Windows 7 only). We also support Windows and Linux servers for the Internet version of Compulife.

By contrast, the tools that we ourselves use to enter and maintain the data files have largely remain DOS based. There was no pressing need to upgrade those because they have been working quite well. The old rule, "If it isn't broke don't fix it", applied quite nicely. However, it only makes sense to upgrade those old data entry tools at the same time as we are doing a major overhaul to the data structure. The overhaul necessitates major changes to the software, and requiring our programmer to make those changes using old development systems and tools is just the wrong way to go. No one wants to go back to a manual tools after getting used to working with power tools.

So the first objective was to get those old data entry programs re-compiled and operating under Windows 32 so that they will run on both Windows 32 and Windows 64. In that regard our old DOS software will not run in Windows 64, and because our programmer's development system works best in Windows 64, we needed to do an intermediate step. Conversely, the new Windows 32 version of the DOS software, which now runs in Windows 64, will not run in DOS. Therefore, the change that we are making means the new software will require us to say goodbye to running anything on a DOS based system.

No doubt you will think "it's about time" but for those who are familiar with the historical versions of Compulife, we still need/want to have the ability to work and function in DOS.

The reason is that all our oldest historical programs are DOS based. If we were to move everything to Windows 64 systems internally, we would not be able to do anything with those historical files.

You have the same problem if you were to order our historical CD for $99, which gives you monthly copies of Compulife back to the early 1990's. If you are running Windows 64, you cannot use/run those old DOS programs on a Windows 64 machine. Why? Because Windows 64 will not run DOS software which is why I personally still run Windows 32. Windows 64 can run Windows 32 software, but Windows 64 software will not run on a Windows 32 computer.

Our programmer runs Windows 64 because the latest development tools work better in that environment. And there is no doubt that all equipment will someday be Windows 64, so the time is right to move our data entry software to Windows 32, so that it will work in Windows 64. It is also easy to move Windows 32 software, to Windows 64 software, if or when that day ever comes.

Knowing that all this was coming, I had personally moved from a DOS based machine for basic data entry, to a Windows based machine, over 2 years ago. That Windows machine is a Windows 32 machine which happily runs the old DOS software. That system will remain Windows 32 until it has to be pried it from my cold dead fingers. That will let me work and operate in both the old and new world. Once everything is Windows 64, the old DOS stuff will be dead. We will have to keep some old computers around to run it.

On another side note, you should also know that our data entry system is isolated from the web. That is to ensure that nothing can get at it. Apart from protecting ourselves from theft of software, we are anxious to ensure that there are NO viruses in Compulife. Virtually all computer viruses today are web based and web transmitted. By isolating that machine from the web it means nothing can get to it.

The process of re-compiling software for a different operating system is always a pain in the butt simply because the code that was written for one OS (operating system such as DOS) always ends up being somewhat different for another OS (such as Windows 32). What we try to do with the various products that we support is to refine our code so that we make it as "generic" or "vanilla" as possible. That way, whether we are compiling for Windows, Linux or whatever, it requires few if any changes. It also ensures that the next operating system we choose to move on to is as pain free a transition as possible.

Of course that kind of refining has not been going on with the DOS based data entry program that we use in-house. In-house we control the operating system environment and don't have to worry about having multiple variations for multiple OS. Even so, now that we are going to convert from one data structure to another, it is important to upgrade our data entry program so that we can now use the latest language tools and compilers that we are now using for the Windows program that you receive. It also means less tools our programmer is forced to use, making his job much easier and resulting in higher productivity.

So the first step we decided to take was to convert the existing DOS tools to Windows 32. That is now done. But the new program really looks like the old program because it uses the same old-style DOS interface (the stuff that you see on the screen).

This takes us to the second step, where we replace the DOS interface with a new Windows interface (what we will see on the screen). This will take much longer, as menus and screens have to be re-constructed from scratch in a completely different environment. And this is the part where we slow down and take our time because the new Windows interface will let us reorganize the way that we work with the data on the computer screen. That will make the addition or change of companies and products much easier.

This re-organization is also important to get right as it will be the bridge between the old and new data structure (from the human point of view). When we do the third and final step in conversion of the data entry tools, the look and feel will remain the same. We will have the new look talking to the old data structure, and the same new look talking to the new data structure. The third step will change the way that the numbers are stored and managed internally.

We will also have a conversion system, letting us convert old files to new. But we can't trust one time conversions to include everything or be bug free out of the can. So, we will continue to maintain the old data, convert it, then make sure it works properly with the new program. Then, we have to test and ensure the new data tools, talk to the new data, and ensure there are no bugs there. Only after a few months of that process can we be comfortable in abandoning the old system.

Incidentally, the current (old) software is called GOWIN.EXE. The new software will be called CQS.EXE. CQS will do everything GOWIN does now but it will do it talking to completely different data files. For a period of time you will actually have both systems on your computer and we will maintain both, until we are completely certain that CQS is working flawlessly, and that the new data entry tools work perfectly.

As we have tried to explain, none of this will produce any change in what you currently have or see. The goal, in converting from old to new, is to ensure the integrity of everything that we have now, and to ensure that none of that is disrupted or lost when we move to the new system.

Once the changeover has occurred, our job of maintaining the data will be much easier. The new structure will then serve as the foundation for adding a lot of new feature and capabilities that will make the software better for you.

Some of the early benefits will seem subtle but you will find them helpful. For example, sometimes we have to duplicate a product entry to deal with state specific variations. With the new system such redundancy will be eliminated. State variations will be something that we can better control internally within a single product entry. Currently we can only manage maximum ages on a state by state basis, whereas the new system will eventually allow us to handle all sorts of variations by state. The benefit for you will be shorter/tighter lists of products without cryptic notes indicating the differences between the multiples of products stored.

Preferred plus product entries will be completely joined to preferred and regular product entries, cutting down the number of product entries in the system. While we have partially disguised this with our "product family" concept, there are still multiple product entries when reviewing lists of products and/or working with state/province approvals. That will be streamlined with the new software program.

The new data structure will also focus on eliminating rate duplication. In the U.S. YRT renewal tables are currently stored for each and every term product, even though many of those renewal premiums may be the same YRT tables for 10, 15, 20 and 30 year versions of term policies. Those YRT tables will eventually have their own storage system, and will be co-shared by multiple products, thereby cutting down duplication and storage. This means our rate tables will shrink significantly, making premium lookups much quicker.

We realize that some of this talk about "faster" may sound silly, given how well our software already performs, but as more and more of our software is used on internet servers, with multiple requests for quotes happening at the same time, the tighter and faster that we can make our data, the faster the software will run and perform, even under high demand situations. At the end of the day, no one likes to wait for something to be calculated and we intend to keep our software super fast.

Of course if anything needs to be addressed in the current Windows program, during this infrastructure transition period, we will see that it gets our immediate attention. But you can appreciate that right now we are not looking to make significant changes or enhancements to the software until the data has been fully converted.