Let's talk about how things look with the benefit-centric approach. Under this approach, you have the following:

• Timeframes (eligibility rules) assigned to benefit subgroups

• Billing codes assigned to benefit subgroups

• Plans and rates assigned to benefit subgroups

• Employees assigned to benefit subgroups

This is a beautiful approach for simple groups. For example, take a group that has:

• One set of "timeframe" rules for all employees

• One billing code for all employees

• The same benefits and rates offered to all employees

With this approach, the user can input all of the information for a given employer on just one page within the system. This cannot be done with the employee-centric approach. With the employee-centric approach, building out even the simplest group will take going to a minimum of five pages.

Let's review this second, employee-centric approach. Under this approach, this is what you have:

• Employees assigned to benefit subgroups

• Employees assigned to timeframe subgroups

• Employees assigned to billing code subgroups

• Rates assigned to plans

• Plans assigned to benefit subgroups

Now why would it ever be better to do things this way? Let's take a moderately complicated employer. This employer has the following:

• Two sets of timeframes (eligibility) rules

• Three sets of primary billing groups (divisions)

• Six sets of secondary billing groups (departments)

• Four sets of benefits groups (executives get more life insurance than other employees and some employees are paid biweekly and others semimonthly)

With the second, employee-centric approach, you will need to build out two timeframes subgroups, plus three primary billing subgroups, plus six secondary billing subgroups, plus four benefits subgroups, for a total of 15 subgroups.

With the first, benefit-centric approach, there would be 2 x 3 x 6 x 4 subgroups, equaling 144 benefits subgroups. Yes, that is right, 144 subgroups.

Let me tell you something about having 144 subgroups. You never really feel confident that the system is correct. And when you have to change the system at next year's open enrollment — let's just say "nightmare."

And this is what happened to us in our agency. We began having more and more clients that needed 50 or more subgroups. This was in part because we were winning the trust of bigger employers, but it was also because we started to appreciate more the complexity of even our smaller groups as they insisted on having things reflected absolutely correctly in the system.

Transitioning BerniePortal from being benefit-centric to employee-centric was awful. Imagine: We had to take all of these clients whose employees had logins already and condense their 50 subgroups to five to ten. We had to do this without disrupting the client. The only time it was possible to do it was at open enrollment. We did it over the course of a year, running two parallel systems and code bases that had to be maintained by our developers while we made the transition.

Ugh. Now imagine if we had already had thousands of brokers and employers using our system. If that had been the case, we simply would not have been able to make the migration from being benefit-centric to being employee-centric.

We would have had to continue making "cloning" things easier, and making auditing subgroups against each other simpler. No one would have been happy, but we would have muddled along. We know several products that serve the 1,000+ employee space that are in this position today.

To sum up, look for this. Ask about it. Here is the question:

If a client has a DOH provision for new hires and FOM 60 days for everyone else, offers more life insurance to execs than other employees, pays some employees biweekly and others semimonthly, and for billing purposes has three departments and six divisions, can you show me how that would be set up in your system?

You'll want to see 15 subgroups in that scenario. Two for eligibility rules, four for benefits, and nine for billing. If you see 144, run for the hills.

This column is adapted from the book "Online Benefits Technology: The Strategic Broker's Guide," found on Amazon.