The great RFP hoax: why boilerplate checklists never work

Published November 13, 2013
Last modified November 13, 2013

Industry watchers say that organizations change their customer support tools every five years on average. Whether it’s a gentle migration or a more painful rip-and-replace, changing a business-critical system is never as simple as you’d like. It’s also expensive, even if the ultimate goal is to save money. And let me repeat: Companies are going through this every five years.

Of course, there are plenty of legitimate reasons you could decide to change their customer support tool. Maintaining an in-house legacy system may have become too expensive. Perhaps the vendor is no longer be supporting or upgrading your current solution. Maybe after a round of consulting and training expenses, it’s become clear the existing tool really can’t address your needs.

But before rushing into selection process for the next support system that you’ll wind up abandoning in five years, why not stop and examine the selection process itself. A little up-front investment could lead you to a customer support solution that will last for much longer.

Why predefined templates are no good
So, here you are, unhappy with your current support tool and about to embark on the request for proposal (RFP) process. Maybe you’ve already shortlisted some tools or vendors, and now you need to know exactly how they can help you.

A predefined checklist—whether a best-practice checklist or a vendor-supplied RFP template—isn’t designed with your specific needs in mind. You could end up leaving out important support requirements of your business. And, if you submit an RFP you’ve used previously, you will likely overlook innovative new ways of working by excluding vendors simply because they don’t match outdated requirements.

It’s okay to start with any of those for inspiration, but keep it at that. In fact, Zendesk has a customer support scorecard you could use as a starting point.

Remember, you (and your organization) are a unique snowflake, so take the opportunity to come at it with a fresh perspective. Consider how your organization has evolved since you developed that old RFP, and look to the future trends of your marketplace rather than accepting the preferences of the Fortune 500 companies whose requirements went into the RFP templates you’ll find on the Web.

What you can’t avoid doing
Putting together an RFP is not a quick and easy task. Nor should it be. It takes work, and you can’t avoid it if you want to be successful.

A good RFP isn’t just a list of technical requirements you’re ticking off; there are people interacting with your support software. Your agents and managers need to like it—or at least agree that it makes their jobs easier to do. Your customer support tool touches so many parts of your organization—it’s serious business—so be prepared to invest some time in getting it right from the start.

Who you should talk to
Even if you’re following best practices, the things that make your industry and your company unique mean that you may go about it a different way or have unusual constraints. Seek feedback from outside your own department to understand the needs of the people who’ll come into contact with the new software through use or maintenance. In a support organization, that’ll include the support staff themselves, their managers, perhaps partners or suppliers, the IT team, and also your customers.

With a clearer understanding of present requirements and future needs, you’ll have your best foot forward when it comes to trials and demos.

Need more help?
As you’ve learned, planning ahead can extend the life of your new customer support solution. Need help getting started? Flip through our new guide in the SlideShare below.

If you have a question or think we missed something, please let us know in the comments.