📱

Get Our Mobile App

Take your business learning on the go!

Download on the App StoreGet it on Google Play

How to Write an RFP

EPAY Systems1:02:02

Transcription

Good afternoon and welcome to our webinar today from IPE Systems on how to write an RFP and managing your buying process to help you make that decision. My name is Michelle Lancer Smith, and I am the Chief Marketing Officer here at IPE Systems. And joining me is John Gotti, our Lead Senior Sales Engineer.

Hey everybody, thank you for joining us today. This is actually kind of an interesting topic for me, Michelle, not our norm, and actually like a little refresh, refreshing to do something a little different.

Yes, it is. We receive thousands of RFPs all the time and have to sort through them and work through them. And we see clients and customers that do it right, and others that really struggle with the process. And often times, we are asked from our clients, "How should we go about and do this?" So, this is basically what we've done is collected all of our learnings and what we share with people that ask us, and we're going to present it to you for the next hour.

Now, that we are going to open it up to questions, not using your voice, but using your fingers. So, when you have a question, just go to the right-hand side of your screen, look for the box called "Questions," and type it in, and we will try to answer as many as we can as we go along.

So, what we're going to do in the next hour is, I'm just going to briefly talk about ETA Systems. We do have both customers and new folks on the line today, so I want to do that, take care of that little piece of homework. And then we're going to talk about what is an RFP and RFI, RFQ with different reasons for them. Really, how do you plan for an RFP? The timeline, things you need to include, how do you evaluate and score, and then common mistakes that Jan and I see all the time. So, we've got last two tips to share with you. So, we hope you enjoy today.

Well, who is a paid system? We have been around since 2001. We're headquartered here in Chicago, Illinois, out of the Windy City, and we provide a fully unified HGH CM or capital management solutions. That's HR technology, payroll technology, and time and labor management technology in a fully integrated solution. We serve hourly workforces. So, we tend to work with clients that have a very complex workforce environment, typically distributed, might have people moving from site to site, location to location. It just causes all kinds of crazy shifts, differentials, you know, paying people differently over time, difficulty in scheduling people, difficulty in getting the right collection devices to capture their time. So, that's what we've focused on. And we have always been in the time and labor management or your workforce management business since the very beginning. And what people like about us is really that flexible engine that we provide. And because of the flexibility, we can take care of and handle the very complex workforces. People also really like our support. We offer 24/7, all year around support to everybody. We don't have a gold and a platinum service. Everybody gets free premium support, and that is from for all of our modules within our human capital management platform, from payroll to time and labor to applicant tracking and so on. And because it's 24/7 support, they're constantly getting their questions answered. We have a great retention rate with our clients. You can see some of our clients there, but we, of course, have many, many clients ranging from small to mid-size to enterprise clients. That's a little bit about it, you pay.

Let's get into our topic today. So, John, let's talk about the RFP. And it's a very humble beginning. What was the origin of it? How did it start?

Yeah, you know, it really started out as a way to have a non-biased view into getting a bunch of different proposals all into one, so that the end user can evaluate them effectively, right? And have a, have a way of looking at the data and identifying, "This is a good fit for me," or "No, this one doesn't meet the bill," right? And is look at the different types that are out there. You know, an RFP, an RFQ, very similar, right? Request for a proposal or request for quote. You're looking to identify a vendor of choice that way because you're getting pricing on that. You're looking to get that information so that you can actually make a decision on, on a particular product.

Then RFI is slightly different. That's definitely the first start of an RFP process. So, sure, when you look at a government entity, there's, they're going to go in and do an RFI first, just part of their processing and how they have to handle that. With the RFI, you're not really looking for pricing in there. You're looking more to gather information about different vendors, or you may not know anything about what you're trying to buy, and you're just trying to gather additional information so that you can become educated about that. And that's what we definitely see an RFI.

Now, an RFI is a short form of an RFP, right? So, we look at RFP or RFQ versus RFI. You're typically seeing the RFI as a short version. It's not as many questions. Everything is more high-level, whereas an RFP, you're looking at very specifics because you have your own specific needs, you want to make sure you meet those requirements. And I will talk more about how to, how to look at some of that stuff around here.

So, you mentioned government contracts. And in the government world, we see an RFI first, then they go get their funding, and then you see the RFP. What do you think is, besides that, what do you think is the difference in terms of a government versus commercial, this whole process, I should say?

So, government is very strict policies on, on how they have to essentially buy from the public, right? They have to go out for quotes, right? And that first process is doing an RFI and actually for them to identify particular vendors that, that are going to fit the bill, right? And then from there, once they've created an RFI and they've gotten responses back, they now have their initial data to go back and say, "Hey, we need a budget for this. These are the reasons why," right? And then they move it over into an RFP. Now, they get the proposals or the quotes, and that way they can finally get into that and decision, select the vendor, have their contract negotiations, and then make that, that announcement of who the actual vendor is for that.

Yeah. Ah, now, on RFIs, what do you typically see or what is best practice? Should you ask for pricing information on an RFI?

An RFI, you typically don't see pricing information on an RFI. It doesn't mean that you can't ask for it, but expect it to be a very high level because you're not giving, you're keeping it very short, right? And you want to make it a short process for that. So, don't expect the pricing, the whole tree. When it gets to an RFP, where there's more detail, and now we start to uncover more things that need to be done, and there's more jargon that weren't in the inside of that RFI.

