At some point a lender may need to issue an RFI or an RFP for a credit decisioning system. In this latest installment of “working with vendors” let’s dive into some best practices for writing RFIs and RFPs that will help you more quickly and efficiently understand the capabilities of a vendor.
First, have one person (or at most a very small group) review the document before it goes out to vendors. Too often these kinds of documents seem like they’re just cut and pasted together without any concern if they paint a coherent picture. If it’s worth the time to write an RFI/RFP, then it’s worth the time to get it right so that the vendor responses make sense. If your document paints an inconsistent picture, a vendor may not know what products will best serve your requirements. In turn, precious time will be wasted in discussions around what’s being proposed.
Here are some things to make clear in the document:
- For what part of the credit life cycle does this RFI/RFP apply (prospecting, origination, account management or collections)? If the request covers more than one part of the life cycle, make clear which questions apply to which part of the life cycle.
- Do you need a system that processes in batch or real-time requests (or both)? For example, a credit card account management solution can process accounts in batch (for proactive line management), in real time (for reactive requests) or possibly even both. Let the vendor know what it is you’re trying to do, as there may be different systems involved in processing these requests.
- Do you want this system hosted at the vendor, a third party (like AWS, Azure, etc.) or installed on premises? If you have a preference, let the vendor know. If you have no preference, ask the vendor what they can support.
- In general, consider playing down or skip detailed pricing questions. There’s nothing wrong with asking for a price range. For credit decisioning systems, detailed pricing is difficult for the vendor since there are often high levels of unknown customization to do. A better question might be, “What things will the vendor have to know in order to accurately price the solution? What are the logical next steps to get more accurate pricing? What’s the typical range of pricing in a solution such as this and what drives that range?”
- Will you be acting as an aggregator? Sometimes systems are created as front ends to several lenders. For example, a client may want to create a website where a borrower can “shop” among several lenders. This is certainly doable but carries with it a whole host of legal, compliance, business and technical questions. In my opinion, I’d skip the RFI/RFP in this situation and have a robust sit down directly with the vendors. This option will likely be far more productive.
- Ask more open-ended questions. “How does the solution perform task X?” as opposed to, “Do you support Y?” Often, there’s more than one way to accomplish a task. Asking more open-ended questions will yield a more comprehensive answer from the vendor rather than a simple yes or no response. It also gives you the opportunity to learn about the latest decisioning techniques.
- Be careful that you have not copied old RFP questions that are no longer relevant. I’ve had clients ask if we support Bernoulli Boxes (a mid-80s kind of floppy disk), or whether we support OS/2, etc. I’ve even had questions about supporting a particular printer. These kinds of questions are centered on the support of the operating system and not a particular vendor’s credit decisioning software. Instead of asking yes/no technology questions, ask for a typical sample architecture. Ask what kinds of APIs are supported (REST, SOAP/XML, etc.). Ask about the solution’s capabilities to call third-party systems (both internal and external). Ask fewer, but more in-depth questions.
- If the solution needs screens, be clear which screens you’re talking about. Do you need screens to make rule adjustments or configuration changes? Do you need screens for manual review or some sort of case management? Do you need consumer-facing screens where borrowers can type in their application data? If you need screens, be clear on the task the screens should perform.
- If you have particular concerns, ask them in an open-ended way. For example, “The solution will have to exchange file-based data with a mainframe. How can your solution best satisfy this requirement?” In general, state your requirement not the technology to use.
- A preamble or brief executive summary is useful to get the big picture across before the vendor delves into any questions. A paragraph or two can go a long way to help the vendor better assess your requirements and provide more meaningful answers to you. This works well because it’s easier to give the big picture in a few paragraphs as opposed to sprinkled around in multiple questions.
To summarize, be clear on your requirements and provide a more open-ended format for the vendor to respond. This will save both you and the vendor a lot of time. In section three, I’ll cover evaluating vendors.
