June 11th, 2024 | Brian Hendricks, Chief Operating Officer, CapitalROCK

Non-integrated software is like buying a bathtub and filling and draining it with a bucket!

Placement and integration of a software package are key to utilization and success. If you fail to integrate well, you may have destined the software to failure.

A Little History 

Early on at CapitalROCK, we were deploying our suggestion engine solution at a top three insurance company. The suggestion engine provides cross-selling opportunities across the entire firm and can be provided to a financial professional at the level of their specific book of business. We assumed that financial professionals would flock to the solution to get these golden nuggets. The only integration was a single-sign-on link to our application from the client’s dashboard. We launched it with lower-than-estimated success because many financial professionals would not click the link into the application. We measure success by the number of suggestions that the financial professional dispositioned (they liked it, they didn’t think it was right for the customer, they would look at it later, etc.). The link was prominent; it required one click from the dashboard to our solution. Once they linked into the application, there was a widget that presented the top five most promising sales opportunities front and center. It seemed relatively easy.

Based on this muted success, we decided to try something else. What if we integrated these five daily suggestions into another application? To do this, we created a simple widget and integrated it into the financial professional portal so that zero effort was required by the financial professional to view it. When we launched the new widget, the results were immediate. The success rate, or the number of actions taken by financial professionals, increased tenfold. This simple integration change made all the difference. When this same client opted to change to a new CRM, they took that same widget and integrated it into the dashboard of the CRM with similarly good results.

We see similar patterns with our regulatory solutions. Firms that have an integrated solution have much higher user satisfaction and lower NIGO (Not In Good Order) rates. The level of integration varies across our customers, and the success almost directly correlates to the level of integration.

Best Practices 

After numerous integrations of the RightBRIDGE platform with multiple other systems, we have learned a few things that may be helpful when considering how to integrate applications such as RightBRIDGE. 

Map Out the User Journey in Layers 

1. Define Your Goals

• Why are you doing this integration?
• What problems are you trying to solve?
• What are your objectives for the system users?

Carefully determine your objectives and state them clearly for the team. I have heard at times “our users are not good with software,” or “our users do not like change.” Well, who does? If your goal is to force the users to follow a process, then you might want to reconsider the objective. Instead, a better objective is to make the process so easy and clear that users follow it naturally.

2. Create Layered Diagrams

When mapping out the journey, it needs to be done in multiple layers. There are at least three layers that will help:

1. System Flow: This is the flow between systems. In our typical integrations, we have at least two systems other than RightBRIDGE that are part of the process.
2. User Interface Flow: This is how the user navigates. What buttons will they press? What happens when they leave one application and go to another?
3. Data Flow – How does data follow the user? Where does it come from, and what is the method of getting it?

Don’t try to do these together, as the diagram will get complicated and will confuse the technical team and the business team. Have a different diagram for each.

Within these flows, answer the following questions:

• What data values can be mapped between systems?
• How does data need to be transformed (e.g., Birthdate to Age)?
• What triggers a user to move from one system to another?
• What security concerns exist?
• What is the common ID for the User and the Client record?
• Are the access permissions the same for each system?

Decide Your Integration Model Between Applications

There are two primary models for most integrations, Hub-and-Spoke or Vendor-to-Vendor. There are benefits to both, but you will want to determine your approach and stick with it for consistency. Here are some pros and cons of each of these models:

Hub-and-Spoke	Vendor-to-Vendor
The firm has a core system or integration hub where all integrations start and end. All vendors integrate to this platform.   Pros  • You control the data.  • You can replace one vendor with another.   • You control the process.   Cons  • Heavier firm resources.  • All integrations are new.  • Maintenance with upgrades is your responsibility.  • Typically takes more time.	Vendors work together and use existing APIs to integrate and pass data from one system to another.   Pros  • You can use existing integration between vendors.  • Vendors are responsible for maintenance of the integration.  • Lighter resources from your firm.   Cons  • Data ownership issues.  • More difficult to replace a vendor.

Consider Who Will Maintain the Integration

When designing the integration, there can be a tendency to design in complications. You may not be able to avoid all complexity, for example a design that supports a security requirement, but wherever possible, seek to simplify. Ensure only one side of the integration puzzle does the data mapping. Decide early on who will do the data mapping. If you decide to rely on the vendor, plan on spending ongoing configuration fees and T&M to make changes. If you plan to do the integration to the Vendor’s API, make sure that the vendor will allow changes and the ability to add more data without an additional charge. Avoid having both sides do data mapping, as it increases the complexity of the integration.

Get the People “Who Know” in a Room Early

