Vendors all have a standard sales approach in which they highlight their capabilities and key differentiators based on their understanding of the market. This process is often not sufficient to obtain the depth of knowledge required to make a sound decision. It is incumbent on the project team shopping for a treasury management system to design an evaluation process that ensures they obtain the information required to confidently select the right software for their organization.

In my experience, the following steps have proven most valuable in obtaining in-depth knowledge as well as a broad understanding of the vendor's organization, both of which are necessary to maximize the long-term success of the partnership.

1. Educate each vendor on the business and operational processes that will rely on the treasury management system.

Vendors are well-versed in the functionality their system contains, and are more than happy to demonstrate all the new capabilities and visually appealing elements of the software. They are also prone to using industry buzzwords, such as "straight-through processing" (STP) and "SOC2 compliance" without taking time to educate prospective clients on the importance and relevance of the related product features. Some of these capabilities may be important to the industry as a whole, but they are often less relevant to the company making the current purchase decision.

The project manager leading the treasury management system selection process should ask vendors to tailor their software demonstrations and other presentations to the company's specific needs, as opposed to walking through their standard sales pitch.

In order to focus each vendor on the system functionality relevant to the organization's unique situation, the project team must spend time up front educating the vendor on the company's operational processes and requirements. Examples of information that can help educate the vendors include:

• Detailed listing of roles and responsibilities of stakeholders who will be utilizing the application;
• Current- and future-state architecture diagram showing how the application will fit into the company's existing financial-application infrastructure;
• Walk-through of current operational processes and how the company envisions utilizing the system;
• Reports the treasury team currently generates, including those leveraged for operational and management purposes; and
• Specific policies or procedures that the company wants the treasury management solution to track, and ensure compliance with, in an automated manner.

Some of these items can be addressed in a well-written RFP, but the project team must go beyond just providing the information. Representatives of the client company must spend time ensuring that each vendor truly understands and appreciates the nuances of their requirements. These conversations should include the vendor's pre-sales team. Because they will likely be responsible for demonstrating the product, the members of the pre-sales team need to fully appreciate the requirements and how the buying company prioritizes those requirements.

Once the pre-sales team fully grasps the client's unique needs, then the client's project team needs to actively work to ensure they incorporate this knowledge into each step of the evaluation process.

2. Create detailed use cases.

One of the most effective methods for obtaining a more detailed understanding of a product, and the areas of functionality relevant to a particular company's needs, is by having the vendor tailor demonstrations to accommodate detailed use cases devised by the prospective client. Use cases are business and/or technical scenarios that the system needs to be able to perform. The project team at the client company should develop use cases, and then submit them to their short list of vendors. Typically, key stakeholders whom the client envisions as users of the system once it has been implemented should be involved in prioritizing which use cases to include in the evaluation. Each vendor should then demonstrate both the configuration steps that its product requires to be able to accommodate that use case and the final output the software will produce.

For example, consider a company that has a complex debt structure where the spread varies based on the business's credit rating. As part of the due diligence process, the company's treasury management system selection team should ask vendors to model the debt, including certain events such as rate resets and changes in spread triggered by changes in the company's credit rating. They should ask the vendor to demonstrate how the debt terms are captured, interest calculations are performed, and accounting entries are generated, as well as how the system will automatically adjust the rate based on the specific event scenarios provided. The goal is to ensure that the system fully supports all the calculations, operational events, accounting, and reporting in an automated fashion. The business shopping for a solution should have the vendor walk them through each of the operational steps to determine how efficient and intuitive it is and whether workarounds are required to achieve the desired outcome.

In addition to providing use cases that reflect some of the more complex challenges the new system will have to handle, treasury decision-makers should also include scenarios addressing their highest-priority requirements. They should ask each vendor to model these scenarios, producing some of the specific calculations required, and ask the vendors to demonstrate the exact steps they take to have each system produce the desired outcome.

To accompany the use cases, the prospective client's project team should also provide vendors with sample data and with some of the key reporting views treasury currently utilizes. Then they can ask each vendor to generate a sample report replicating the current reporting views, while using the company's actual data. This process will help companies evaluate the robustness of the reports that come built into the system, as well as the flexibility to customize the standard reporting views to meet clients' specific requirements.

