Avoiding Tech Regret: RFP with Results

Overview

1. What is an RFP?
2. How not to RFP
3. The RFP Journey: Research, Evaluation, Testing, and Selection
4. RFP Traps to Avoid

Transcript

Note: transcript is auto-generated, there may be typos.

Chiara Moore: I hope so. Can everyone, can everyone hear me all good? Okay. Uh, well, I, my name is Chiara Moore. I am super excited to be here today, uh, to talk to you all about a topic that might spark a range of emotions in this room. Yeah, RFPs. So whether, uh, that sparked a feeling of happiness or more likely a feeling of sinking dread, that is okay.

[00:01:00] Chiara Moore: Um, my goal is that by the end of this, you will feel more confident in how to run a successful RFP and maybe even a little excited about what the right RFP could do for you and your team. And before we get into the process that we use, let's make sure we're all on the same page. I'm sure everyone here already knows this, but RFP stands for request for proposal and it's essentially a way to compare different options objectively and understand the strengths and the weaknesses of each tool.

Chiara Moore: It can also be a really good negotiation tactic. It can help you negotiate better deals when you have multiple proposals in hand, and you understand why someone might choose one tool over another. RFPs can be a lot of work. Anyone who's run one of those knows this, so you have to keep in mind when it might be worth that work of running one.

[00:2:00] Chiara Moore: And there are a few criteria that pretty much guarantee that it's a good idea to run an RFP. The first criteria is if it is a primary tech at your company. I think. Safe to say. Everyone here is very familiar with the a TS. Um, that's a really good example of this. That's the backbone of your recruiting team, and really critical hiring is happening in there every single day.

Chiara Moore: Another criteria is if it's a longer term investment. Um, so if you don't wanna have to go through this whole process again in a year, you're gonna wanna make sure that you're picking the right tool. And the third is if it's cross-functional tech. So if multiple teams in the company are gonna be in and outta that tool every single day, it can create really, really big headaches that radiate across the company if you do not make the right choice.

[00:4:00] Chiara Moore: Um, so let's say that your tool meets those criteria. What's next? Um, before we go into exactly how to run an RFP, we're gonna talk about what an RFP is not. Uh, unfortunately, some of these steps might feel familiar to some of you. Uh, well, how not to RFP all starts with the CEO handshake, which is when your CEO gets lunch with another CEO, they really hit it off and by the end of lunch, surprise, your team has purchased a new piece of tech that has promised to solve all of your problems. The issue there is that it's very quickly usually followed up with the phantom functionality, which is when that team, that tool gets thrown over the fence to the team that's actually responsible for implementing and using it. But it never went through any real vetting. So that functionality that sounded so great over lunch doesn't actually come to life in the way that you expected.

Chiara Moore: And then it all comes full circle with the ghost town, which is when a few weeks after that tool launches excitement, totally fizzles and usage in the tool plummets because that tool doesn't actually solve the problem that it set out to in the first place. And in the worst case scenario, that can mean that you are stuck in a long, expensive contract with no ROI.

[00:06:00] Chiara Moore: So if even one of those steps felt familiar to you, you will understand why we wanted to do things a little bit differently at Confluent. Um, and it took a lot of hard work and a lot of collaboration, but I think we pulled it off during our last RFP process. We had 93% of our team participate in selecting that new technology. We are about. Three quarters of the way through our implementation with zero implementation surprises. Everyone, please knock on wood for me. Thank you. Um, and we have built very strong relationships internally within our recruiting team, with our stakeholders that we partner with at our company, and also with the vendor that we selected.

[00:07:00] Chiara Moore: And speaking of strong vendor relationships, it will probably come to no surprise to any of you that uh, we use this process to purchase a new a TS, which was Ashby. Uh, but I promise you did not just sign up for a 10 minute Ashby pitch. Uh, this is something you can use for any type of tool. It does not need to be an a TS. It doesn't need to be Ashby. The process that we followed to select our tech, fell broadly into four stages. Started with research, then went into evaluation, then testing and then selection. And you'll see that we really intentionally baked our stakeholder participation into every step of the process. And when I talk about stakeholders, I don't just mean the usual suspects of recruiters and sourcers and coordinators. I also mean the people that we. Partner with outside of recruiting, so that can be obviously your hiring managers and your interviewers, but also finance HRIS, people ops.

[00:08:00] Chiara Moore: And we started with a very long list of potential a TS vendors. And in order to narrow that down, we took a holistic approach. We started by talking to all of those internal stakeholders and understanding what systems they'd used in the past, what they loved about those, what they'd hated, and what they felt like they really needed out of this next system to move the needle for them and make that cha, uh, cost of change worth it. We also talked. To a lot of teams at companies that were at similar sizes and stages as us to understand their pain points, their best practices, and what tech was top of mind for them right now. And then finally, to close things out, we looked at G two reviews online to get a sense for the broader user sentiment around each tech. And that helped us get into the five tools that we wanted to really get into the details with. Um, and then it was time to think about our requirements. So in order to workshop our requirements, we, we ran focus groups with each one of those. Types of stakeholders because we wanted to make sure that our requirements were both specific and comprehensive enough to capture what they actually needed out of the tool.