Well, let's kind of get into the meat of things and talk about what you need to do to ensure the success of a good purchase process, I guess. And the overall timeline, how long does the whole thing tend to take from what you're saying with your client?

What I typically see, especially in the HCM industry, is we typically see about a two to three month turnaround from a project planning point of view. Meaning, you're trying to figure out, "What do we need?" Right? You're planning out your needs, you're drafting up your, your RFP, which is giving it all the information. We'll talk more of what's included in there in a little bit here too, as well, to going out to sharing it to the different vendors, to the vendors responding, and then you're going in and doing the reviews and also doing demos, and then you're into your final decision, right? So, it takes about a two to three month timeframe to actually go through that entire process if you're doing it effectively. Now, I'm speaking from HCM, it could be shorter for other pieces of software, right? You know, in part of it, it just ends on the complexity of what you're buying, and that's really going to determine what that timeline is going to be. But you need to make sure you do your planning right because that's very important in anything that you do, really. You know, if we, whatever I kind of look at this as, you're creating a report from scratch to find what you want, right? And that's kind of what I look at this as an RFP. You have a project to find what you want, but then also give the pieces of information that are needed so that you can get the right responses and have a good way of identifying who's a good vendor and who's not.

Okay. Well, when it's time to get started, let's look at what are the first few steps you gotta do to get gone?

What you want to define who your point of contact is, right? Who's going to be that go-to person where all the vendors go to to ask questions, to send out communication to the vendors, to really be that, the facilitator of, even down to the demo stage of, "This is what's expected. This is, we're scheduling," etc. Have one point of contact. Don't have multiples because you're going to end up having too much mixed information from too many different people, right?

Absolutely. You also want to have a selection committee, too. So, it's not just one person makes the decision. You want to have stakeholders that are part of that process, who are going to be using that, that piece of software. You want them as part of that selection committee because they're ultimately going to be using. You want their buy-in. So, you want them to have a say, "Yeah, this is going to work for us," or "No, this isn't going to work for us." Because if you leave it up to one person or one group, they don't know everything that goes on in every department and how that's going to work for that part, right? That's why you put together a committee. Now, it doesn't have to be a 59 committee, right? You still want to keep it to a small group, but just make sure you have key stakeholders part of that.

You also need to set up your timelines, right? And you want to identify, you know, "Hey, this is when we're starting the project. This is when we're expecting the RFP to be sent out. This is the timeframe for questions. This is the timeframe for responses. This is a timeframe for reviewing and selecting finalists for demos," etc. So, you want to set up what your due dates are so that everybody knows what to expect. It holds you accountable to those dates. It also holds the vendors to those dates as well, right?

I'll stop your bunch of parameters. Get an idea for what you're willing to spend for the project as well, because if you find out that, "Hey, all of these are we overpriced? We don't have a budget for it?" Then this project can't exist, right? Or I need to go and figure out how to get more funding to actually think this work, right? And finally, you do want to do research on various vendors. You know, you can, if you ever watch what we do in the shadows, Google it, right? Here you can go in and find vendors in different industries. So, you know, it's easy to do those searches to find them. But then you also, it's okay, it's not enough just to find the vendors and say, "Hey, they do this, right?" Call them, talk to them, get some product brochures on, do a little research of your own about that company and see if, "Are they really a vendor that, that might work for me, or am I wasting my time with that?"

Yeah, I definitely agree with that. You definitely want to call those vendors, talk to them, get your salesperson, if each vendor. Yes, you're going to have to talk to a salesperson, but you need that contact because you'll see down the road why you need that contact because you're going to have to be able to send them your RFP. You'll also need to, like Johnson, you got to get that budget information, otherwise, you really don't have a clue how, what kind of questions or what kind of criteria to give them so that they can give you a price properly. If you don't understand how this piece of software prices, right? And it's also why it's important to talk to the vendors too, ahead of time, so that you can understand, "These are the pieces of information that's needed to price it out." Because if you don't know and you're just saying, "You know, give me a price," you kind of want to know how are people pricing it? That way I can set up some sort of a form factor of identifying pricing so I can look at everything evenly across.

Absolutely. So, you got to get educated. The other thing too, I thought of that we don't have on here, but is a good thing is when you meet with that committee and whoever the point of contact is, probably typically the ear of this whole process, you do need a leader, ah, because there's just too much coordination and decision-making and to be done. But you need to spell out, probably from an executive champion, "What is the vision? What are we trying to do here? What are we trying to accomplish?" So that everybody's on the same page. Because as you have different stakeholders involved, people have their own priorities based on what they're looking for. And so, you need the executive to say, "Now, this is why we are looking at this and doing the therapy, and this is what the company needs to accomplish. So, these are our goals. This is how you need to go forward." And then after that executive speaks, probably establish some ground rules in terms of when you're talking to vendors or keep demos and things like that. We'll talk more about that, but I think that executive championship and vision is very important so that everybody gets on the same page.

Okay. So, let's get a little bit more into project planning. What do you think it's better, John? You say you start today and say, "Okay, based on what we need to do, we can have a go-live date this time," or do you start with your desired go-live dates and work backwards?