Be mindful that modeling use cases can be time-consuming for the vendors; it's usually best to limit use cases to the company's higher-priority and unique items. The best use cases—if selected carefully by the client and then executed properly by the vendor—enable the treasury team to begin to visualize how daily tasks will be performed with the system and the potential benefits the client company could realize. They also help decision-makers understand how to navigate through the system to perform their operational responsibilities. With this knowledge, the project team can determine whether the system would be an improvement or a step backward from the organization's current state. Furthermore, they are better able to differentiate among the systems they're considering.

This outcome is certainly achievable; however, the process and vendors must be closely managed throughout the evaluation. Deliverables such as use-case results often miss the mark, either because the vendor does not fully understand the scenarios the client provided or because they made incorrect assumptions. For example, the vendor might leverage its existing data, as opposed to information provided by the prospective client; it might use incorrect rates or deal terms on financial transactions; or its scenario might follow an industry-standard workflow rather than a workflow specific to the client.

The vendors prefer to utilize examples that are similar to those they have previously modeled for other clients and that are readily available in their demo databases. The project team may need to be insistent that each vendor bases its demos on the specific needs of their company.

Shortly after distributing use-case information to each vendor, the prospective client's project manager should engage in a detailed walk-through of the use cases, and organize regular check-in calls along the way to validate that the vendor is utilizing the correct assumptions and to ensure everything is on track. Ideally, the prospective client will obtain written examples of the requested output prior to the vendor demonstration. This will allow the project team to review, be more prepared, and come into the demonstration armed with specific questions based on their review of the results.

3. Organize and lead scripted demonstrations.

Because the project team at the prospective client company will have only limited opportunities to see each product in action, they must make each interaction with the applications as meaningful as possible. Vendors have canned demonstrations and demo databases that they have spent significant time preparing, and they usually prefer to leverage these standard presentations.

It is important to allocate some time for the vendor representatives to demonstrate their system in the way they feel best represents its capabilities. Some components of these presentations are useful; however, a project team should keep in mind that the canned demos were prepared to meet the needs of other clients and illustrate functionality the vendor believes to be its biggest differentiator. The canned demos are not designed to show a particular company how the system can meet its unique requirements—and that is what the majority of a vendor's demo time should be focused on.

Before each treasury management system demonstration, the client company's project manager should develop a detailed agenda that includes time allocations for each section of the presentation. Time should be allocated based on priority and complexity. A typical agenda would include:

• System overview including standard workflow and dashboard capabilities
• Allocations for each functional area including applicable use cases
• Technology overview
• Implementation approach
• Detailed next steps

Additionally, the project manager should conduct at least one call with the vendor prior to the demo to walk through the agenda and ensure the vendor's staff understands the relevance of each point on the agenda, within the broader context of the organization. This will tell the vendor which items are the highest priority and should be the main focus.

It's ideal for vendors to incorporate examples that use data the prospective client provides from the use cases. Whether or not this occurs, the key to a successful software demo is to ensure that the limited time is allotted to items that will aid the client in better understanding and differentiating between the products on its short list, given its unique needs.

4. Interact with, and understand the structure of, all key groups at the vendor.

Understanding each product's capabilities is clearly an important aspect of the software-selection process, but a project team should consider other factors as well. One example is that they need to understand how the vendor is structured and who they will be interacting with—both during the implementation of the system and on an ongoing basis once the software is live.

The majority of interactions with the vendor during the selection process are with the sales team. However, after purchasing a product, the client will have very little (if any) interaction with the sales team. Thus, the project team's opinion and impression of the salespeople may not provide a representative picture of the entire vendor organization. Although it's logical to question any vendor that does not invest properly in a high-quality sales team, the effectiveness of the professional services, product, and customer support teams will have a bigger impact on the client company over the long run.

The project team needs to understand how each vendor is structured and request an opportunity to interact with individuals from each relevant team. The first team they will likely interact with once the procurement process is complete is the professional services team. This is the group responsible for implementing the system. A good implementation team can lead to a successful, on-time and on-budget project, so its importance should not be underestimated.

The key stakeholders on the project at the prospective client company should meet with the head of professional services at each vendor to clarify the following items:

• What is the vendor's implementation model? Is it a more hands-off, "train the trainer" type of approach; is it a full-service implementation; or is it a hybrid approach that is flexible based on the client's needs?
• Does the vendor use a specific implementation methodology?
• Does the vendor utilize its own employees to perform the implementation, does it leverage third parties, or does it prefer some combination of the two models?
• What level of effort will the implementation require of the client?
• What are typical challenges experienced during implementations, and what solutions has the vendor used to correct them in previous deployments?
• Who, exactly, will be assigned to the implementation?
• How many different simultaneous projects is each member of the implementation team typically a part of?

