If you’re worried about how to write an RFP for a new phone system—well, you should be. Writing an RFP (request for proposal) can be time-consuming, involves technology details you’re probably not familiar with, and kicks off the arduous service-purchasing process.
But it doesn’t have to be that way.
At Jive Communications, we’ve drafted our share of RFP responses. We’ve also helped many organizations (or consultants they’ve hired) craft their own RFPs aimed at Hosted VoIP providers. That’s why we wanted to share this list of tips on how to write effective RFPs.
#1. Meet with your team/department first.
In so many cases, someone inside your organization—usually your purchasing department, if you have one—has created an RFP template, or collected some of the information you’ll need for one, like general terms and conditions and applicable forms.
Even if no one’s done that yet and you’re starting from scratch, you will still want to meet with everyone involved in this project and answer some questions:
- Who’s going to manage the implementation?
- Who’s going to handle day-to-day system management?
- What kind of users do you have (basic, advanced, executive, receptionist, call center, etc.)?
Identifying project stakeholders and engaging them early in the process helps you zero in on their specific pain points and craft the solution requirements to best address them.
#2. Map your existing system.
Provide a description of your current operating environment. In some situations, you can hold on to elements of the existing infrastructure. Keep in mind that with many VoIP deployments, it’s important not only to map your telephone system, but also your network environment. Include network diagrams and other technical specifications.
Then identify your pain points. Clearly stating what you don’t like about your current situation gives vendors the opportunity to propose solutions that specifically address and resolve your biggest issues. If your primary pain point is getting your current provider to prioritize your moves, adds, and changes—make sure your new provider can tell you in detail how they’ll do a better job.
#3. Determine needs versus wants.
As you map your existing system, take a moment to map your current features as well. Are there some you’ve come to depend on? Are there others you never use? If lack of features is one of your pain points, what are the core ones you’re missing?
When you draft your RFP, clearly identify which features are must-haves. This tells vendors who cannot provide those features that this isn’t the opportunity for them.
Then move to the features that would be nice to have. Maybe these are features you’ve heard of but don’t have much experience with. Or maybe they’re some of the features you have but don’t use very often. Either way, if a vendor can’t deliver on them, you’d still consider that vendor as an option.
#4. Research the available technology.
You’ll want a general introduction to what solutions are out there so you understand their pros and cons. This may impact the direction you take with your RFP and the preference you give to certain vendors who respond to it. Research like this will also help clarify how you want your system to look at the end of the RFP process.
For example, the differences between hosted and on-premises solutions are pretty dramatic. If you’re only interested in one over the other, state that up front. It’ll save you the frustration of sorting through vendors offering solutions you don’t really want anyway—regardless of how well they’re presented by the vendor.
#5. Structure the RFP for uniform, side-by-side responses.
Build out your RFP requirements so that responses are easily compared side by side. This will cut down on the paperwork and much of the procedural headache involved in RFPs. Some organizations find it easiest to create an extended chart or graph which vendors fill out. Whatever system you use, make sure it’s consistent throughout the whole RFP.
To help out with this, here are a few sample questions you can use on your RFP:
- Business history. How long has the service vendor been in business? Do they develop their own solution, or simply resell another vendor’s technology? What is their development methodology?
- Available features. Does the vendor offer the same or similar communications features and functions that customers have come to expect? For example: call management (forward, transfer, hold), voicemail, conference calling, mobility, unified messaging, etc. Do they offer new features that customers are interested in utilizing? What additional features are on their development roadmap? How are those new features deployed? Are they available to existing customers? Is there a cost to upgrade?
- Equipment. Does the vendor require specific, proprietary network equipment to support its solution? Or does the vendor use commodity hardware? Can the system be deployed across existing network resources?
- Support. Does the vendor support the entire solution? Is support available 24×7? Is it U.S.-based? Does it require an additional service contract to access it? Who may access the service (e.g., end users or only authorized administrators?) Does the system require certified technicians to be deployed to your location to perform system diagnostics and maintenance? Or can the system be maintained remotely?
- Survivability / redundancy. How is the vendor’s service delivery platform distributed? Are there multiple, redundant instances at geographically dispersed datacenters? What happens to service in the event of a public Internet outage? What happens to service in the event of a local power or WAN failure? What routing options does the vendor provide in the event of an outage?
- Pricing model. How is the vendor’s pricing structured? Does the vendor distinguish between basic and advanced users (or standard and premium features)? Or do they charge a flat fee for every user? When comparing prices, it’s important to ensure that prices include all initial and recurring fees, including hardware, software, user licenses, support, maintenance, features, training, etc.
#6. Make sure you get accurate pricing quotes.
Much of the RFP process comes down to price. In our experience, too many organizations flip through proposals and only look at the total cost. This is a mistake. In almost every case, the quoted sticker price doesn’t tell the whole story. In fact, many vendors manipulate cost proposals to deliver a lower sticker price that hides the nickel-and-dime charges that kick in once you’ve signed a contract.
Our suggestion? Don’t ask for the total cost. Anyone with a calculator can figure that out. Instead, ask for all the charges. List the features you want and demand that vendors fill out every line item. Ask specifically if there are any start-up or activation fees. Force vendors to identify service limits, feature add-ons, license fees, or upgrades. Include line items for service, support, and maintenance.
#7. Establish a clear timeline.
Set reasonable deadlines for each step of the response process. These usually involve dates for:
- RFP release
- Deadline for questions
- Answers released/addenda issued
- Proposal submission deadline
- Proposal review
- Bidder presentations (for the vendors that make the cut)
- Award
- Contract start
- Implementation period
- Go-live
#8. Specify your point of contact.
In the RFP, specify to whom questions should be directed and the responses sent. Identify if and how you want to be contacted during the RFP process. Even with the best RFPs, vendors still come up with a multitude of questions. Make sure your designated point(s) of contact are capable of answering the questions they receive. In your RFP, clearly define how answers to questions will be released.
Writing an RFP doesn’t have to be a nightmare. Starting out with a clear goal, and communicating that vision as clearly as possible in your RFP, will help you cut down on the paperwork and headaches and find the telecommunications solution your organization needs.