Need innovation? You won’t find it in an RFP

Are you looking for new, innovative software for your telco? Here’s a piece of advice: don’t use an RFP to try to find it.

I sat on a panel recently at TelecomTV’s Digital Service Provider Leaders World Forum called Capitalising on an Open Vendor Ecosystem where I stated—quite bluntly (at 25:30)—that RFPs actually prevent telcos from embracing innovation. Somebody jokingly asked to take my mic away afterward, which is partly how I know I’m on to something. But I’ve been advocating for this change for awhile, and even wrote a short thread about it back in 2019, on Twitter.

RFPs (What are they good for?)

To be fair, let me start by saying there are some situations where RFPs are actually useful. They’re great when you are trying to find a vendor that has a commodity product or service. By creating a list of requirements based on the current state of the world and forcing N vendors to respond exactly the same way, you can find a vendor that meets your needs AND make sure you get the cheapest price. It’s a great way to comparison shop, if that’s what you need to do.

But stop any vendor on the street and mention that you’re putting out an RFP, and you’ll get a bunch of moaning and complaining because everyone universally agrees that RFPs SUCK. They’re often a total waste of time, and a money pit, too, especially when they are used to elicit a stalking-horse bid, or to get quotes from “one or two more vendors so we can say we got multiple bids.” (Remind me to tell you about the time I spent $1.5m on an RFP response … AND LOST.) They also encourage bad behavior from vendors because there’s incentive to claim as much functionality as possible just to make the short list—regardless of whether or not those claims are true.

And what if you’re looking for innovative, disruptive, new vendors? In this case, RFPs are a TERRIBLE way to evaluate vendors and products. New tech (like products that use the public cloud) perform poorly on RFPs that have been written assuming the state of the world (and the tech) hasn’t changed much. I read RFP after RFP where the questions assume the same old way of doing things, and the format doesn’t allow for new vendors to really highlight how they are different from incumbent vendors.

For example, in charging software RFPs, you’ll find questions about dimensioning hardware for the deployment, or how upgrades or change requests are handled—because for all of the dinosaur vendors, this is a big portion of the cost of the system and it’s a key way to evaluate them. But what about vendors like Totogi (where I’m acting CEO), which is a SaaS, multi-tenant software product, that runs exclusively on the public cloud? How do you answer these questions when the business model is offered as-a-Service, where there’s no hardware to buy, and no upgrade to be done because you continuously deliver new features into a multi-tenant product? Or what about the open-RAN vendors, answering RFPs that assume an old-school RAN deployment model? These new business models and new approaches don’t do well in the old-school RFP format.

Thankfully, the world has changed. With the advent of public cloud-based SaaS software, there’s now a reason to throw away your lame, slow, boring RFPs. Instead, just give the software a try yourself. With no hardware to buy or software to install, you can sign up for a quick trial of the service, and if you don’t like it, stop using it. SaaS vendors usually offer a free trial or free tiers, allowing you to start small and see how their solution works for your organization without committing whole hog.

By using the public cloud, SaaS players have ushered in a test-drive mentality that has changed the way organizations buy software. For example, Salesforce lets you use its customer relationship management (CRM) system for free for one user forever, giving you access to most features. Zendesk gives you access to its customer support Zendesk Suite Professional plan for 30 days for free. In both cases, you have access to a full, in-production, live system. The work you put into setting up your instance is not lost if you decide to use the product; if you want more users or want to continue using the product, you just pay for it. On the other hand, if the product is not meeting your needs, you stop using it and stop paying for it. It’s that easy.

Modern solutions now offer free trials, free tiers, and pay-by-the-use pricing, which render the RFP obsolete. So ditch it! Instead, change your procurement mentality with these three mottos.

1. Start a trial

Is there a new solution out there you think might work for you? Then ask for a trial and test it for a few weeks (usually for FREE). With this approach, if it doesn’t work, you just stop using it. No harm, no foul … and in most cases, not much money or time will be wasted, either. For example, with Totogi, you can be charging transactions within one day of network connection. That’s it! People are amazed it doesn’t take months and months of work and testing. And when there’s no hardware to buy or software to install, it’s super easy to figure out if it can work with your network. BOOM.

2. Test the big middle

Don’t try to boil the ocean and test every single edge case you can think of, from 2G voice to network slicing. Start with the “big middle”—the main use cases that cover most of your subscribers. By starting there, you’ll figure out in a short amount of time if the solution is a potential winner. So many people start with the esoteric edge cases that cover 1% of subscribers, but if it doesn’t work for the main use case, there’s no use in testing edge cases because it probably won’t work for your organization.

3. Test the boundaries

Once you know it can work for the big middle, *then* you should add more and more use cases to test what works, what’s easy or hard, and where the limits of the solution lie. You’ll see for yourself what’s in the product, what can be addressed with configuration (minor, non-coding changes), and what requires customization (coding change requests). Usually, this will involve talking to the vendor to get answers, but you’ll walk away from the conversation with a good idea of what it’s going to take to cover all of your requirements, both in time and money, as well as with an impression of the vendor. Since you’re hands-on with the product, you’ll have firsthand experience with it, instead of the vendor’s description of what it’s like to use the software. This is way better than trying to imagine it via a 500-page RFP response.

Here’s a great example: when the TelcoDR team was getting ready for Mobile World Congress 2021, we knew we needed a project management solution to help organize the planning of a 65,000 square foot (6,000 square meter) booth and all the work we needed to get done in 90 days. We didn’t put out an RFP. We just used free trials of Asana and Monday.com for a week. We ended up using Monday.com because it was easier for us to learn in a short period of time, it met our needs for the project, and it was cheaper. BOOM.

So ditch your RFPs and use the public cloud to test-drive SaaS vendors’ free trials and free tiers. I promise you, it’s a much better way to buy software in telco.

PS. Sick of your charger and want to try this new approach to buying software? Try ours!

Recent Posts

Get my FREE insider newsletter, delivered every two weeks, with curated content to help telco execs across the globe move to the public cloud.

"*" indicates required fields

Email*

Email

This field is for validation purposes and should be left unchanged.