Of all the ways our industry has evolved, one of the more challenging changes is the prevalence of the request for proposal, or RFP.
While providing pricing to clients has been around just about forever, the change to which I am referring is the evolution that this process has undergone. It has become so formal (almost sterile) and, in many cases, difficult. This devalues the personal relationships we all strive for as we build partnerships between organizations.
Here are some best practices that help the process remain valuable, unbiased, and equitable without making it more like a matrix that is cumbersome and difficult for respondents to complete.
It is vitally important that the respondent feels included. The RFP should be presented and written in a way that includes the respondent. It should clearly state the “deliverable” that the respondent is being asked to create. By simply stating what business problem/issue they are being asked to solve and clearly defining the operating environment (IT structures, preferred and mandated security protocols, implementation timelines, etc.), the respondents will be able to provide better and more detailed responses regarding the deliverables. The respondents will be able to include graphics and verbiage that directly relate to the organization issuing the RFP, which makes it easier for them to evaluate the responses they receive.
Minimize Filler Content
RFPs should be direct and based on action. Organizations invited to respond to RFPs do not like ambiguity. It forces them to make assumptions, which is always dangerous for both organizations. Be clear and expect clarity from the respondents. A properly developed RFP invites responses that clearly define the actions that each party will undertake should they engage in moving forward. Without this level of clarity and clearly defined actions, the whole process loses a great deal of value for all involved.
Spelling and Grammar
The RFP should be well-written and easy to read. Nothing disturbs me more than finding grammatical and spelling errors in one of these documents. It is difficult to prepare an RFP and takes both resources and time, but yet, it is difficult for me to believe that organizations fail to do a simple review of the document to check for spelling and grammar. Would these same people send their resume into an organization without first checking these important elements?
Clearly Pose Questions
When issuing an RFP, your organization is looking for answers. The RFP needs to be clear about what the organization is looking for. The respondents deserve clarity so that the answers they provide will be clear and on point. As a result, their responses will be obvious within first two sentences they provide, which is an added benefit.
In the RFP document, margins, graphics, and text should align and flow seamlessly. The graphics should be used to supplement and break up the written content. Respondents will appreciate the structure and value a consistent look. This makes it easier for them to clearly know where they need to add a response and allows them to format their responses, focusing on continuity in terms of structure. Too often, RFPs are cluttered and formatted in ways that make it challenging (this is putting it mildly) for respondents to provide their information. This is one form of “response prevention” that I am sure is unintentional but is nonetheless an impediment to the value of the RFP itself. If respondents are expected to provide clear and concise responses, the RFP document must be properly prepared and presented.
Remember that any RFP you prepare must be universally accessible. Without access, the respondents cannot/will not respond. If the responses are limited, the best solutions may never reach the organization issuing the RFP, which is certainly not optimal. Use updated versions of the commonly used platforms many RFPs are issued in. It is difficult to prepare these responses anyway, and trying to do so in outdated versions of the programs is not a best practice. At the very least, I always worry if my responses will “translate” properly between versions or if the issuing organization will even be able to open the response if they only have the older version of the program.
Invite Comments and Feedback
Finally, while you have potential vendors engaged, ask for their feedback on the RFP. Allow them to share their thoughts on the structure and “ease of use.” They will share some insightful thoughts that will allow you to improve future efforts and RFPs you work on. Continuous improvement is something we all strive for, and the RFP process should be no different. Allowing the respondents the chance to provide their feedback will represent you and your organization very professionally which is always a good thing.
Don’t Let the Process Overwhelm You
Preparing RFP documents is challenging and difficult. I appreciate it as an art form and take great pride when I can provide RFP documents that are easy to respond to clearly and concisely. Focusing on the respondent is one way to ensure that the effort of preparing the RFP will result in thorough, thoughtful, innovative, and complete responses. Leaving the document open to question is an invitation for respondents to feel the need to add all sorts of caveats and assumptions, which is not optimal.
Each of the “best practices” above keeps the focus on the respondent. I believe this list is quite helpful, and when followed, it will result in responses that are clear and easy to evaluate. I hope it is helpful as you prepare RFPs going forward!
Mark Rheaume is a Services Engineer, Enterprise Services Sales Engineering, at Ricoh USA, Inc. He has over 35 years of industry experience developing, designing, and implementing solutions. Mark is and has been an active member in several postal industry associations as a board member, speaker, and writer. These associations include: MTAC, Idealliance, NPOA, PCC, MSMA, Mailcom, NPF, and Printing Industries of Minnesota. He can be contacted at Mark.Rheaume@ricoh-usa.com.
This article originally appeared in the January/February, 2021 issue of Mailing Systems Technology.