For me, I think it's important to start with your go-live date. You know, "When do you want to start? When do you want to have this, this piece of product live and up and running, right?" And when you can decide on that, you can work your way back and identify, "Okay, it's going to take, you know, approximately, you know, a month for negotiations. It's going to take a week for the final answer," etc. So, you can work your way back and identify, "Is my go-live date rational? Is it, is it something that can be met or not?" And if it can't be met, now I know that. Now I can see, "Okay, this is what it's going to take. Now we can figure out exactly, okay, I need to move everything by a month or two," because it's a couple extra months that I, that I originally thought it would be once I actually did that planning. That's why I think looking at it from the go-live date first is the best practice so that you can work back and say, "Yeah, I'm in line with this," or "No, I'm not. I got to push it out." And if you do have to push it out, then now your go-live date as well.

Yeah. So, in this here, we talk about, you know, you're going out, you're distributing your RFP. And the, the first one, you set the date, you get a, let's say, you get a bunch in, right? Um, but then look at that bullet number four, vendor finalists notification. And then you go on from there. So, what is the pot, maybe the right amount that you kind of want to start with, and then what do you want to narrow it down to process?

So, you don't want to have 30, right? That's just too much information to look at. You still, you want to keep it to a big enough group where it's manageable because it, what happens is when you get too much data, you're, we're trying to look at too much data, you end up putting things together that aren't there, right? So, if you keep it to about five to seven vendors to start with, you narrow it down to three, you're looking at small chunks of data to make your decision. So, it becomes more manageable in terms of, "I don't have to communicate with twenty people. I don't have to communicate with five to seven people." And guess what? There may be vendors that say, "You know what? There's things in this RFP that we can't meet." Or out, guess what? You have the ability to go in and find enough replacement for them, right? So, keeping it at that small amount, it's probably, if it's really your, your best bet because the other thing is that you have to review all this information as well, right? It's not just, they fill out an RFP and then all of a sudden, by magic, I know whether the right vendor is. No, you have to go through that data. And we'll talk about how to, how to manage that in a more effective way as well here in a little bit by using scorecards to really help identify that, just to make it easy on yourself, right? And we'll talk about some of that stuff here.

So, what happens though if you don't get enough initial request for proposal?

Well, the great thing about this is that this is your RFP, right? You have the ability to make a modification, but you have to be fair about it, right? So, if you say, "Hey, I only had two people respond. I'm really looking to have at least five people." Obviously, you want to go out and find those additional vendors, but that may also have you push out, you know, when responses are due because now you're finding the vendors and pushing it out. You want to be able to extend that out and let the vendors know ahead of time, more than just the day of, that, "Hey, we're extending it out, right?" It's that common courtesy of, "Hey, this is what's happening. You know, we haven't seen enough responses and we're extending it out."

Okay. Well, let's talk a little bit about then actually putting that RFP together. What are some of the key components that you see over and over again that tend to work nicely?

So, what I find that's great is that you want to give an introduction about your company. What does your company do? What, what's your some of your core values? Because sometimes you're looking at core values of your vendor as well as core values from you to make a right match, right? So, you want to see that type of information. You also want to give a purpose. Why, why is this going out to art? Why are we doing this, right? We also want to give scope of works. Identify, "This is what we're trying to get out of this piece of software, right?" And then you also give them the schedule of dates. You can include an NDA or company confidentiality statement in there. Also, giving clear-cut instructions on how you want that RFP to be constructed. But don't make it so convoluted. If, like I saw one last month that I read through it, I had no idea how they wanted to construct the RFP in response, or in fact, right? Make it clear for the vendor and let them know that this is how we want to see it come back. And there's great ways of doing that. One is, you can, we'll talk about again this more a little bit later, but you can have a PDF with your introduction and company profile and all of that, and then you give them an Excel spreadsheet to fill out for everything that they need to fill out, right? And then also tell which order needs to go in. If it's, if you have additional documents that need to be signed, ah, fine, tell me which order you want to see it that way, again, it's that same process for everybody. Everybody's got all the same information. You're all looking at it the same. Just follow those things, right?

But you actually also need to know about that vendor profile. You can ask for financial information. Don't expect it to get it from private, privately held companies. You know, it's something that they're, they're willing to give it to you, but they're not going to give it to you on our right. And they'll typically give it to you later on in the process if they are finalists. But don't let that scare you if they don't give you their financial information. It's just a, you know, they're privately held, they kind of hold on that as closely as possible, right?

Now, you also won't need to know and add in their product functionality. Can the product function or have the functionality that I need, right? So, you're spelling out exactly what your needs are. We'll talk about that one. Look at scorecards and functionality and how to process that. Also, you may want to know about the technology and security processes and things like that. Also important is what's their implementation strategy, right? And again, the more information you give, the better they are to include an implementation timeline for you, depth specific for you, based off of what they're seeing, right? Now, that is an estimate. Things change, right? New customers are being added on. Implementation teams shorten up with, with resources. So, you can expect, you know, at least the timeframe in terms of the number of days or weeks or whatever it is to, to accomplish it, stay the same, but maybe the dates change. Like, right, and you work with your vendor to get as close that go-live date as possible. But part of that is also the vendor has to look at, you know, when you're expecting to go live date is and your decision press and identify that, "Yeah, this is a feasible timeframe to implement," or "No, it's not," because extend it out. And they need to be upfront, honest with you on that as well, right?

