How to get a head start in the RFP process

The RFP can be a bewildering and even intimidating exercise. Andrew Burgess suggests some ways forward

You’ve been overheard saying “there’s got to be a better way” about the banking. Now somebody wants you to find that better way – and to prove its worth before the firm puts its money where your mouth is.

The request for proposal (RFP) is the classic way to gather information about the complex range of services a bank provides.

Done right, it lets the banks know what you are looking for. It conveys that you are serious about changing or adding services, and want the best fit for your needs as well as requiring those needs to be assessed fairly and professionally. The desired outcome: a smooth transition to improved business function and profitability.

Done wrong, it’s a time-consuming waste of resources that confuses everybody and results in the business overpaying for functions it doesn’t really need, ones that might even impede normal functionality.

The usual procedure is you generate a report (the RFP) detailing what you are looking for from your future bank and asking how they would meet the requirements you set out. This is sent round several candidate banks. The banks respond with written suggestions. You select a shortlist to meet and enter into more detailed discussions with.

 The RFP is the classic way to gather information about the range of services a bank provides. Done right, it lets the banks know what you are looking for 

From those discussions, a final decision is made. Ideally, this should not be the point where you realise that the wrong questions were asked at the start and that the whole exercise needs to be repeated.

The two key stages are: drafting the RFP and the discussions with the banks.

An analogy would be a promising new graduate drafting a CV and having multiple job interviews. You get to choose which employer, but it better be a good choice, because once you are committed to investing your future with one firm, it is expensive in time, money and lost opportunity to change track if they don’t behave as expected, or if they do, but you discover that this is not what you really wanted.

Drafting the RFP

To do this well you need to know where you are, where you want to get to and ideally how you would like to travel. So you need to think about the following issues:

1. Your scope: are you looking for a new main relationship bank; a zero-balancing pool provider; a quick access to the Single Euro Payments Area system; or a well-placed bank in your new target growth market?
2. Your current actual situation as it is; not as it should be. It is best if this is backed up by descriptive statistical data of the volume and type of transactions you actually have to process, both regularly and on those special circumstances that in practice turn up so often.
3. Your intended end result, ideally both the perfect and acceptable cases.
4. Your priorities for making the decision; in ranked order (none of this ‘they’re both equally important’ rubbish). If everything else was equal, which factor would swing the decision?
5. Your deal breakers: what the bank must be able to deliver should be front and centre. There is little point being at the point of signing having failed to ask: “by the way, are you able to implement this by the end of next month?”, for instance.
6. Your decision-makers: if corporate finance head office will be making the final call based on global funding provision alone, then there is little point asking regional treasury hubs to do a detailed RFP to assess transaction costs.
7. Your biases: does anyone involved in the process have noticeable feelings for or against any of the banks involved? Identify if ABC bank missold your first mortgage or XYZ bank employs your nephew, and then neutralise any non-relevant impact on the decision.

Not all this data needs to go in the RFP itself, and some definitely shouldn’t, but you need to clarify what matters for your decision-making. Then you can produce the questions to give you all the answers needed.

Letting the first draft RFP sit untouched for a few days before coming back and checking it with fresh eyes is almost always useful – as is a proofreader. Once it’s good to go, send it out and wait for the replies.

The interview process

Once the written answers have been sorted down to a shortlist, it’s time to get face to face with the banks. You might want to consider having a wild-card bank that barely makes the shortlist as a first-practice interview for what to expect.

Who to take to the interview? The short answer to this is: anyone whose opinion you’d respect and want to take into consideration. Specialists from cash management and IT support are pretty much a given. Everyone takes notes and everyone picks up on different things.

You shouldn’t worry, either, about asking more questions for clarification later – it’s not as if the bank will refuse. Do discuss each interview afterwards, however, both to check everyone understood it the same way and to identify areas to check in the next interview.

What you want to find out is:

• What they offer and how it meets your needs;
• What they can actually deliver, ideally with minimal discrepancies to the above;
• When it will be in place, and how the bank deals with implementation problems;
• What it will cost, and that this quote is guaranteed;
• How it will operate once in place;
• Who your contacts are and their availability;
• Any systems limitations or changes needed; and a strong sense of how robust the solution is likely to be;
• Any legal restrictions on yourselves or the bank; and
• Expected functional life – if next year’s regulatory change means it won’t be functional, why install it?

You should also ask to be put in touch with some reference customers willing to discuss the implementation process. Ideally, these should be the three most recent customers, not just the three happiest.

Once the interviews and any follow-ups are carried out, it’s decision time. You can take soundings, and take those into account, but can’t delegate this decision. Writing out your decision with reasons why you propose accepting one bank and rejecting the others and reading it back out loud a few days later is a good way to back check yourself.

While you might feel under time pressure in terms of making a decision, you should bear in mind that making the right decision should, properly speaking, outweigh that. Don’t feel hurried. You’re allowed to ask more questions and talk to more banks right up until the point where you are fully happy with the choice.

And if it comes down to two banks that are finely balanced… toss a coin. Not to see the result, but because you’ll know which one you’re hoping for while the coin’s still in the air.

Tactical moves from banks

Once you’ve invited banks into the process, watch out for the following:

• Courtesy calls to find more information than is included in the initial RFP document for clarification. If it’s something genuinely missed out of the document, don’t forget to highlight it to the other banks. Your aim is to have a level information playing field (but do note which bank did the more diligent research and found the omission early).
• As in any sales situation, rubbishing a rival bank’s services, rather than talking up their own, usually tells you who the bankers in front of you are most worried about.
• The treaty room. Off-site visits to the bank’s plush private banking suites, rather than your drab Formica and grey carpet-tiled office might make some of your team feel overawed and off balance – it’s intended to and will if you don’t recognise it.
• Style points. The bankers you talk to will be acting as a sales team, whether they are your future relationship partners or not, they are there to impress and land a sale. Sharp suits and business cards are to be expected. Make sure all your team knows that, and that there’s no need to compete or worry.
• Practice. At least some of the bankers will have been involved in multiple RFPs; most treasurers a couple at most. You can accept some guidance, but not railroading.
• “Don’t worry about that” is the reddest of red flags.
• Listen with your eyes: if their IT support guy isn’t making eye contact while their team leader is discussing system reliability, you might want to probe. If the senior banker interrupts and corrects their proposed relationship banker constantly, you’ve got a problem.
• Ask the questions you’ll regret not having asked later. “What have you learnt from previous implementations like this?” is a good one.

Why and why not to involve consultants

Consultants can be useful in the RFP process, especially if you don’t mind being seen to subcontract your thinking, but they can’t make the decision for you. What they can offer is:

1. Data collection about what you do. Often this is simply going and talking to the operational-level staff, then presenting it as high-end insight. Talk to your own people first and don’t pay for what you’ve already got.
2. Outsider perspective: having to answer “why do you really want that?” before the RFP is drafted can avoid habitual thinking becoming a key criterion.
3. Data collation: if your team is too stretched to go back through 10 years of bank statements to check the level, this can be farmed out.
4. Editing the draft RFP and checking it includes all the relevant data not just that matching the function of interest: there’s little point having a great cash-pooling system, if your new bank won’t deal with exotic, but commercially important currencies.
5. Added experience and authority: provided they have done several end-to-end RFPs before. This can both anticipate implementation problems and defuse sales techniques.

The key with consultants is to make it clear from the outset they’ll be assessed by how effectively the implementation of the RFP decision goes (as will you). If future support is needed to deal with the problems, you’ll be getting it from your new consultants.

About the author

Andrew Burgess is FX manager at GE Alstom