Replacing an MGA's Core System

A detailed review of an AMS (agency management system) is an opportunity for an enterprise to closely examine its business and make strategic decisions about the kind of agency it wants to become. Modern Agency management systems should allow independent agents to evolve to support the changing insurance landscape. Most Agency systems are in place for 5 to 10 years.

Your customers and employees expectations of technology have been changed and they will demand their insurance purchasing and sales experience to follow suit. This is as much a process and people project as it is an IT project. You’ll need to involve many different parts of your organization to ensure a successful implementation and change management process.

Before diving into the process, let’s list why you should consider a core system switch.

• Poor technical support
• Legacy system that is no longer updated
• Disparate and unified processes
• Long cycle times between key actions (quoting, binding, issuing)
• Poor data management and lack of reporting
• Heavy reliance on a large back-office or offshore team

If you match any of the above, here are some steps to that will aid in your AMS decision:

(I) System Selection Team

If you have not yet involved your sales and support staff in reviewing the new agency management system, it’s time to bring them in to understand their needs. Choose a ‘system selection team’ (from customer service reps to top management) that will coordinate the review process and offer insight on which AMS best fits the requirements of the agency. The staff must know why a new AMS is essential to the agency. Make sure that everyone who will be impacted gets an opportunity to share his or her opinion.

Your agency must determine the system features that are most important however we suggest you start with a benefits first approach. That is, the team selected above must determine the what it want’s to achieve from an internal and external perspective. You need to understand the functionality and pain points of the team, which can help you create a must-have list and a wish list.

(II) System Requirements

A system requirement is a feature that a system must include to satisfy the business requirements of an agency and be acceptable to most users.

A must-have list will help you start eliminating providers that do not meet the basic needs. Items on a must ­have list should include things that each part of your business needs to function. Examples include sales data for your sales staff and commission tracking for the finance department.

A Wish list can assist you in breaking ties between providers that have almost everything you need. The list can include the things that are great to have, but are not absolutely necessary for daily operations. Here you may include items such as storing an unlimited number of documents, built-in web portal etc.

Here are a few methods to determine system requirements and ensure your new system matches your companies goals: Interviews: The team can gather many facts about the current system by speaking with all system users of the agency. An alternative approach involves using a survey tool like survey monkey.

Some sample questions you might include:

• In what areas do you think our existing system is inefficient?
• Can and should these processes be automated?
• Does our existing technology lack functionality that would aid your underwriting ability?
• What key reports do you feel would help you better understand your business?

Observe: Even better than interviewing users is actually watching them work, observing staff members will bring to light many of the processes that might be missed during an interview but are still key to your workflow.

Reviews: The team should look at the outputs from the current system that are integral to how the business works including: reports, certificates, error messages, bills, etc.

(III) Creating an RFI

By creating an RFI (request for information), you can identify potential vendors and their platforms that would be appropriate to review. RFI acts as a formal statement of the agency’s expectations. It provides direction to vendors as to the requirements their management software must meet. If all vendors work from the same RFI, the agency should be able to make a fair comparison between the initial information of different vendors. The RFI may include the following:

• Agency description. The description must include the types of insurance sold (Commercial, Personal etc) , specific objectives for the new system, current and projected client base information, carriers the agency makeup, and marketing strategy.

• A list of functional requirements identified by the team. As vendors will base their proposals on this list, this is the vital part of the RFI.

• Proposal specifics including those items that the vendors must address in their proposals. This might include a timeline or goal and budget.
• Configuration requirements, this would include specifics such as the number of workstations, types & numbers of servers, and also the required capacity for growth if choosing an on-site solution. Or user-roles, storage limits and employee count if choosing a cloud solution.

• Support issues including help desk support, on­site repair service, and other support areas.


(IV) Demonstration Process

There are primarily two types of demonstrations: Vendor controlled demo and Agency controlled demo.

Vendor controlled Demo

This is the initial demonstration from the vendor, and the team would be able to get a good overview of the product and its features. The system selection team members may take notes on what they see during this process. The goal of this demo is to narrow down the number of vendors that you invite back for a more detailed and in depth demo. It is recommended to identify 2 or 3 vendors from the first group that you will invite back for a more detailed demonstration of their system.

Agency controlled Demo

This demo will be controlled very specifically by the agency or mga. The team provides detailed written scenarios on common functions performed in the agency, and vendors have to accomplish this by using their system demonstration.

Here are a few rules to be followed:

• Keep the functional requirements in mind. These are the high priority issues that you want to make sure the system will solve.

• The team can expect the vendor to address the functional requirements that the RFI listed first.

• It’s always a good idea to have a secondary demonstration session for the agency or MGA personnel who handle accounting.

• The team may send descriptions of a few workflows to vendors for inclusion in their demonstration. This is to judge how well the system performs these tasks, and the team will be in a better position to compare it to other systems.

• The team should schedule demonstrations close together. All members should meet as soon as possible after each demonstration to discuss their thoughts, and may use score cards to compare all the systems.


Once you review the evaluation teams perspective, plan your roll out and make a purchase decision based on your teams input.

If you want to learn how we have helped various businesses like yours scale go to www.bindhq.com