And then customer references. This is not something, it's not something to expect a customer to, or a vendor to give to you in an RFP. And plus, you're not calling on those references anyways if they haven't made it to the finals, right? When they get to the finals, ask for customer references, then, right? And at that point, have the vendor facilitate the call for you as well. Not that they're going to be on the call, but have them say, "Hey, let's let schedule that call for me with these references." That way, you let them facilitate that call and schedule it out for you without you having to reach out to that, that, that reference. Because vendors don't want to bug their customers for customer references. And when you add it to an RFP and they have no idea when this is going to happen, you can give them a warning that, "Hey, you know, I included this you as a reference for this RFP, but don't expect a call, you know, until a couple months out." That's not fair to that customer. They're going to forget because that's not as important for them. But also, you may never call them anyways. So, set the expectations that, "Hey, you know, if you make into the finals, expect to for for you to give us a customer references, and then also we expect you to kind of facilitate that the schedule goes out, right?"

Yeah. What you can do with deception instead of in the RFP asking for the specific names, ask about their install base. How many customers do you have? Where they located? Which industries verticals? You know, don't expect that they have a hundred percent of your type of industry that they're doing there. Might be serving multiple, but it's nice to understand what industries they play in because that'll tell you the skills with their people behind the software and what they know. So, that's really what I would do with that one.

Yeah. And then obviously pricing and cost of expectations, right? Because you need to, you know, what this is going to cost me, crying. Okay? So, you need, you need obviously include that in our processes. And again, the more data you give the customer, the better they can price it for you.

What about training? Where would us then to explain training?

I would explain training in the implementation process because that's going to really be where the train should happen. Training shouldn't happen after go-live. Training should happen pre-goal live where people are getting trained on the system so that are getting comfortable with it. And that's going to be during that process. It is nice to understand what kind of train is available to you afterwards because you're always, you have people leave and you want to be able to retrain them. So, the training is important.

So, just to emphasize a couple points, that introduction and company profile is very critical because, as John said, that's where the vendors are going to understand your configuration and they can envision what's the kind of how their solutions will meet your requirements because they just say seniority type of company over and over again. So, you give them some key facts about your number of employees, in your sites, and your locations, and so on and so on. It depends on the RFP. That's important. It's probably also what they're going to use to price their proposal off of. And so, that's important. Whatever you've learned in your initial research of holiday price, make sure you're giving them those, those criteria in this introduction, in the company profile piece. And then the other thing is when you ask them for pricing, different vendors price different ways. They may price by seat, they may price by per employee per month, by license, or whatever. And that will get really hard for you when you're trying to evaluate one person's price over another. So, use something that can't change, such as, "What's my bottom line monthly cost?" You know, that then to make sure that they explain that to you so that if I have X number of employees and you're selling buy seats and I know my monthly cost is this, or if it's some other way. So, what is the monthly cost? But get to that monthly cost so that you have a very definite number that you can compare from one vendor, right? And you may also want to go there, what's the first year cost, second year cost, their gear costs, or things like that? Because if they have maintenance fees that are yearly or things like that, you want to know that again so that you can compare things side-by-side and understand exactly, "Yeah, this is what the cost is going to be," or "This is higher or lower," and I have something that's comparable.

All right. Well, we're going to dive more into the whole product functionality and how do you get that information back because that's obviously the key part of the RFP. So, how do you recommend setting it up, John?

So, the way I like to see this when I'm reviewing an RFP, and I'll give you the reason why I like to see it this way, is I like to know what's required, what's a nice to have, or love to have, and what's a like to have, right? So, um, and the reason for that is is that when I'm going to that process, I start to understand more about your business. So, it's not just that front information, number of employees, and, you know, all that other, you know, what, what's my company do and all that. It's also when you're looking at the features, as a vendor, you're starting to identify, "Okay, this is what they're looking for, right?" Now, you can start to form a basis of everything that they're looking for. And it's also letting the vendor know, "These are things that are very important to me, right? This is required." And say, "I have a hundred things that are that are required, and I can only do 50." Others, right? As a vendor, you know what that tells me? "This is probably not a good fit. I'm going to bow out, right?" And that's why it's nice to show that information because again, that vendor is start, starting to know more about your business and what kind of functionality you're looking for. And what you're telling them, "This is required. This is a nice to have," right? And so, it's just, it's helpful for the vendor. It's also helpful for you because you know what just what's required for you and you can also score these in the right way as well. Very important piece.

So, when you set it up like this, you kind of, you need to get even more information than from the vendor. And the feature set that they're providing, how do you recommend they answer your requirements statements?

So, have, have a set of, obviously, this is part of the instructions, right? You want to set what are the values when they're actually filling out that, that sheet, right? You know, is it standard for the system? Is it on a roadmap? Is it something, is it not developed yet, but it is on the roadmap? Is there some customization that's going to be needed? I've even seen some that are, you know, it's configurable by the customer. So, so again, this is up to you and how you want them to respond. But these are some of the ones that I see that are good. It just helps identify, "Yeah, this is standard," or "System. It's great. Move on." Future on the roadmap. You know, customization, and they're going to fill out the codes there, right? The comment allows that vendor to extrapolate on something that says, you know, "It's a future on the roadmap." Okay, great. Why does it do that? That's something that you can actually ask and have as part of the instructions. Say, "Hey, if it's future, indicate when it's expected to come out." Or if it's a customization, you know, "Describe what that customization might look like, right?" So, it gives you that additional information. And you may see something that says that they'd answer a standard. They still enter a comment because they want to clarify it because sometimes that requirement, it's a gray area. It's not simply a yes or no. It, yeah, it can work, but it works in this way, right? It's still really a standard feature, but as a vendor, I want you to know this ahead of time because I feel, feel it's important for, you know, that this is how we're going to.