[00:09:00] Chiara Moore: And the end product of running this process was a spreadsheet of 200 requirements that fell into 15 different categories of what we were looking for. And when we had our requirement document finalized, we sent it over to the vendors and they sent back their responses to us. And those written responses allowed us to get an initial round of scoring for each tech, which was really helpful, um, because it gave us a sense for kind of an initial view of where tools were stronger or where they were weaker. But then this is where we kind of started to deviate from what might be considered a, a standard normal RFP process because we actually took the time to validate each and every response to the requirement that each vendor sent us. And we did this in two different ways. So where we, where it was possible, we looked at their knowledge base, their documentation online, and we actually. Clicked through, read through how it would come to life in their tool, in their documentation, and where we weren't able to do that. We held live targeted demos with each vendor to have them actually click through every single step. And between that initial round of scoring based on the. Responses that they gave us and the finalized scoring, once we'd validated what they could actually do, the scores changed a ton.

[00:10:00] Chiara Moore: And there were a few reasons for that. So one of the things that we were really solving for throughout this process was efficiency. We knew that if a tool was going to slow down our recruiters, that that wasn't the right tool for us. And we found there were a lot of cases where maybe a vendor could technically meet the requirement, but it took way too many clicks. To get there. There were also cases where they said they could meet the requirement, but it would, it was going to take a third party integration to get there. It would take external development work and hours to get there. Or what they were showing us was actually an add-on tool that maybe wasn't something we had initially been considering as part of what we were looking for. So this part of the process was very clarifying for us. And if this all sounds like a ton of work, the focus groups and the evaluation matrix and going through all of that validation, it is a ton of work. It's probably just as much work as it sounds like, maybe more. It took our team weeks. Um, but this is where, where it will really. Pay off for you to go big. Um, you're, you can think about it as either, you know, paying that time upfront to really get your requirements right and make your RFP successful, or getting down the line in implementation and realizing that it doesn't actually work the way that you thought it was going to. That's a little more painful. And the end result of this evaluation process was essentially a heat map where we could see which tools were stronger and which were weaker and in what categories. And we had a very clear score for those tools, and it was super obvious to us which tools we wanted to advance to that final finalist stage.

[00:11:00] Chiara Moore: So we had our top two vendors that we wanted to look at, and it was time for us to take things for a test drive in both systems. So we ran a sandboxing process. We involved over a hundred members of the Confluent team where we took these. T sandbox environments, and we created prescribed testing scripts for people to click through. Obviously these were not fully configured or customized environments, so we had to keep things really structured and really simple and think about the one to two key workflows that that user type would go through in that tech on a day-to-day basis. And we had them go through that script and they would rate each workflow they went through and tell us how intuitive it was and give us.

[00:12:00] Chiara Moore: Comment, feedback on why they rated it the way that they did. And this was so helpful for us to compare those tools objectively. Um, and then at the end of the process, when they had gone through that with both systems, they were able to vote for their preferred tool. So we had this score of which tool our team preferred, but we also understood exactly why our team preferred it. By the time that we chose Ash V as our a TS, we were extremely confident in that decision. And not only that, but our team was completely bought in and really excited to kick off our implementation. Our team had been through a number of RFP processes at this time, at that point, collectively. And so as we were going through, we had a few traps that we knew were really easy to fall into during the RFP process that we actively worked to avoid.

[00:13:00] Chiara Moore: So if you and your team are thinking about running an RFP, I highly recommend that you keep these in mind. The first is just ignoring the PR of it all. I think we can all be honest with ourselves that we tend to resist change, that we did not get to weigh in on whether or not that change is for the better, even if it's for the better. And so part of what we did very intentionally here was making our stakeholders, owners, and advocates during that process, we really wanted them to feel that it was something they were driving, not something that was happening to them from talent ops. And part of making them owners, drivers of that meant that we held them accountable for being informed decision makers.

[00:14:00] Chiara Moore: And that's why we required that they go through that sandboxing testing process so that their vote was based on hands-on experience in the tool. It wasn't just what they were more familiar with or what they'd heard from their friend was good. And then finally taking things at face value. So this really became clear to us during the process of validating all of those scores, um, we realized that a yes no answer was not gonna be thorough enough vetting for us. And as an example of this, um. There. If you say that you want a tool that gives you smart scheduling, there are going to be dozens of tools on the market that tell you that they can do that. But anyone here who's been responsible for scheduling an interview panel knows that there is a ton of complexity, a ton of granularity underneath that requirement. So do yourself and your team a favor. And vet those requirements very thoroughly. You do not wanna get to the end of this process and find out that the functionality that your team was most excited about doesn't really exist or comes with a much heftier price tag than you originally realized. I. So this stayed pretty high level because I only had 10 minutes.

[00:15:00] Chiara Moore: But like I said, we've been through a few of these now and this time it really, uh, went drastically differently in a very good way. Um, so if you, uh, are about to run an RFP and you want more details on how we did this or you would like to see templates, please find me later today. I would love to talk to you more about this or come find me on LinkedIn. Thank you all so much.

Key Takeaways

• When to run and RFP: Focus on primary tech, longer-term investments, and cross-functional tools that impact multiple teams daily
• Combine internal stakeholder interviews, peer company insights, and G2 reviews to create a holistic vendor shortlist
• Use focus groups to develop specific requirements across various categories, ensuring both comprehensiveness and specificity
• Don't take vendor responses at face value - validate every claim through documentation review and live targeted demos
• Evaluate not just if a tool can meet requirements, but how many clicks and integrations it takes to get there
• Involve team members in structured testing with prescribed scripts to compare tools objectively
• Make team members owners and advocates of the selection process rather than passive recipients of change
• Address natural change resistance by ensuring informed decision-making based on hands-on experience
• Smart scheduling and similar features have complex granularity - dig deep into vendor functionality claims before committing