The Process of Writing An Agency Management System
Posted by Bradley Chesnut on August 31, 2009 under Agency Management Systems, Desktop CSR, TIME System | 
Be the First to Comment
Before I can really get into the topic for this blog, some preliminary information needs to first be shared with you. As you'll learn, this preliminary information is foundational and crucial to the success of designing and writing a management system. Let's begin.
Having an Extensive Background of Working With Agencies and Management Systems Is Very Important
In the past 20 years in this industry I've had a tremendous amount of experience with the agency management system. Not only have I worked on or with many of the management systems on the market this past 20 years, I also represented two of them. With the first starting in 1991 I also did some programming in it. With both I worked closely with the design team (along with numerous other parts of the company which is another blog).
In addition, I'm also a very analytical consultant striving to find and teaching the best and fastest ways to do things, master your automation (management system & 3rd party programs) and to process your work. I also have a strong working knowledge of many 3rd party programs which has proven to be very advantageous in my helping agencies. The end objective is to help agencies decrease their workload, be more efficient and to better protect themselves from E&O exposures.
Finally, I also do programming and have written many single purpose database programs for agencies over the years like marketing database systems, phone logging system, client management systems and much more. I even wrote a custom management system for an agency in 2006 that dropped their workload by over 40%. I just talked to them this past week and they were commenting on how big of an impact the system has made in their agency. The difference is I understand workflows and processing work which I included in the design of the system. I can't begin to emphasize how important this is! We'll discuss this more further down.
The Agency Management System Is A Complex System
The agency management system is far from being some simple database program. Instead, the agency management system is a complex, multi-facet system that handles many different tasks required in an agency and captures a lot of different information. It's also been said that the management system is multiple programs all tied together into one program.
Regardless to how you describe an agency management system, it's a very advanced piece of software!
It’s not only designed to keep track of information like clients and their policies, in today's time it's also suppose to help you process your work like submitting new applications or endorsing policies. The fact that its also suppose to help in the processing of your work takes the management system to a whole new level of software.
Keep in mind the evolution of the management system. Prior to the 1980's it was predominately an accounting system to keep track of billings to the insured since most policies were Agency Billed, not Direct Billed from the carrier which is now dominate today. Then in the early 80's we saw our first major overhaul of the management system when client and policy management was added to it.
That was an exciting time because this new approach to agency automation opened up so many more doors for agencies and gave agencies the ability to work more closely with their clients. Over the years we watched more and more features being added to an agency management system to help you do your job. Things like imaging and T-History to do T-Filing.
Today we talk in terms of "going paperless", SEMCI, Real Time and other terms/phrases to symbolize creating a more efficient, productive and therefore, a more automated agency.
As a consultant I would work with the agency on how to process their work with the system they were on. Agencies committed to increasing their productivity found this to be the key … learning proper workflows to process a task. The problem is, the systems on the market were not designed to be process driven which made teaching CSR's how to process a task a difficult job. I'm sure you can relate with this.
It's been a constant battle of teaching staff proper workflows and making sure everyone's doing it the same way to protect the agency from E&O exposures. This is why the "workflow manual" and "workflow courses" has been just as important as the management system itself! That's because it's how the system allows you to process your work that establishes how efficient and productive your agency will be. And considering productivity is a huge factor in your profitability, creating a productive agency is very important when striving to create a profitable agency.
What we haven't seen yet in the evolution of the management system is a system built from the ground floor up with workflows and tools to help you process your work as an integral part of the system. That is until now with the creation of the Desktop CSR and the TIME System.
I'm actually not surprised we haven't seen this built into the foundation of a management system until now. In my opinion, that's because the big boys are too arrogant to bring in consultants to help them design a system (not to mention it's extremely expensive to have a system re-designed and written fresh with all new code like we did) and the newer vendors on the market are just simply duplicating/mimicking what's already out there, but that's just my opinion from what I've seen and the experiences I've had the past 20 years.
Up to this point I've shared some key information about management systems, a pre-requisite to this topic. Now it's time to get to the very point of this blog which is, "The Process of Writing a Management System." So let's move on to the real reason why I wrote this blog …
The Process of Writing a Management System: You Start With Back-End Programming … This is Foundational!
The most important part to the writing of a system is knowing upfront what you want the system to do which includes what features you need, understanding workflows, how to process a task along with what parts of the system are used to process each task, and then be able to put it all together. All of this MUST be known upfront before writing the blue print and then programming the system! Would you agree all of this collectively is key information to know if you're going to write a management system?
Let me give you an example of how important it is to know agency automation and all very well prior to designing a system – When you do an endorsement to a policy you also always add a note to the record to show what you did. In our system that note is created automatically for you adding what you changed on the policy and includes a link to the Policy Change Request form. It only makes sense to automate this consistent process, which is another exclusive feature of our systems. We have many features like this throughout the system along with over 40 exclusive features in the system.
When I represented and worked with other vendors and systems the past 20 years I was consistently making suggestions on how to enhance their systems. While the vendors were quite impressed with my suggestions, what I was consistently told was "in order to add that to the system we'd have to do a re-write of the system and we're not going to do that." As I pointed out, knowing upfront what you want the system to do is the most important part to writing the system! Here's why …
Back-end programming is the next most important part of writing the system, and it's foundational. Look at the back-end of the program as the power behind the product, the engine, if you will. It's the table structures (which we paid very close attention too for numerous reasons such as to make integrating with other programs much easier), how each table integrates with other tables, the programming of each field and table, and much much. These are things users don't see because it's the automation behind the scenes type stuff. Can you see why having all of the preliminary knowledge and information is so important?
Without it, we would end up with just another feature driven system. You see, when I took on this project I knew how critical it was to build in workflows and make sure you could process your work quickly and easily as part of the design of the system. However, if I didn't know productivity strategies and workflows as well as I do … which is intimately … then I couldn't have built them into the system from the ground floor up.
This is exactly what I've done … built the system from the ground floor up with proper workflows and productivity pieces & tools!
Many say this is the next evolution of management systems. One thing for sure, adding this piece to the management system requires a tremendous amount of knowledge and experience in workflows, productivity strategies and processing tasks which is why it doesn't surprise that we're the first vendor to add this element to the management system.
In this project the two areas that took the longest time is the policy management side which includes ACORD forms and the accounting. I was very clear on how important the policy management piece is, which programming has done a great job putting together. How the data flows and the functionality of the different forms like Certificates is just absolutely amazing! The foresight to this project is going to amaze you!
We also re-engineered many of the core pieces of the management system. Follow-Ups, for example, can be one of three different things … a client follow-up, a carrier follow-up in behalf of the client and a policy or a scheduled appointment. Because this is a new approach to a follow-up, once we explain this to you you'll wonder why it took this long for the follow-up to be designed properly to maximize it's purpose! And like I said, follow-ups is just one of many features we completely overhauled and re-engineered!
Once the backend programming was basically done we moved on to the next part …
The Process of Writing a Management System: The Front-End Programming (Window Layouts, etc.) … What The End User Sees.
With the back-end programming in place (the engine), it's time to do the front-end programming. Look at the front-end as the steering wheel and all of the controls. Where now taking all of that power we programmed on the back-end and make it all usable by the end user. To add to the complexity of this, the end users can be CSR's, producers, managers, owners, bookkeepers and accounting people, and people handling the marketing in the agency. That's what the front-end programming is all about … making the system usable for each of the different types of end users.
Here we're designing the layout and putting the windows together, placing the appropriate buttons on each of the windows, putting our menu system together, setting up security and system setups, and much more. Here we're designing what the end-user sees and how the end user will use the system.
A key element to this piece is it's here where easy-to-use is created or missed. With our tremendous experience in working with agencies on automation, teaching agencies how to use their automation and being frustrated with so many of the vendors in their failure to design a system easy-to-teach and learn, I have no doubt in my mind that you'll find our systems the easiest to learn and use of everything else on the market.
In the past 2 months I've really seen this piece — the front-end programming — come together. The windows are starting to have the look and layout I provided to programming as a proto-type and the functionality on the windows is coming together. What we'll do is give each of the windows the functionality for that window and then last we'll do the eye-candy piece.
I fully understand how important the visual side is. Not to discard its importance, traditionally the eye candy piece is the last thing that's done, yet it's how many people judge how good a system is.
It's important that we make sure each of the windows have the functionality they were designed to have and that each window has the ability to efficiently handle the job they were designed to do, along with making sure each window is common-sense in it's layout and design so it's easy to learn and use. Then comes the eye candy. We are doing the eye candy as we go along and as each window is ready for it. I should also point out, doing the eye candy visual layout is also a lot of work!
In closing, I hope that you found this to be educational. It's a tremendous amount of work to design and then have a management system written especially when you refuse to mimic anything else on the market because you don't want to end up with another feature driven system. We literally designed the system from scratch based off of our many years of insurance automation experience with a very clearly focused objective …
- To massively increase your productivity … this encompasses many parts of the system and requires building in the workflows into the system
- To create the absolute easiest system to learn and use
- To handle data conversions very well
- To integrate with 3rd programs and interface with your carriers
- To provide features and functionality to do your job better, easier and faster
- To bring agency automation to the 21st century!
You're not going to be disappointed at all with what we're bringing to the industry!
Now, all of this is what we wanted to accomplish with the product. Wait until you see how we've overhauled support and training, which is another blog for another day! At our home page for our agency management systems you'll find product information.