So, so from this point, let's, let's put ourselves in a scenario, right? And now we have, let's say, six different RFPs came in. You now have to take what the product functionality, this spreadsheet of all these requirements, and how the vendors answered them, and you have to do some sort of scoring, and you have to basically to come up with a number. But not everything is created equal here, right? So, if, if you look at the, the top box, if something is standard, alright, they say it's standard in the system, and you said it's required, you got to have that. That's worth a lot of points. Whereas something that you would just like to have, and maybe you would have to have it customized and spend money on it, it's not worth its lesser points. It's not, it's not as ideal, right? So, this is, there's a lot of ways to do this. This is just one idea of one recommendation of how you could score all of these coming back on this product functionality piece. And you can see here, we awarded points based on this table. So, if the then of you said, "This feature, I love to have," which is that middle column, "would love to love to have it, not required, but we love it," and the vendor comes back and says, "Well, it's going to be on our roadmap in the next six months." Well, that's for some points. That's worth four points. Whereas if you said it's love to have and they've got it today, that's worth more points to you. So, it's a five.

Yeah, I mean, essentially what you're doing is going to sound technical, but you're creating an algorithm. But the great thing about Excel is that, and we'll talk about why Excel is so powerful for these, is that your criteria. There's algorithms for the calculation of saying, "Hey, if it's standard, it's required, it's this point." You can even say that, "Hey, if it's, if it's required, it's this many points. Into the love to have, it's this many points. You know, this is the highest point tool to like to have it, this is the highest point total." And then you can say, "By the way," and have Excel calculate all this, you know, "If it's standard, it's 100% of the points. If it's future, it's 80% of the points. It's, it's customizations, it's 40% of the points," or whatever that is. But you have the ability to adjust that based on what you want it to be. But ultimately, what you're doing with the scorecard is you're making it easy on yourself. Too many times I've seen RFPs come in and the vendor is just looking at question and answer. The entire RFP. "One, I hate filling those out. We just got to get it out there."

I know I am. Absolutely. As a vendor, I hate filling it out. As the, and I can only imagine the person on the other end reading it. They have to read through five of these, and these could end up being 20-30 pages. Change. That's a lot to go through, right? So, when you actually create these scorecards and having the vendor just fill out, you know, "Hey, this is a standard feature," you know, etc., and you assign these points to it, what you're ending up doing is you're actually creating a very non-biased view into the vendor and identifying, "Hey, these are my total points possible. This vendor has 18. Guess what? They're, you know, they're number two on my list. Another vendor has 20 points, right?" So, it allows you to identify based off my point totals, "This vendor is going to work out very well for me based off of my requirements, whereas these bottom three, you know, they're at, you know, seven points. That's really not going to work out. I can, I can eliminate people very easily just by looking at their score, right? Without having to read a novel."

Five. So, exactly. Yeah. Yeah. So, definitely something to be learned from us seeing so many of them on how some people are just asking for a lot of pain.

It's okay to to ask, you know, "Hey, give an overview of this portion of the product, right?" It's okay to ask for that. But that, that's more for just added bonus to identify, "Okay, this is what it feels like," or "How they're explaining it." And then now these are the requirements. Can they handle them, right? You still want to ask those requirements. You know, "Can you do this?" "Yes, great." "No, you can't." "Okay, great." You know, you scored in an appropriate way. Just makes it easier for you to evaluate, you know, five vendors or five and vendors versus reading pros now. And there's really no reason to ask them anything that you can't read on their website either. So, and I'm not just saying that because of its offender. But if you ask some basic, basic questions, they are going, their marketing people will just basically cut and paste it for marketing collateral, which you can read somewhere. That's again, why you have to get down to the future stuff and get into things that are not covered on public places, right? And that's also why you might do an RFI first before the RFP because you just don't know what those feature sets you're looking for. Hmm. And that's why you would do an RFI where it's just more general. You're not avoiding anybody any contracts there. You're just gathering information, right?

So, from here, once you come, you basically take your card and you figure out for everybody what their points are on each requirement. So, each line item. And then you total it up. And then you're going to total it up by each section. For instance, in a human capital management RFP, and I know some of you are on the in the webinar today because you're looking at RFPs for other areas, but take each section of your RFP and do a total points possible, what's possible there, and a total points what they earned. All right? So, you have it for each section because you're probably going to want to refer back to that. Where did they score high? Where did they score score lower? Which categories of your are see?

Yeah. And that's also important to identify too. Okay, well, this is our strong suit. They've got, they hit every point possible in this particular category. And then you can also add weighted averages into it as well because maybe certain functionality or sections should be weighted more than others, right? And you can actually create that. Again, Excel is great for this to be able to just do these calculations for you. But you can also do weighted averages to get you a point total that way as well.