At each organization there is always a person who knows the lay of the land and knows the systems. Find out quickly who this is and rely on them for guidance to your systems. This may include system architects and product owners for the systems that need to be integrated. Connect these experts with the vendor’s architects or product owners. I have seen numerous occasions where a business unit in isolation designs an integration and then presents their plan, only to have it prove unfeasible based on some technical limitation of the platform. Ask your vendor partner for examples of what they have done with other clients and what the pitfalls were.

It Is Ok to Do It in Phases

It may be good to have a long-term plan for your integration, but if one portion of the integration is exceptionally difficult, consider splitting the work into functional phases that will provide usage of the solution with the end goal in mind. Define your “MVP” (Minimum Viable Product) and start there. You will learn so much if you have a phase 1 and phase 2 follow up.

Apply the 80/20 Rule When It Comes to Data

The most common complaint with nonintegrated solutions is “why do I need to enter data twice?”   Certain data may be easier to integrate than others. Start by integrating the data that is easiest or most common. In RightBRIDGE the most common data is a case or client identifier and the suitability information for the client. We have found that if a firm begins with passing at least the Client ID, a client name, risk tolerance, income, age, net worth, then the level of user satisfaction increases. User adoption also increases when they see that most of the data is pre-loaded. Delaying implementation to integrate the last 20% of data can waste money and time while paying for a license that your financial professionals are not fully using. 

Get Your Teams Focused

Agile only works if you have a dedicated team for a period of time. When you start the integration work, make sure that the vendor’s and your teams are allocated and ready to work. Regular working sessions expedite the process, preventing delays caused by back-and-forth communication. A typical pattern we see, especially when using offshore resources, is that teams will make a change, followed shortly thereafter with an email when it doesn’t work, only to get a response hours if not days later from the other side with yet another question or additional changes. I see this with my own teams where an issue may arise, and the developers start a group chat to try and resolve the issue. I prescribe to the 3-message rule for my team. If I see a chat that goes back and forth three times, I will coordinate a call with everyone to avoid further wasted time. I have seen over and over how a 15-minute call can expedite a process and save days or hours. When it comes to a successful integration, it is better to have a 1 hour meeting every day for a week than to have 1 meeting per week for 6 weeks.

Get Valid Test Cases and Data

Taking the time to build valid test cases with data that makes sense is a worthwhile investment. We’ve all created our share of “Mickey and Minnie Mouse” fake cases. It’s appropriate to use fictitious names, but you also need to make sure the underlying data is representative of what your system will use. Ensure that your test/dev solution is a mirror of the production system.

Headless Or Full API

Occasionally we are asked if our RightBRIDGE application can be integrated as a “headless” application or full API integration to create a “seamless user experience.” This is where the firm builds out a user interface to replace the RightBRIDGE UI. We have made this option available, but firms should carefully consider the pros, cons and costs of integrating a solution in this way, regardless of system.

Here are some questions to consider when looking to use a headless integration:

• Is the user interface and the flow it provides a key component of application success? 
• Does the application change frequently due to upgrades and/or regulatory changes? 
• Are you willing to accept reduced functionality for the same license cost? 
• Do you have technical resources to build the initial front-end application? 
• Do you have technical and business resources to upgrade your application to take advantage of new features? 

While delivering a seamless user experience is the ideal state, most financial professionals are accustomed to currently using multiple systems, from financial planning to CRM, order entry applications, to Word,  Excel, Esign, and a whole host of legacy platforms. Paraphrasing a wise saying, “Don’t let the perfect integration be the enemy of a good integration.” 

Watch out for warning phrases

There are a couple phrases that always make me shudder. They are an indication of a system problem or a lack of understanding.  

“We will just train to that” 

It’s tempting to throw training at an application or integration that’s lacking clear instructions or intuitive design. Training is important, but it should not be used to compensate for a poorly designed system flow. For example, if the user needs to upload a document, then why not include a big button that reads “Click here to upload documents”? In this way, the integration overcomes a manual process. 

“Send me all the data” 

When a client requests “just send us all the data”, this could indicate a lack of understanding on their part. Data is much more precise, and it may take some time and review of the available data to determine what data is needed.   Ask the vendor if they can highlight the most commonly integrated data elements, and then consider what questions or processes you want to understand with the data.  

Ask a Lot of Questions

If this is your first time integrating a certain software application, don’t hesitate to ask questions and reach out to the vendor or even industry peers who use the same solutions and have experience integrating it with their systems.

Conclusion

Integrating software is complex, but the ROI can be huge. Integration is essential for promoting adoption by your financial professionals and maximizing the value you receive from your new software investment. By following these best practices, you can ensure a successful and efficient integration process.