ABS went by a different name when first established in late 1994. A name change occurred after we discovered our product, and company name were in conflict with another software company that produced a completely different kind of product. Although we would have prevailed in a legal dispute we changed our name. That turned out to be a blessing. The name change happened in 1996, and Agency Business Systems, Inc. was born. I think our lawyer said something like: “I won’t write software, so you don’t practice law.” Sound advice. He’s still our attorney after over 20 years, and a great guy

The designer of that first software product entered the insurance business after a successful career in the large mainframe computer business. At that time, commercial agency management systems were poorly designed, or priced way beyond a reasonable budget, or both. Unfortunately, that hasn’t change much over the years. We decided, way back then, that we could do better. After several years as an agent, a basic management system evolved for in-house use only. But, efforts to keep it in-house went down the drain when other agents saw what we had, and pushed us hard to buy our software. Eventually we relented and sold a few copies (after giving one or two away to good friends).

We had created a product that answered the needs of running a new and growing insurance agency. But because we were not encumbered by how other systems work (or didn’t) our system was logical, easy-to-use, and made us more efficient. As more experienced and better established offices started using our software, we got lots of feature requests. Too many, and wildly varied. That’s when the previous experience in the computer industry paid off. We established three cardinal rules:

  • Only implement features that will clearly benefit the majority of insurance offices. That quickly increased the software’s usability because we didn’t waste time developing some really cool feature that would only be used by the requesting office. Our efforts went into things everyone needed.
  • Avoid implementing changes that make our phone ring. That meant designing enhancements so they were easy to understand and use. In other words, intuitive, uncomplicated, and usable with little effort.
  • Rule three is perhaps the foundation for the other two. It has been my software development guide since working as an IT manager at General Motors many years ago. It is simple, and so obvious that we are amazed at how many others just don’t get it. Simply put, computers should work for people. People should not work for computers. That is why so much automation, and artificial intelligence, is built into our software. Just think of how many programs require major effort and yield minor results. Too many.

These three rules plus the belief that a higher power wants us to be kind to one another form the basis of our business philosophy. We believe our software, our support, and our pricing reflect it