Exactly. So, from here, just thinking on the left-hand side, before you, you basically need that to read your RFP. And you read your, your product functionality and how they've done, right? I believe done an acceleration. You've got that. So, but we wanted to take it just a little bit farther from because you want it, you want to look at the whole thing. You're going to evaluate them on other things besides that functionality. You're going to evaluate them. So, now I'm looking at the right-hand box. You're going to evaluate them on price. You're going to evaluate them on maybe service, training, education. You're going to evaluate them on the demo that you asked them to see something. And you're going to end up evaluate them on their basic vendor profile. What's their install base like? Are they easy to do business with? Are they located in your geography? Whatever is important to you. So, you're going to have these different categories. And a John was the same, that's probably where you want to do your weighting. And oftentimes vendors will tell us, and I'm vendors, excuse me, hunt companies will tell us what their waiting for is going to be. They'll tell us the rubrics. Those of you that have children, so they get a rubric for every, you know, research paper they do. They'll tell you what the rubric system. So, if price is like a major, major decision, tell them. If it's service, if it's function, or whatever. You don't have to disclose them, but some do. So, then you weight each one. Now, what we did here in this example, as you can see, we took the score of the product functionality one that John just walked you through, and they had a score. This vendor had a score of 451. So, that's the points they received. Follow the blue line, the blue row here. 451 points in product functionality, and we weighted it 25% of the overall category. So, then it really is only worth one hundred and twelve point seven five points. Okay? And that's how then we can, you can do that. Now, we gave you an indication of how to figure out product functionality. We don't have time today to say, "Okay, how do you give them scores for pricing? How do you give them scores for service and demo and so on?" But you need to decide that upfront, right? What are you going to look at pricing? Is it just bottom-line price, monthly cost? Is it contract length? Whatever. So, look at that. When it comes to demo, have your demo piece of paper for all your stakeholders ready so that they know what they're listening for during the demo to check off for, and that you can get a score. But what it was key is that then you can apply the, the weights and you can come up with total scores so that you can decide who is better or not better.

Okay. All right. So, we talked about a lot of things, but this is kind of a nice summary. Should you and don't? What are the top ones that come to your mind?

Um, like I said, about the question and answer, don't do that, please don't. Like I said, it's not fun for the vendor, it's not fun for you to read through all of that. Um, when you send out your RFP, the portions that you want somebody to fill out, don't send it out in a PDF form, right? It's hard for people to export that out to Word, to Excel, to get in the right formats for you. So, it's okay to set up your instructions and your company profile and that information in a PDF. And quite frankly, that should probably be sent out in a PDF because you don't want them changing that. Um, but anytime they're filling something out, you know, have them do it out of an Excel spreadsheet. That's the easiest way. As we talked about, that score carding, the easiest way to do score cards for them as well, based off of product functionality, just makes it very easy. Um, you know, using Word, you're not going to get that type of, you know, access to be able to do formulas in there and things like that. And if you can do it, it's very tedious and cumbersome. It's just a lot easier to do it out of Excel. Um, also, um, there are other formats as well. You know, we talked about Excel, they'll be able to have them fill it out. There are tools online that you can actually use. You a tool that I've used in the past is our 365, where you can upload your entire RFP in there. So, it'll give the instructions, it'll do the waiting for you, does all of that for you, all on that, all online. And you can actually just send out that link out to the vendors to let them know that, "Hey, there's an RFP out."

Don't just use out-of-the-box templates because I, and this is a common mistake I've seen, is RFPs come in and I'm reviewing things and I see that this customer is asking them, this is just an example, they're asking, you know, "How do you handle global payroll?" And I go to their website and I see that they're nowhere near anything in terms of global in terms of payroll. Why are you asking this question? Right? And, you know, you ask them that, I'm like, "Are you, are you, do you have global payroll?" They say, "No, that was just something that was out of the temple." Michael, capable. Read through what you're using and remove what's not important because you confuse your vendor and then it will get bad responses.

Exactly. Um, you know, customize your sections that include things that are important for you. Take the time to identify what your requirements are versus your, like to halves, are nice to have things like that. Um, you know, and like I said, don't be afraid to use cloud software tools for uploading that data as well.

Okay. Well, once you do that, you've got to get the word out that you want people to respond to the RFP. How do you see it come across your guests?

So, there's different ways, right? So, one, there an email can be sent out to the different vendors. But again, you want to research who that contact is, right? With your salesperson, right? Because ultimately, they're going to be responsible for that RFP and making sure it gets completed. They may not be the ones filling out that RFP, but they're going to be in charge of ensuring that it gets back. Post it out on your webpage. Make an announcement on your webpage. You know, have it out there so that anybody can can sign up for. Don't let that be the only way that people find out, right? Talk about researching and creating a list of vendors. That's, that's, that's that's the way you've got to do it. If I, it is the best way. Yeah. Um, identify who that contact person is for each vendor, right? Who are you sending it out to? Who, who are going to be following up with? Try to make it as easy as possible to find. Maybe you can share it on social media as well. "Hey, we have an RFP out there." Follow up to, right? That's awesome. You know, also important to follow up with the vendors and say, "Hey, you know, it's a few days before. I haven't heard anything from you. Do you have any questions, right?" Um, excuse me. You know, also important is identifying, you know, "Is the vendor going to respond or not, right?" Because the sooner you can find that out, the sooner you know whether you have to find a replacement for that, right? So, you know, follow up with them and find out, "Hey, are you going to search spot?" You know, and make it fair, right? If you find, if you do have to do replacement, one, extend it out, make it fair, give that new vendor the time to properly fill out that RFP. There.

There are so many times I've seen RFPs come in that and they're due two days later, and it's hard for companies to fill those out in that type of time, right? Right. So if that does happen, be sure to be nice and extend it out and extend everybody's due date. Obviously, it's going to change your timeline a little, and again, it's okay if you're to your art, you need to make those modifications.

