Sign up for The Full Desk Experience updates!
Show notes
In this bonus episode, we have a special guest, Tim Keckler, joining our host, Kortney Harmon. Tim is a seasoned software implementation expert and decision-maker who has worked with numerous organizations to successfully adopt new software. Today, Tim shares valuable insights on the challenges of balancing the ongoing work of producers, recruiters, and salespeople while introducing new software. He explores the importance of assembling a diverse buying committee and valuing the opinions and feedback of end users. Tim also dives into the common pitfalls in software rollouts and offers practical advice on evaluating and selecting the right software for your organization. Don’t miss this episode packed with actionable tips and strategies to maximize software adoption and implementation.
Transcription
Tim Keckler [00:00:00]:
Crafting an RFI, there’s going to be a lot of eye rolls. Right now, crafting an RFI is no fun project whatsoever, right? And a lot of people think that giving an RFI to a salesperson is actually a challenge for the salesperson. It’s not. I’ve appreciated every single RFI that I’ve ever gotten because what it allows me to do is come to a demo prepared with something that I can actually show you that might be of value to you right out of the gate.
Kortney Harmon [00:00:27]:
Hi, I’m Kortney Harmon, staffing and recruiting industry principal at Crelate. Over the past decade, I’ve trained thousands of frontline recruiters and I’ve worked with hundreds of business owners and executives to help their firms and agencies grow. This is the full Desk Experience, where we will be talking about growth blockers across your people, processes and technologies. I’m your host, Kortney Harmon, and today we have a very special guest with us. Tim Keckler is a highly experienced sales engineer and Tim has worked with thousands of offices and truly has extensive knowledge of the challenges faced by organizations when it comes to switching software solutions. He’s here to share his insights on how to navigate this complex process successfully. So, Tim, thank you so much for joining us today.
Tim Keckler [00:01:23]:
Oh, Kortney, thanks so much for having me. I’m glad to be here.
Kortney Harmon [00:01:26]:
I love it and I love your insights before we dive into this and delve into this amazing topic, because let’s face it, offices that are looking to make the switch don’t do that every day. So just like people interviewing, they don’t do it every day. That’s why recruiters hold that special place in that consultation of helping people in our industry. So with that being said, talk to me about why this topic is so important for you and what you’ve witnessed firsthand with maybe major factors that can make or break that software switch.
Tim Keckler [00:01:56]:
So I have absolutely talked to many, many organizations making big, big moves when it comes to software switches. There’s some commonality behind all of them. When someone’s coming to market, what is some of the anxiety there that we’re going to be facing? What are some of the challenges? And hiccups? There’s really three major ones that I think about and that I hear more often than any others. The first one, hands down, is adoption. If my team doesn’t adopt this, if they don’t like it, what’s going to happen? And if that’s where your headspace is, you’re dead on. That’s exactly where you should be. That’s exactly what you should be thinking. That is the most common pitfall I see with any software rollout anywhere is poor adoption. I think the second one, hot on its heels is going to be implementation, which leads to poor adoption. Right? If we are poorly implemented, people aren’t going to pick it up, people aren’t going to use it. Therefore, we have a failed launch of a new software platform. And I think a third kind of an unsung hero in the list of three major pitfalls or three major reasons why software rollouts fail, I think is getting sold on features. Right. We come into a demo, we see some cool stuff, we get sold on that cool stuff and we make a decision based on the cool stuff. Come to find out, the cool stuff may not have done what we wanted it to do or may not be even useful to some of our team members. We fail our software rollout. We have a software that, again, leads back to adoption.
Kortney Harmon [00:03:28]:
Those are great insights. I love that. Do you have any personal examples that you’ve kind of worked through, whether it’s yourself or working with an office, about maybe coming to market and making such a selection?
Tim Keckler [00:03:39]:
Yeah. So I’ve been on both sides of this fence. I have been the consultant that’s helping an organization roll out and implement new software. I’ve been the person to decide the new software and roll it out. So I understand the challenges from both sides of the fence. I’ll give you a quick example with the organization that I work at currently. A couple of years ago, the word came down, hey, the time has come, right? It’s time to switch to a new CRM. No easy task. If I had known then what I know now, and I learn more about this every day, I would have done that quite a bit differently. Part of the reason why I’m here is helping other people to figure out how not to make the same mistakes that I made here. But we go through the entire transition. I led the charge on a lot of the implementation over there, and there are still users today in small corners and whispers that say the old system didn’t do that right. So mostly in fun nowadays, but at the same time, they’re absolutely right. We’re going to talk about this more in a second, but the end user, I think, is a key target in who to get feedback from when we’re coming to market. So, yeah, I’ve been on both sides of that fence. I’ve led the charge on software rollouts for my own organizations that I’ve been a part of and I’ve helped a lot of people roll it out in theirs.
Kortney Harmon [00:04:51]:
I think that’s amazing. So you’re taking this twofold, you’ve been there, you’ve done that, but you see it more and more every day, which I think gives you a very unique perspective. So let’s say someone is coming to the decision they actually need to make this move. They need to start evaluating or demoing or they need to make that move. How does someone even go about starting something like this? Like you said, lessons learned. What is your advice to say this is how you start that process?
Tim Keckler [00:05:22]:
The biggest things that I see is jumping into a new software search. Just headfirst right. This really is managed in phases, right? We have to plan to come to market. We have to come to market and then we have to make a software selection. So we’re really talking about a workflow, if you will, of three phases to software rollout. So I think there’s a couple of key factors in each one of those phases that we should consider when we’re doing it.
Kortney Harmon [00:05:50]:
All right, so let’s start with the first step. What would the first step in at least getting that ball rolling be for someone that’s getting ready? Like, okay, I need to go now for something to happen in December. What is step one?
Tim Keckler [00:06:02]:
I think step one is always going to be establishing a buying committee, right? Establish the voices in the room that need to be heard and represented when we’re thinking about changing, making a major change in systems, right? Who is this going to affect? How is this going to affect their day to day? How can we get their input when we’re making this choice?
Kortney Harmon [00:06:22]:
I love that. I love that perspective, and I have seen that across so many offices. That’s a major downfall that people don’t do. But let’s talk a little bit more about that. Why is the collaboration and diverse perspectives important when forming that buying team for this technology acquisition?
Tim Keckler [00:06:38]:
Switching systems is the major change for the organization. It’s going to upset the Apple card, if you will. We have to really think through whose lives we’re affecting when we change the software. It’s not always just the end user or the recruiter or salesperson that’s logging into a system like this, right? How is accounting affected? How is the person working in the back office admin? How’s their life affected by this sort of switch? So we need to be cognizant of what people and processes that we’re going to impact when we make a switch as we’re in that phase of deciding to come to market. So we develop this buying committee and then it’s important for us to have representation on that buying committee from all the people who we’re really going to affect in this process.
Kortney Harmon [00:07:24]:
All right, now let’s discuss the different roles and responsibilities maybe within the buying committee and the different people that it touches. I know you went into a little bit of detail, but let’s dive in.
Tim Keckler [00:07:33]:
We always need to balance this against current production. So the producers, the recruiters, the salespeople, they still need to do their day to day. They need to be able to weigh in on a decision for a new software, but at the same time, the work doesn’t stop just so that you can shop for a new software. So when you’re developing a buying committee, it’s important to have the major groups represented and on the demos and interacting with the salespeople and asking questions that are important to how it affects their lives going forward. It does start with the people who are in the software most frequently. Right. I’ve been a part of buying processes out there where it’s coming from the top down and decisions are being made for all the different groups. And that is one way of doing it, but it’s typically not the most successful way. Right. I want the end user on there. I want the recruiter, the salesperson, the back office admin, a representative from the accounting department who’s managing our payroll, who pays commissions, all of that. Right. The idea is that a software change of this magnitude is going to upset the Apple card back to that. So the people who this are going to change are the people whose opinion I’m going to value most. Every leader and CTO out there is going to want great reports. Right. That’s kind of the thing that’s driving us behind the scenes, but it’s oftentimes not the thing that’s going to get us to make the move. Right. We’re going to listen to the user’s feedback. We’re going to listen to all the problems that they’re having in the system today and how they wish the system did something different or functioned differently. In the back of our mind, we’re like, yeah. I’d also like some more insight into the business. The leaders definitely have to be represented, right. But when you’re developing this buying committee, we want to take people from pretty much all of the departments. Take your technical people, take your nontechnical people, pull them into this committee. The software rollout is only going to go well if the interests of all the people using that software are represented on the committee.
Kortney Harmon [00:09:27]:
I love it. It’s almost like you have to think about it. What’s in it for them? When you get that adoption from your teams, you have to understand of what their buy in is. So they’re thinking it through at their lens. Leadership is thinking through it from their holistic view of the business. Accounting is looking at their pain points. Everybody has a different lens of focus for this.
Tim Keckler [00:09:46]:
Yeah.
Kortney Harmon [00:09:47]:
All right, we’ve established a buying committee. Let’s assume we have step one down. What’s next? Where do we go from here?
Tim Keckler [00:09:54]:
So we’re not ready to dive into demos yet. We have a buying committee. We think we have a good group of people. We’re talking about how excited we are to shop for new software, and we’re thinking about that process and maybe even identifying some vendors. There’s still steps to take before we’re ready to jump out there and jump into demos. And I think one of the most important steps that we can take there is thinking about the current process today. Sit down. And my recommendation here is to document it. Get this in writing, whether it’s in the committee or the company. Right. And a lot of you guys have this today. A lot of organizations just starting out or organizations that have been maturing for years have process documentation. Dust that off. If you haven’t looked at it in a while or sit down and write a new one. We want to sit down and we want to start with our unique value proposition to our clients. What are we doing? What’s the kind of the magic sauce there that we’re providing to the clients? How’s that work for us? What are some of the unique things we do in there? What’s the candidate journey like with our organization? What’s the sales process look like with our organization? What does the employee management piece of this look like? So no matter what type of recruiting or talent scouting that you’re doing, you have an idea of what those processes are in your mind. Whether you’re just starting out, you get to mold something new or you guys have been doing this as a team, and it’s well established, and it’s just worth sitting down and saying, look, let’s document our process before we go out there. And I think the benefit that that provides is now we have a document that’s in writing, we’re agreeing upon it. That way, when we get into the demo process, we can reflect on that document. Every time we get into or out of one of those demos, we’re coming back to that document and we’re seeing how what we just saw aligns with the document for the workflow. The workflow today doesn’t have to be perfect. I’ve seen organizations make two versions the workflow how it is today, let’s get real. And then the workflow for how we want it going forward, and maybe software can help us with that. That’s absolutely fine, but we need some sort of document for accountability purposes. So I think the first step there, to answer your question most directly, is establishing a documented workflow of processes before we start jumping into demos.
Kortney Harmon [00:12:11]:
You speak near and dear to my heart. We talk about foundational processes all the time here, and it’s really aligning the methodologies the way you want your business to be ran with the technologies. And oftentimes you actually hit probably the nail on the head. A lot of times leaders do this. In the beginning, it’s like, hey, this is the way of doing things. But oftentimes we don’t revisit them. Right now, we’re going through a market shift. We maybe have to sell more than we’ve had to in the past. Maybe there’s a new emphasis on skill marketing, whatever that might be. There’s oftentimes that we have to revisit these, make sure that the cobwebs are dusted off and we’re actually engaged and have that set. So I love that. Great advice. How do we ensure that technology requirements really align with our overall business goals and operations of our company? How do we make sure those two connect and collide?
Tim Keckler [00:13:00]:
I think that also is taking it right back to that document. Right. Let me give you an example of what could happen. I’ve been in lots and lots of demo and sessions with organizations where there’s disagreements on process, fundamental process, and it can send the entire demo process into a tailspin. Right. If one person thinks this is the way it is and we’re supposed to be, and another person thinks that something completely different technology is not going to be able to help you in that situation, you have to have sat down and hammered all that out before you’re looking into the demo process. Some of the most challenging buying cycles that I’ve ever been a part of are buying cycles where we’re consulting on the processes of the business and the technology at the same time. I think that’s why that document is so important for you to at least have a solid understanding and idea. That way you’re not demoing products for two different reasons. Right. We’re all on the same page about what the problems we’re trying to solve are.
Kortney Harmon [00:14:01]:
Yeah, I think it’s like the roadmap. You have to have the map and you can’t just fight over which back road to take. You actually have the map to know.
Tim Keckler [00:14:07]:
Where you’re going or which stops to make or which attractions we want to see. Oh yeah, been there.
Kortney Harmon [00:14:12]:
Lots of disagreements and road trips. All right, so you talked about the process. Let’s talk about current tech stack because obviously that’s important. Let’s talk about why it’s important to take inventory of maybe existing technologies and software tools before purchasing new ones.
Tim Keckler [00:14:30]:
So a lot of organizations have software that they may not even remember that they have. Right. And I’ve been a part of many, many again going back to buying cycles with clients of mine. And they have a lot of different softwares with maybe overlapping functionality or maybe, and I see this more often than not, maybe we have softwares that are solving major business functions for us that aren’t speaking to one another or are very far apart. I’ll give you some quick examples. Like in the recruiting, in the, you know, in our world, candidates, clients, we are building relationships with people. That’s what we do in recruiting. If my ATS is over here for managing talent and my CRM is over here for managing clients, and I’m picking up the phone with a hiring manager and I’m logging into two systems to see that sort of thing, I have a very disjointed process. Even if there’s some sort of integration that says, hey, I can get a little insight into one versus the other. You’re talking to people all day long. Managing processes, two processes like that that are so major and so intricate to the business in two separate softwares is just completely unmanageable. Right. We almost need full insight from one and the other. I’m on the phone with a hiring manager and then I’m on the phone with a candidate. I’m negotiating an offer for one candidate and I’m scheduling an interview for another one. I have a placement that I made at a company a couple of years ago and that person’s asking me about new opportunities. So now they’re back on the candidate side, right? So I’m constantly needing a software that is in touch with all of the other things that I’m using and there are so many systems and flashy items out there today or products that a lot of times we kind of get away from the tracking aspect of that. Now we have having a platform to run your business from is not a bad thing. Having multiple systems in a tech stack is a great thing, right? There are softwares out there that specialize in certain things. There’s no end all, be all. I like to say that some softwares are sort of like cutting a steak with a Swiss Army knife, right? If you claim to be able to do everything, you’re probably not doing everything right. So what other systems out there are we talking to that manage this process for all of their clients all day long? Best in breed, if you will. So evaluating that tech stack is kind of the second essential point to this, right? We’ve talked about our process, now let’s talk about the tech stack. Let’s again document it. What is everything we pay for today in software? Who manages that software on the team and what is that software doing for us? Because a lot of times you can take a look at a tech stack like that and look at consolidation. And software has probably come a long way since the last time we got in a buying cycle or the last time we evaluated software out there. So let’s see what we can consolidate, but let’s make sure that it’s doing the things that we needed to do. When we’re talking about consolidating, I’m exhausted.
Kortney Harmon [00:17:29]:
For those recruiters and salespeople that are doing dual entry. Just you talking about it made me tired.
Tim Keckler [00:17:35]:
I see it all the time.
Kortney Harmon [00:17:37]:
Well, okay, so we talked about the people running the desk the day to day. Let’s talk about the challenges that staffing and recruiting, operation directors, maybe the leaders of those organizations, what do they face in this process?
Tim Keckler [00:17:49]:
So again, having come from that side of the fence doing implementations as a sales leader and rolling out new software for teams myself, I think we oftentimes suffer in silence. We want insights, we want to know how we’re doing as a business. We want to be able to predict where we’re going as a business. Right? So we need softwares that give us those insights. We need a brilliant platform that can tell me about how good we are at finding a certain role at any given time. Right? So I think that a lot of times that falls by the wayside when we’re listening to our teams, the complaints they may have about a software platform that they’re currently on, sometimes overwhelm the directors and leaders of this process and sometimes our needs fall by the wayside. I assure you there are softwares out there that will solve the needs that they have and give you great reports at the same time. Just a matter of preparing and coming to market. So I think to answer your question, again, most directly, suffering in silence, I see a lot of times amongst the leadership and the directors that are coming.
Kortney Harmon [00:18:54]:
To market that makes complete sense. They thought of Last or maybe whenever they look at the reporting, they think they have all the things that they need, but they don’t realize that systems should talk or they’re integrated to have a better view. That’s something that I talk about all the time. In missing reports, you’re measuring your teams on a do more mentality, but is that the right way to measure? Do you even know how your metrics come about? So I love that. All right, so we’ve established one, we need a buying committee. We’ve established two, we need to evaluate our process and understand that foundational. Process number three, we understand we have to check out our tech stack and what we currently have. Now that we’ve got all those in play, that’s going to be a timely process. That’s not going to be an overnight fix, right? What about correct me if I’m wrong, I’m guessing we come to the demo part and coming to market. And what I see from a lot of offices whenever they’re currently evaluating these things, how do you not get sold on the shiny object syndrome? We all are there. We all think there’s like a big fix, let’s move towards it. How do you make sure that doesn’t happen? And am I right in my next assumption that that’s the next thing now it’s demo time.
Tim Keckler [00:20:02]:
Now it’s kind of the fun part, right? Yes, it’s exhausting. You’re going to be seeing a lot of people, you’re going to be shaking a lot of hands and getting a lot of smiles, but it’s time to actually look at some solutions. So kind of backtracking. Yes, we’ve sat down and we’ve established people that we want to weigh in on this process, a buying committee. We have sat down and we know who we are, current state, and we’ve gotten real with ourselves and this is currently what we’re looking at. May have an idea of where we want to go. Now it’s time to start doing some demos. Before we start scheduling those demos, though, one of the steps that I see taken for the most successful from the organizations that I find the most successful rollouts on is crafting an RFI. There’s going to be a lot of eye rolls right now, crafting an RFI is no fun project whatsoever, right. And a lot of people think that giving an RFI to a salesperson is actually a challenge for the salesperson. It’s not. I’ve appreciated every single RFI that I’ve ever gotten because what it allows me to do is come to a demo prepared with something that I can actually show you that might be of value to you right out of the gate. So I think an RFI is a very valuable tool to have when you’re coming to market and you’re about to do demos. I think that RFI should include the things that we’ve already gone over. A brief snapshot of the workflow, a brief snapshot of the tech stack that salesperson, any salesperson, consultative account executive or sales engineer worth their salt is going to be able to take a document like that and show you something that speaks directly to your pain and the value that you’re looking for. Future state of your business and your tech stack. We want to have lists of what are our absolute must haves. There’s no software out there that’s 100% bad, including the one you’re on, right? If you moved that tomorrow without any sort of buying committee or any sort of notice to your team, somebody’s going to say, hey, I was using something in there and I needed to do my job. So there’s some value in every tool that you’re using today. We need to sit down and we need to think about what we can afford to lose. So kind of make three columns out of an RFI, I’m going to do this inside of the template. But what are our absolute must haves? What does our system do for us today that we absolutely can’t afford to lose? Maybe it’s an sic code that we track or an industry, or we organize our records or our candidates and clients and referral partners a certain way that somebody on our team is easily able to find stuff and do their job more efficiently because of. So we need to figure out what those things are. We need to make a list of the things that we absolutely must have in a software going forward. Then in the middle column, we’re going to make kind of our wants. This is the most fun column, right? This is like the wish list. Hey, I’d be great if I had a system that could do XYZ and then I get the things that we’re looking for in a new solution. So we have the column we can’t live without. We have the middle column here and that’s the stuff that we want. That’s the new shiny objects. That’s all the new functionality, all the things that are going to increase efficiency and reporting and things across the organization. And then the third column is the can live without. And this is hey, it’d be great if we had a system that did this. But if we can’t find a system that can do that with all the other stuff or if the thing that we can live without conflicts with some of the core things that we decided to even come to market for. Then we’ll throw in the Can Live Without column and see if we can find a software that does that. Or maybe an integration of the platform that we’re thinking about choosing that might cover that for us.
Kortney Harmon [00:23:33]:
I love this. This is like full circle from running a desk. This is exactly how you take a job order. You have to ask your clients, what do you need out of this candidate? What would you like to have and what must they have? It’s a non negotiable. So, like, this is like full circle in the talent industry. It just warms my heart. I’m a nerd. I know, Tim. I’m a nerd. I only think in terms of teaching in this industry.
Tim Keckler [00:23:55]:
We’re all nerds.
Kortney Harmon [00:23:56]:
Yes, absolutely. I love every minute of it.
Tim Keckler [00:23:59]:
So I think crafting an RFI as long as we can get on board with that process is a great step to take just before getting into the demo process.
Kortney Harmon [00:24:09]:
I love it. So it’s like the idea that you understand what you need, you understand what you can and can’t do without, and it’s like your guardrails in your process, right? It is.
Tim Keckler [00:24:21]:
It’s a document that we can refer back to if and when this project starts going off the rails. Right. We’re going to jump into a demo and we’re going to see something neat. And a lot of times we have a tendency to just drop everything and go towards that neat thing that we saw, thinking it’s going to solve all the problems. I think an RFI document is something that we can refer back to when we get to that point in the process and say, okay, yeah, that was really cool. That was a cool thing that we saw. Let’s put that in a column there. But is the software also solving all these major things, all these reasons why we even decided to look for software in the first place? So it gives us, again, back to that concept of accountability in this buying process. It gives us a document that we can then refer back to and say, all right, how did that demo and what we saw there align with what we’re looking to accomplish here?
Kortney Harmon [00:25:12]:
And for those most everyone knows this, but an RFI is a request for information. I know that seems like a basic thing, but it’s oftentimes overlooked in all the other acronyms and TLAs right. Three letter acronyms that we have in our business. So I just wanted to make sure that was spelled out.
Tim Keckler [00:25:30]:
It is. And there’s an RFI request for information. It’s informal. It’s not a document that you’re legally held to or contractually obligated to buy a software based off of. Right. It’s a request for information. Tell me a little bit about your product before I dive into a demo with you, is really what we’re saying with an RFI.
Kortney Harmon [00:25:48]:
I love that. So thinking about it’s going to be work number one, but how can providing information about your current process, about your tech stack help vendors or people that. Are giving these demos or these demonstrations, how can it guide that process?
Tim Keckler [00:26:04]:
Kind of like what I was saying before. With any consultative salesperson out there is going to be able to take a document like that and show you the things that might help your business. Specifically, a lot of times discovery is done sometime during a demo process. A lot of times when a business is coming to market today, right, they come into a demo and they tell you a little bit about their business and they tell you a little bit about their current situation. And a sales rep is really sitting and listening to that and absorbing that and trying to help, right? We want to help. That’s what we’re there for. So we’re trying to plug in, okay, we have solutions for that over here. And I definitely hear you talking about you need this, this, and this, and we have solutions for that over here. If I was able to prepare all of that in advance. Based on the fact that I just answered an RFI for you and you gave me some insight into your current workflow, I can come prepared with a number of different things, a number of different questions to ask you based off of what I read in the RFI. And that kind of creates this relationship, this consultative relationship between the buyers and the salesperson, where now I have some insight into your business more than I would have had otherwise. I know a little bit about what we’re doing, and I can really go in, especially on the sales engineering side, I can really dive in and I can say, like, here’s what I’m thinking might help, right. Versus having to do something like that on the fly or trying to show you something that might be appealing to you or worst of all, giving every demo that you do the same cookie cutter, sort of scripted demo that never works for anybody, right. Our professional services team at the organization I work for loves to say you’re not an out of the box organization. We’re not an out of the box tool. How can we sit down and consult with you and really show you something? An RFI done in preparation for that demo is going to have that account executive or sales engineer account executive and sales engineer, in some cases, sitting down and really crafting something that speaks to what you’re looking to accomplish.
Kortney Harmon [00:28:09]:
You’ll see the bells and whistles you want to see versus that someone else needs to see. So I love that.
Tim Keckler [00:28:15]:
Yeah.
Kortney Harmon [00:28:15]:
And I may be letting the cat out of the bag a little bit, but if you’re going about an RFI and you need an RFI, where would you go about finding one?
Tim Keckler [00:28:23]:
Tim so, Courtney, when you asked me to talk a little bit about this, I think one of the things that doing so much thinking about, like, well, if I change systems today, what would I do? I would definitely craft an RFI and it would be great if there was some sort of template that I could use out there. So as I was preparing for this and as I was thinking about helping organizations come to market and buy software, I was thinking about all the things that I would ask in an RFI. So in that kind of started to craft this RFI template that I know I’m going to use when I buy software next, but I wanted to share it with everybody. So I’m going to come out with a templated RFI that you may even choose to make downloadable from this episode and everybody can have that.
Kortney Harmon [00:29:07]:
I love that. I selfishly had to plug that because I love giving stuff to people for them to be able to use on their own. And it’s really just to guide you through the process. We’re here to help and just to be able to help you make better sound decisions, right?
Tim Keckler [00:29:21]:
Yeah, absolutely. And that is it. It’s not the type of thing that is very complicated. It’s basically what we went over here.
Kortney Harmon [00:29:29]:
Anything else we missed in this process before I go on because I think there’s a part that we’re missing in this conversation and it’s maybe really the idea of how to staffing and recruiting operations directors or people focus. On maybe red flags or things that they hear in a demo or an evaluation process that stop to say, I just don’t have the best feeling about that, or that doesn’t make sense, or unforeseen features that you may have come across during a demo.
Tim Keckler [00:29:59]:
That’s a really great question. And there’s a style of demonstration that I very much prefer whether I’m coming to market and shopping for software of myself or the style that I use when I’m talking to clients of mine. Seeing is believing, right? Don’t be afraid to ask questions. Don’t be afraid to ask can I see that again? Hey, slow that down. Rewind show me that again. Because as we’re checking those boxes through that RFI, or even in our mind of the things that we want to make sure this software is going to do, oftentimes we’re seeing a software for the first time, right? So we’re not in this every day. It’s going to take us a little while to kind of get the gist of what’s happening on the screen at a base level, right? So when we’re asking for certain use cases or certain examples to be demonstrated, make sure that we’re doing that in a way that we can comprehend, right? Not just, oh yeah, we do that. Moving on to the next question. Okay, you do that. That’s a core business process for us. Can you show me a little bit about how your software helps us with that? Show me how this particular feature works. So definitely seeing it, not being afraid to ask a question more than once right to see it demonstrated different ways. Until you have a solid understanding of that’s how I would log in, that’s how I would do that. Yes, I can manage that. That seems like something that I can do. The other thing is if you can get hands on with it and I know, again, going back to one of my favorite things to say, the work doesn’t stop just so that you can shop for a new platform to run your business from. But if you have users, potential users of a new system and you’re narrowing your short list of systems, sometimes it helps to actually be able to sit down and say, hey, do you guys have a trial or something like that where I can sit down and kind of play with it, see how that might work for us?
Kortney Harmon [00:31:52]:
I think that solves two problems in reality. It helps them answer their own questions, get comfortability of the product, but it also helps gain the adoption further down. When you gain excitement or you create that excitement as people are looking at a system and saying, oh my gosh, it does this that our system doesn’t do, you create that excitement, but you also create that adoption. Because let’s face it, whether you’re in a virtual environment or a physical environment, people are going to have water cooler talk. They’re going to say, hey, I saw this cool thing. I want you to know this. This will help you move faster because it’s about speed in our industry. There are so many things that I think that’s going to help long term with adoption. And seeing and feeling early on is definitely a game changer.
Tim Keckler [00:32:32]:
Definitely.
Kortney Harmon [00:32:32]:
I love it. We covered a lot here today. We’re already like 36 minutes in. Is there anything else that we didn’t cover that maybe our listeners should keep top of mind when they’re going through this process? Lessons learned. Anything else that you would want them to know?
Tim Keckler [00:32:50]:
I told you about all the lessons I’ve learned. We’d be here for two days and 36 minutes on this episode. But I do want to touch on very quickly, just a process that I don’t often see used, mainly because organizations don’t realize that it’s an option for them. A lot of mature organizations that are coming to market for new software are familiar with engaging consulting before they come to market on that. Lots of good softwares out there. Lots of the best softwares out there. Have a professional services have a professional services team inside of their organization. This team, if you wanted to take this process to the next level, you should be able to engage this professional services team and get a proof of concept built. If the anxiety for adoption and implementation and getting sold on shiny objects is keeping you up at night, even through the end of this process, one of the things that you might ask is like, hey, what would it take for us to get a proof of concept built out? What would it take to migrate a portion of our current database for us to build in? Maybe I need to see this integration before we pull the trigger and invest heavily into it. What does that look like? Now, this isn’t a free service. Organizations will charge for this as a part of professional services, but it is kind of the next level of that. It is saying, okay, great. We’ve seen a lot of things. We’re comfortable in the demo. We think this is a viable solution. I just need to make double sure, right, that I’m not making a mistake. And, I mean, it’s not going to be 100% even if you build a proof of concept, who knows what could happen in the future? But at least it gets you all right. Not only have I gotten hands on with it, but I’ve gotten hands on in a manner that it might be what my first Monday in the system looks like, right, where it’s my data, it’s my processes, the integration to whatever other system I have or whatever system I want to integrate that is hooked up in there. And I’m seeing how the two we’re not paying full fledged implementation, we’re not migrating all of our users over, but we’re getting kind of a taste of what that would look like in a very targeted environment that would really give us an idea of how this is going to function in the future. And the most mature sales organizations and software development companies out there are going to have a team that can help provide that for you.
Kortney Harmon [00:35:10]:
I’m going to ask a part two of that question. You said, well, if you need to make double sure, what if you don’t know? Honestly, there’s times that you go into this process and you’re like, I don’t know. What I don’t know? Is there any value in tapping in that professional services team? What are other values that they could think of that I wouldn’t think of? But what is that next step? I feel like there are certain organizations, maybe they’ve walked a mile in your shoes. They see so many just like you as a sales engineer. You see so many demos, you see so many systems. But what is the value of professional services?
Tim Keckler [00:35:43]:
So professional services you should be talking to. One of the second most reason why I see failed software launches is due to poor implementation. So right alongside of all the things that we’ve been talking about as a part of every demo that we’re doing, as a part of every conversation that gets us to the next conversation where we want to learn more, we should also be talking about transforming our current process into that, right? Because remember, we can get the best thing going forward, and if we don’t take our old process and properly move it over into what we’re doing going forward, then it’s going to end up falling flat on its face. So get familiar with professional services early, at least introductions into, all right, well, what would implementing this on my team look like? What’s the time commitment for my team? How long is this going to take? How much effort is involved? Of course, the cost we want to discuss. Right? So there are a number of benefits to getting professional services in early, whether it’s on that proof of concept side or not. If you’re getting them to do a full proof of concept, maybe engaging with them earlier and helping them craft that, or getting them to help you craft that RFI. And take a look at your current tech stack with you. And take a look at your current processes with you. It’s becoming common amongst some of the best softwares in the recruitment space to be going into the industry for people who are implementing software on their behalf. So chances are, if you’re with a good one, you’re going to be talking to somebody who’s sat in the seat before, who’s ran a desk before, who you might benefit from their insight all the way up in the RFI crafting process, or all the way up into evaluating our workflows and our tech stack. A good consultant can help you with that. A good software has that consultant team on tap.
Kortney Harmon [00:37:32]:
I think you’re key when you talked about adoption and implementation. People oftentimes think that that’s an ongoing thing. So when implementation is an ongoing thing, not only is it crucial in the beginning of engaging professional services, but it’s also training your new team members as they come in, training a new update of a software that came out with a certain rollout that came. So there’s consistent training in the implementation to make sure it’s all successful.
Tim Keckler [00:38:00]:
There is, and it’s another benefit to engaging the professional services team or making sure that the professional services conversations are happening in parallel to the demo process and the software decision process. I’ve heard no shortage of horror stories about botched data migrations and untrained teams that launch on a new software platform. Right. On Friday, I left the office and I was able to find candidates this certain way, and we launched in this new platform, and I have no idea how to do that in the new system going forward. So getting professional services engaged early and often in those conversations to ask questions about, okay, well, this field is essential to this team over here because they use it in business development or in candidate marketing or in MPC or all the different things that we do inside of the database. It’s essential for us to build lists or find people. How is that going to be mapped or transformed into a new way of doing things in Crelate going forward? We’re there with the buying committee, so we’re going to sit down and we’re going to make sure that works and that aligns with what we’re looking to do moving forward and then that’ll help us in making our decision ultimately.
Kortney Harmon [00:39:09]:
I think that’s great. I love this. This is such great information and so much for people to think about from before they pull the trigger on doing the fun part of the demos, because let’s face it, that’s usually where people go to first. What are the building blocks you have to do before you start that process? What are your foundational processes? What’s your tech? Stack the RFI, even all the way through for that professional services team. I thought this was so insightful. Tim, thank you very much for your insight.
Tim Keckler [00:39:36]:
Oh, it’s so great to be here.
Kortney Harmon [00:39:37]:
I love it. And I think our audience will definitely take pieces of this and use in their own process. And don’t forget that downloadable asset that will be in the show notes going forward and we’ll share with our team, from our team as well. I think it would be a huge gap for you to, instead of you having to create this, that we actually have this for you. So thank you very much, Tim. I appreciate your time and thanks for being on with us.
Tim Keckler [00:40:01]:
Talk to you soon. Courtney thank you.
Kortney Harmon [00:40:05]:
I’m Courtney Harmon with Crelate. Thanks for joining the full Desk Experience. Please feel free to submit any questions for next session to [email protected] or ask us live next session. If you enjoyed our show, be sure to subscribe to our podcast wherever you listen and sign up to attend future events that happen once a month.
