The Chaos Behind Choosing the Wrong RFP Tool: A Sales Operations Manager's Candid Lesson on Ownership

Sure. Um, let me take a note of this question so that I stay to the point. All right. Uh, so in my current role I'm working as a sales, uh, uh, director of global sales operations at Index, and, uh, I'm responsible for, um, uh, understanding the sales needs, uh, sales tools needs specifically, and, uh, uh, you know, uh, evaluate, negotiate contracts with the vendors and come up with the best technology that would help, uh, sales to perform better, enhance their productivity. One of the major uh channels of uh earning business for Iris is through request for proposals, so RFPs, both public sector and enterprise vertical, uh, um, actually get a lot of RFPs around 200 to 300 in a year, and basically the processes, yeah, the processes, uh, as you may know that it is time crunch. It is time time process so we have to basically be on track in terms of providing responses, submitting, meeting the needs of the, uh, you know, the DOTs, Department of Transportation, etc. and, um, ensure that, uh, you know, we win the business. So the win win rate for these RFPs uh was around 30 to 40% to start with. Um, my goal was to help automate this process as much as possible because it required a lot of cross collaboration between, you know, multiple teams, product management, engineering, um, uh, legal finance, uh, pretty much all teams, uh, had some kind of feedback that used to go as part of the RFP and to automate this type of, uh, process, it would require really sophisticated tool. Um, my systematic evaluation, uh, approach is always go for, uh, at least 3 tools evaluation and, you know, based on the feedback that I received in the from G2.com, which is a software website where I can see pros and cons of, you know, individual industry leader tools also, uh, getting feedback from the users, the real users from LinkedIn or external sources that I can approach. And basically I went with a tool called LUO which is uh which basically vouched for a completely automated solution for RFP management and to this day I think it is one of my favorite tools. However, uh, considering the requirements that Iris had, uh, especially when it comes to different verticals, public sector enterprise, and automotive. Uh, the tool did not really work the way we had anticipated. In fact, it created a lot of chaos because, uh, earlier the process was managed in SharePoint and we basically had all our knowledge repositories,

Definitely. So basically going with standard simple word document, people, you know, trying to open it real time, trying to cross collaborate, and it crashing, it crashing on us, right? So that was the SharePoint story and moving it on Luo, I thought that it would be really great tool for us to cross collaborate. Uh, also have timely reviews so that the product management makes sure that uh the product descriptions are on point, latest, up to date, reviewed, and, um, and so, so on and so forth, all the boilerplate material. However, uh, for public sector and enterprise where the process was very standard, uh, just like, um, any other company in the industry, it worked fine, but when it came to automotive, the process was very different, um, in the automotive vertical we have. Not just the RFP response that we provide, but there are also something called a deviation list that we have to provide that means um whatever product features that we support, that's one answer but whatever products, uh, product features which we don't support and which we have where we have workarounds, those are the those are the documents which actually go through multiple rounds of negotiations with the customers. So consider it around 7 to 8 rounds of negotiations. And that's where this tool totally failed, uh, and basically, you know, drove the users away from the tool, and I think that is one of my biggest failure because we had invested around $30,000 in that particular uh uh tool at that point in time, even when we were tight on the budget. And uh still and and it didn't basically, you know, provide the way we provide the required output as we thought. So my next to, to, to recover from this, uh, failure, uh, basically I had to tighten the controls on SharePoint's side, right? So, uh, what I did is basically uh created a knowledge repository, which again, uh, had, you know, ready 70 to 80% of the ready boilerplate material that goes into RFPs. So that helped in just having a go to resource for, for uh for this type of information for the remainder of 30% of the proposals where I needed uh in uh involvement from other cross functional team members, I launched an automated approval process on Salesforce which. Is our CRM that we use, uh, which then, uh, quickly notifies, um, all the stakeholders about the RFP that has come in and, uh, their involvement requirement, uh, give them a quick agenda of, uh, what's the basically the game plan, the timeline, the inputs that are required from their end, and basically help. Uh, help bring in some automation, if not all, into that process.

Yes, that was predominantly the major issue because LEO was designed in a certain way where from start to end we would be able to automate a process if, if it's more of a sequential flow versus iterative flow, right? So in case of automotive, that that's what happened in round one we would submit a document called deviation list to the OEM auto automotive manufacturer. And uh they would then come back saying out of these 100 features we would like to uh discuss or shortlist these 60 features. Now let's think about how we can provide work around around those 60 features and what would it cost, uh, what, what would be the impact in terms of, you know, engineering costs. Sources that would need to be involved now we would go back with that as part of round two and then the OEM would come back by weighing the if if something is very costly they could, you know, deprioritize those features and then again come back with let's say 40. Features. So this type of iterative uh uh um model didn't really work on loos side which then um broke the process where, you know, we could only deliver certain amount of automation and not the entire process.

So, um, uh, as I said, like public sector and enterprise side, they started working very smoothly. Those were the systematic RFPs that we could, uh, you know, uh, drive in through LPO pretty quickly. So within, uh, 1 to 2 months of launch, public sector and enterprise RFPs were, uh, pretty much smoothly running on, uh, LPO side. However, um, depending upon when the automotive RFP launched. I think we realized this when 3 months down the line when we were in the in already, you know, established a process around public sector and enterprise vertical for WPO and we're basically onboarding automotive. So after 3 months we realized that oh, this doesn't seem like a perfect. Solution for automotive RFPs and no matter what we try to do it didn't really work uh because of the specific nature of the way we do the business in automotive site and respond to the RFPs.

Sure, that's a really, a really uh great question, Brandon, um, for, um, uh, when it came to the automotive RFPs, as I said, I mean, there are, there are, there are two ways to look at it. One is the, one is the regular response which goes via, you know, 70-80% of the response document is actually your boilerplate information. And that remainder of 30% of the deviation list that I spoke about where we have to provide this workaround, right, uh, by the nature, uh basically, uh, when we started reviewing this we had a lot of flexibility in terms of the format of the document. Uh, we were not very, very much like married to, uh, the format that the sales team was using at that point in time. And when, when we were gathering requirements, uh, there was flexibility from the sales team side to change into a format that is compatible with Loopu, right? So that 11 trigger, uh, basically helps. Help me, uh, think that OK, this may work for automotive as well. Now when it comes to multiple rounds of negotiations, uh, we basically, uh, realized that uploading, um, uploading certain, uploading the size that's the, the size of the document was also a big issue actually when it came to automotive. which was not identified earlier, uh, as automotive RFPs come in with uh multiple files and not just, uh, PDF documents but also some graphical designs, uh, which, which was not something which was identified during the requirement gathering gathering, and that is why it caused the, uh, failure towards the end. After implementation.