So one thing that happens often is people, the vendors have questions. Honey, thinks the best way to handle questions. Personally, I think it's better. So when you have your point of contact, right? So having that point of contact where all those questions come to is is important. Now you have just one person facilitating it versus multiple, right? Identify when the questions are due, the last time somebody can ask a question, right? And when you do that, you're able to gather all the questions and then you send out one email to everybody letting everybody know what the responses are to out all those questions. Fair playing field, right? That's what we're looking for with an RFP is in fair playing field. You want to have all the answers and all the questions that were asked by all the vendors. You want to know what those all of those responses as well.

Another thing you may even think about is having set time print periods where you hold an actual meeting and all of the different vendors can show up and they can ask their questions live, right there, then, right? It's another thing that can be done. Ultimately, it's up to you on how you want to handle those questions. You may start to get questions after that due date, and guess what? If you're getting a lot of questions, you can extend that question period out. But again, make sure everybody knows this, right? It's creating that equal playing field so that everybody knows that, hey, we've just extended questions out an extra five days. Please get all your questions in, and we'll be sure to get them answered and let them know how quickly you're going to answer those questions as well, right? So if it's, hey, it's Dubai, all the questions are due by 11:30, and we're going to respond to them by December 3rd, right? Let them know what what they can expect. It's just that courtesy again. Let them know that, yeah, we're taking this serious and we're going to respond to your questions at this time because all the times they can't put their solution together until those questions are in. They usually play a huge role, and vendors want to not only get their questions answered, they want to see what other people are asking, right? And sometimes those questions come in because there are being used for pricing purposes as well.

All right, yeah. Well, we're getting close to the top of our hour. I think this slide really helps wrap up a lot of the things that we talked about today. You want to just summarize some of the two things you want to make sure everybody on the phone walks away with. Yeah, so obviously important pieces actually, you know, planning out your RFP, right? And that is actually finding the right vendors, right? And setting those RFPs out to those vendors. Then it's actually scoring the vendors and how you can score them and appropriately identify in a non-biased way who is the right vendor. There was a right likely choice for vendor in here. All right, select your finalist. Plan those finalists to do demos, right? Have scheduled timeframes for those demos. Don't schedule demos back-to-back. Don't schedule demos on the same day. The reason for that is is that if you're going to a demo one right after another, you're going to melt or or merge things together that you shouldn't. You really want to have that clear-cut distinction between the two because your person that's evaluating, even though you're giving it a sheet to evaluate, they may think, oh, wait, did I see that in this or did I see that in the other one? So it becomes hard for them to to really evaluate that, right? Um, and then, you know, finally, when you select your finals, because those customer references at that point, have that vendor facilitate those calls with those references as well. Make it easy for you, right? But the onus back on the on the vendor to set that up for you. Exactly. I think talking about references, we actually have a slide on it. For those of you that want to kind of keep some of these tips, we will send out the slides to everybody on the line, but definitely, you know, get those references. It's kind of like a just-in-time when you're ready to talk to the key people, your final selections, go get those references at that time. Yeah, some that I've seen being used more and more is actual video references as well, right? Yeah, so it's not so much that you get to ask the questions, but you get to see that, you know, ahead of time, hey, this is a reference, this is what they have to say about the company. It's also good to see the person there that's giving that reference and are telling you about how they've experienced that vendor, right? Not telling you to not, you know, call a personnel to do a reference that way, but just consider doing a video reference as well as its upper option. Mm-hmm.

Now, when it comes to the vendor presentation, uh, what are some of the tips that you have there? Then those can be tiring. Yeah, so I've seen, I've seen customers that they, they have a scripted demo. They tell you, this is what I want to see, and this is what I want to see. Guess what? Your vendor knows how to demo the product. They know how to have it flow from one to the other to make it look at its best light, and that's also what you're trying and see. Yes, you want to see certain pieces of functionality, that's why you have a questionnaire for each person that's in that demo so they can mark off, yes, I saw this, or no, I didn't. But also give them a requisite of these are the things that we're looking to see in a demo, right? But don't tell them exactly how they're going to demo it to you, right? Because you still want to give them the freedom to to present to you in what in the best light possible, right? That's that's their time to shine. But also, they're going to make sure that they mark out that, yeah, I hit this point, I hit this items, I hit this point, right? And by giving them them, hey, these are, you need to specify the requirements that you're looking for as well. Let them figure out how to add us demo too, right? That's really on them to figure that out. Ask for them to record it as well so that you can go back to it, right? You may not have all the people in the room for the presentation, right? Record it. That is critical because after you hear three or four, you're going to get confused. But if you have a recording to hear it again, it could really be the make or break of, you know, did you make the right decision selection or not, right? You also want to identify how are we going to handle questions during the demo, right? And, you know, what, what suggest our timeframes for for the kind of say that loosely, you can suggest timeframes for different things to cover. What if the vendor comes back and tells you, no, actually, it's going to take me this time, much time to do this? Go with that. But you can, you can work questions for each one of those sections and just have time for and say, hey, once we get to the end of this section, it's five minutes of questions, right? Or you can say, hold all questions until the end, and then we're going to ask those questions, right? And if you leave it to lead to the end, to me, I kind of have mixed feedback with that. If you know you have somebody who, I don't, the word is, but they're they're kind of taking it, take over the the meeting, and they're just asking question after question, question. If you know you'd have somebody like that, then, you know, maybe waiting until the end is the best choice for a because you don't want to derail the demo based off of that one person asking a million questions, and there are people that will do that, and then your other stakeholders don't get to see, get enough time in their section, right? I don't know what the best way of saying. Yeah, and we talked about, yes, so no, you know, your audience and know your selection committee and how you think they're going to act and what their behavior is going to be during the demos, yeah. And then I'll help you decide how you're really going to to handle questions. Just let the vendor know, you know, how the questions are going to be handled, and the vendor may tell you like, hey, you know what, I prefer to have all questions at the end of the demo, just yeah, because they might be on a roll on, or they may have be presenting a story to you, and you don't get to see the whole picture until the end. So give some flexibility there to give them so that they can give you the best presentation they can. Then don't forget a scorecard for that presentation. So you have a scorecard, you know, for that RFP and for those features, but you probably need something different for the demonstration. So everybody's listening for certain things. Yeah, yeah.