Despite the importance of the implementation team, clients usually fail to ask to interview or obtain references on the proposed team. I strongly encourage performing this step, as it can save significant time, money, and frustration in the long run. The implementation consultants' level of experience and skill can vary widely. A company deploying a business-critical treasury management system needs to have confidence that the vendor's best consultants will be assigned to its project.

Similarly, a project team that meets with the vendor's head of product development can gain insight into the underlying architecture of the application, as well as the direction and priority of future development. The prospective client should ask for a walk-through of the product roadmap, a description of how the vendor develops that roadmap and how it prioritizes different types of new functionality, and an explanation of how it addresses defects. The project team needs to understand how client requests are prioritized and ultimately incorporated into future product enhancements. Would the client company have a direct line of communication with the vendor's product team, or would requests be funneled through an alternative channel?

The customer support team is another key group that prospective clients need to become familiar with, as the vendor's customer service representatives will likely be the first point of contact for all issues or questions once the system is live. Here are some important questions to obtain a better understanding of:

• What is the structure of the customer support team?
• How are representatives assigned to clients? Would we have a dedicated representative, or would we call into a generic help desk number with a pooled-resource approach?
• How many employees are in the customer support group, and how many customers are they supporting?
• Where is the team located, and what are their hours of operation?
• What process is used to train the customer support team, especially on newly released functionality?
• What tools and processes are in place to capture, track, and manage client issues?

Depending on the structure of the vendor, account managers and technology support staff might also be relevant groups. Tech support is especially crucial if the vendor would be hosting the application on behalf of the client.

5. Speak with peers in the industry to learn from their experience.

The software vendor itself is the source of all the information described in the preceding sections. The evaluation process should also involve obtaining references from third parties that have similar requirements to the client company, and that have previously gone through both the evaluation and implementation process with the vendor. Asking vendors for references is a standard part of the enterprise-software evaluation process, but companies need to be sure they are obtaining a true depiction of the experience they are likely to receive.

One way to obtain unbiased vendor information is for treasury professionals within the client company to seek independent references through their professional networks. Sources of independent references can include industry associations or trade groups, LinkedIn groups, banks, peers in the industry, and trusted third-party consultants. Seeking out truly independent references does require additional effort; however, it can also provide the most valuable information in the entire evaluation process.

The prospective client should make sure to communicate the company's key requirements and to describe its operating environment, to be sure the reference is adequately similar. Speaking with a company that approached its treasury management system with a very different set of priorities and operating environment is unlikely to be terribly productive. For example, speaking with a customer that uses an on-premises version of the software may not provide much insight into the software-as-a-service (SaaS) customer experience.

Once the project team has identified suitable references, they need to come to the conversation prepared with a detailed set of questions. Sending these questions to the reference company's representative, in advance of the call, can facilitate more fruitful conversations. Potential questions to address on the reference call include:

• Provide an overview of how you are using the system (e.g., modules, functionalities, regions, number of users, etc.).
• Why did you choose this product? Which other vendors did you consider, and what were the key decision factors?
• Were there any major issues with your implementation? If so, how were they resolved?
• How long did the implementation take, and how did this compare with the original estimate?
• Did you work with any implementation consultants whom you would recommend?
• What components took the most time and/or were the most challenging to implement?
• If you were to do the implementation over again, what would you do differently? What were your key lessons learned from the implementation process?
• What level of help desk support do you receive? Is it available 24×7?
• Have you experienced any critical issues with this software? If so, how quickly were they resolved?

At the conclusion of a properly executed evaluation process, the client company should possess a deeper appreciation of each product's capabilities and a clear view of how key operational tasks would be managed with each vendor. The key project stakeholders should feel comfortable with the vendor personnel who would be supporting them and should understand the operating model for ongoing support and upgrades.

Decision-makers must pay close attention to the software-selection process so that when they do choose a treasury management system, they have a high level of confidence in the decision. Selecting the right software helps build excitement regarding the transformation possibilities and potential evolution of the treasury function within the company.

See also:

• Planning a Treasury Management System Implementation

Chad Wekelo is the founder and principal at Actualize Consulting, where he leads the Capital Markets & Treasury practice group and specializes in treasury operations, liquidity management, accounting, and risk management. Specifically, Wekelo has detailed knowledge across all treasury products, including debt, derivatives, and investments, as well as cash management and payments.