All right, common things to avoid. One last time, what do you want to leave for tips? You know, keep in constant contact with with the different vendors. Also, if you do contact them, I think it's best to do a BCC to copy everybody so that you're not giving away everybody's email address, just copying everybody. I see, I've seen responses back to questions where they just show you everybody that was on there, and yeah, that's not a good idea. Don't, don't let them together all the vendors. There kinda want to respect privacy there. Um, you know, expect to get questions from the vendors that we, and they're asking the questions because something isn't clear, right? And if something isn't cleared, they're wanting that that additional information. Answer those questions. Again, you can decide how you want to answer the questions, but you make sure you answer the questions to all the vendors, not just the one that asked a question, just to be fair to everybody. Do expect meas for sharing financials from a privately held company. Expect that from them. Don't expect them to just put out there what their financials are. Don't require the RFP to be delivered via a hard copy or CD-ROM. I think, I mean, I'm one of the very few that those have a CD-ROM on my computer. Most people have laptops now, and CD-ROMs are not part of laptops anymore. They're typically an extra peripheral. Don't expect it to super brown. Um, you know, talk about being able to do it online, or if they are going to send it in, they can email it in, they can send you a USB stick. Most employers he drives up or just ports available to them. You know, make it an easy as possible. You can even just decide on a Dropbox folder that you want to drop them off to the individual vendors that they go in to drop it off there. But just, you know, a hard copy and a CD-ROM, one, you're wasting paper with the hard copies, two, a CD-ROM, you're, it's hard to find a, let's call it a CD brighter, brighter anymore. Yeah, so go electronic. Yeah, we're in the year 2018. Yeah, try to be as fair as possible. Be objective. You know, be fair to all the vendors. That's why there's our VPS because you're trying to have a non-bias with you towards every vendor, trying to give everybody a fair shot at that to be your customer, right? You're trying to give them that fair shot and attach any additional documentation that that need to be shared. A summary of required documents for the vendor, no, give them all the information that they also on due dates. Don't specify behind, you know, what people work now, you know, I won't say 24/7, but they work late. They work later than 3:00 p.m. All right. I've seen people say that they need a hard copy delivered by 2:00 p.m. on this date. Why? You know, just say end of day, right? Just you're being used. Yeah, yeah.

The other thing you can think of too is you can say that you will have a dark period after the RFP is submitted, and that you will not be talking to vendors or answering any more questions. You'll, you know, anything you'll put out, you put out to everybody. We are now evaluating. We will have our in selection at this time. That's okay to do that. You know, instead of you, you don't want salespeople calling you. Yeah. And one more thing to add as well is communicate to everybody, you know, not just a finalist, an orange prison. When you make your final selection, communicate to the finalists, obviously, but also communicate to the ones that have it made it. It's just common courtesy to let them know that, hey, you know, you didn't get make the final final list, right? And you can leave it at that and just and move on. If you want to give an explanation, explanation, but just at least give them the the notification that, hey, you didn't write, right? Exactly.

Well, we are out of time, and I don't see any questions. So thank you, John, very much. You know, I think I hopefully everybody on the line get some good information from today. So thank you for joining me. Yeah, thanks for shaman. Thank you everybody that joins us today. So this is kind of a fun topic for us because it's not one of our norms, but we thought it would be an interesting one to do just because we see so many different RFPs and the issue RFPs ourselves here that we thought it was it would be a great topic to cover because we see so many times that things come in, you're just kind of scratching your head, how is this person going to evaluate all these vendors based off this RFP? All right, so so thank you again. Yes, so at the end of today, you're going to get a short survey. It's just a couple questions on let us know if you'd like to know more about us. IPE systems. Again, we are an HR technology provider. We provide workforce management and payroll HR solutions, and we would love to help you. So we actually do have other jobs and John does demonstrations all the time, so he would love to be able to take you through our system and our our full suite of solutions to help folks. Also, afterwards, you will be able to get a copy of the slides. We'll be sending that out, and we'll also be sending you information about an RFP, I guess it's an e-book that will help you understand how to put an RFP together. So that's a nice follow-up that's coming along, and everybody will get that. So hopefully you'll enjoy that. Again, on the screen here, you can see our full list of solutions and modules that we have, everything from applicant tracking to HR benefits, time and labor, payroll, and performance management. Again, at IPE systems, we would love to be your partner in providing you your HR technology. Hopefully, we can talk to you again. Thanks for your time today. Have a great rest of your day. Goodbye.