How to Assess and Buy Corporate Social Responsibility (CSR) Software
Watch the episode:
Read what we discussed:
My first guest, her name is Tara Scott. She's the manager of growth and market intelligence. And my second guest is Michael Swan, who is Benevity's leader in product management with 10 plus years in B2B SaaS experience. Thank you both for joining me today.
So let's get right into the topic. We're talking about how to choose your social impact and corporate social responsibility software vendor.
I guess let's start with, is there a difference between CSR social impact software and the typical or traditional B2B SaaS?
Difference between how CSR products are develop and other B2B SaaS products
I'll jump in there. I think at a high level it's important to recognize, especially in B2B software, that you're selling to large enterprises and oftentimes larger companies, medium size companies.
They're buying tons of software.
Their businesses are driven by technology.
So it is going to be unique, yes, to the degree in which CSR needs within a company are unique in the job that we're trying to solve with technology.
Some of the ways that I think are distinct from my experience, having jumped from multiple B2B platforms that solve different problems from work management to utility expense management, to all sorts of various elements, CSR is unique in the sense that while we go, Benevity specifically goes to market with enterprises, we have to cater to multiple other stakeholders.
Partnering as a SaaS company with key stakeholders that you're serving is crucial to success.
If you're out there either just reacting to market demand or needs, or you're leveraging your own internal knowledge, we say all the time, answers aren't found within the walls of our building. You have to reach out to get it.
That's probably one of the distinct things that's different.
We not only have to meet with CSR experts within a company, we have to be meeting with nonprofit partners.
We have to be meeting and testing and validating with individuals, how do individuals want to do good in the world?
All of these are core stakeholders that make an entire CSR program successful. That's probably one of the biggest unique things, is our platform technology is only as successful as our ability to unite all those into one location.
Now, is there a difference, you mentioned enterprise, right?
So we're talking to larger organizations.
But how about those companies who are a little bit smaller, who want to know or looking to purchase or just exploring this type of software?
Small to medium sized businesses exploring CSR
I think there's two factors.
I think this is another paradigm in business to business technology as well.
Size doesn't always impact the needs of software in the same ways.
Sometimes the maturity or the breadth or the scope and complexity of a software technology directly is linear correlated to the size of a company.
In CSR that's not always the case actually.
With the advent and increase of remote distributed labor force and lots of other factors within companies, you could be in a thousand employee company and still spread all over the world.
You could also be a thousand employee company and have very awesome CSR practices, and therefore the maturity of your CSR program is higher and the needs of your technology to support it are higher.
I think my recommendation is you need to consider more when you're looking for software.
Does the abilities and capabilities within a software meet the maturity of what you are actually trying to do?
And then if you are less mature, let's say you're just exploring and beginning, consider something that's simple and going to support your needs today to produce that, but also look at something that can grow with you.
I think that's another important thing too, is I've seen it personally in other industries as well, where you go in with something because it's simple out of the box and that meets your needs.
You get really good in that industry.
Two years down the road, you outgrow the solution, you made a decision.
And we all know that the experience of swapping out software within a business is not an easy theme.
Oftentimes there's budget approvals, there's all sorts of deprecation, transfer of data, so many things that come with making those types of decisions, that it's important also to consider where do you want to be and is this not only the technology for that, but is this the partner who's going to help you get there as well? I think that's key.
Sorry, I was going to say I think that's absolutely true, and we've seen that a lot in the last few years because so many things happened to take CSR, whether you're engaging employees in matching programs or volunteerism, community investments, making those grants into organizations that are doing good in communities or at the national level, whatever that might look like. But so much changed in the last few years.
There was so much urgency put on this, that companies that didn't have it all of a sudden were saying, oh my goodness, we need to start offering this.
And what we often saw was the need for speed.
Well actually, let's just say the need for speed often drove decisions that were based on things like price or is this good enough to get me up and running immediately?
And so now what we're starting to see is there are people out there that perhaps didn't slow down enough to think about things like, okay,
- where am I going to be at in two years?
- Where am I going to be at in three years?
- What are those capabilities that I don't necessarily need right now but are definitely going to be valuable in the future?
And that hurts because like you were saying, Michael, it's hard to go, you have to go get budget again, you have to get buy-in again.
Change management is hard. It's really, really hard. So that's where it is important if you can, if you know that you're in a growing industry, if you know that your people are going to be really excited about this and you're going to want to be engaged, you need something that's going to last with you for a long time, not just a quick, let's solve for today.
The one thing I wanted to, because I know Michael touched upon this when he said simplicity.
Buying B2B software, there's a lot of sales people. And just when you're trying to buy, everyone wants to put on all the different features.
And so you mentioned, hey, you want to start simple and actually plan it out because maybe you may not need all these things now, but in two years you may need additional things, but maybe it's not the best thing to get it now.
So how do you navigate that so you're prepared yet you're not paying for features that you're probably not using or maybe not knowing how to use or your team doesn't know how to use at the current moment?
When to add features when buying CSR software
It's a fantastic question.
My recommendation to anyone, and I'm going to maybe switch sides a little bit. On the behalf of companies, one of the things you need to not only look at with software as a service is the technology itself and its capabilities, but also the people behind it.
That's a key thing. And this isn't necessarily exclusive to CSR.
This is actually a pretty common thing.
With software as a service, you want to make sure you find people who can be trusted partners where you can have that conversation.
I think that's a conversation you should bring up directly and explicitly of, this is what I'm trying to accomplish, what do you prescribe and recommend?
It's a healthy balance to strike one of the more unique things, it's not exclusive to the CSR industry, but it is a more unique thing that we as SaaS companies always try to build for 80% of the market needs that can be broadly applicable to the many.
CSR programs are not all created equally across every single company.
So it's really important to find that partner that can say, how can this technology support my current needs?
And also we have a lot of CSR professionals that their programs are evolving, their maturity is evolving. It's a big difference between, am I going to have a partner that's going to try to sell me 1,000 features because it could do things for me?
Or am I going to have a partner that's going to sit with me and say, these are the 10 things you should use right now?
And then when you get to this point in the future as we anticipate, we can talk about these other things that might be beneficial.
That's key in that partnership. It really at the end of the day, it's more than just getting a feature set list and saying, check, I need this, check, I need this.
You really need that partnership during those conversations who will be honest and recommend what is best for you, and maybe that doesn't always match up with what's best for the sales team.
I think the flip side of that too is, I would be a little bit cautious when you're talking to a potential provider and you have your, okay, this is what we want for today, but this is what we want to grow to in two years.
And they say, okay, we don't have that, but we're going to have that by then.
And in fact, how about we just go ahead and build up for you?
Because roadmaps change all the time for a variety of reasons. It could be somebody else bigger than you comes in, and they say we're going to build something for them, and then your thing gets bumped down the list.
Or market conditions could change so that maybe they don't have as many development teams anymore.
So the promise of future features or future capabilities that you know are going to be essential to you, you really have to weigh out, are you comfortable with knowing that that might not happen?
Is today's program going to be good enough for you in the long term if it doesn't happen?
Or again, are you going to have to switch to another provider?
And I think the best, most authentic vendors in the market are going to tell you, this is what our product vision and strategy is, because I think that's important.
But they will be honest to set realistic expectations of what you can expect to see.
My recommendation is always index towards what you're getting right now versus what promises they might be making in the future.
So you both touched on elements of actually the next question.
When we are selecting a social impact or CSR vendor, what are some of the questions that we'd want to ask in terms of how do they develop their product?
What questions should be asked about product development?
I think a great place to start is actually just saying, how do you go about deciding what ends up on your roadmap?
Not just saying what is on your roadmap, but how do you compile a roadmap? What does that look like? Is there an actual robust process in place for developing it?
Is it based on what the market at large needs or are you hearing back answers that are more around, well, a client asks for a feature and we build it?
Because, again, when we think about, okay, why are they doing that? Are they offering to build features to land deals?
Are they doing that because they need those deals specifically to get that revenue from that one client?
Or are they building for where the future is going? Those are the things that I would recommend looking into and thinking about, because if you're getting a provider, and I've seen this especially, I did product marketing for a few years here for our grants management systems and people don't change systems lightly.
It is a very big lift. It is very difficult.
So you want to be sure that you're choosing that partner that's going to be in it for the long haul with you, versus I'm just trying to stay a quarter ahead or two quarters ahead. If there's not an overarching vision there, that should give you pause.
If it is somebody saying, well, what do you want us to build for you?
That should probably give you pause. You should want to be working with someone who understands what you need because they've been paying attention to their client base, what people like you are doing, they understand what those jobs are that you're doing every day in your role. They understand those pains that you're trying to solve with technology.
I think that last point's really important, and I'll throw a younger me under the bus a little bit.
Earlier in my career, I loved as a product professional to have conversations with people and be a hero in the moment and say, what can I do for you?
What problems and what pains can I alleviate?
And I also had this misconception that agility in product development processes meant we just take the moment step by step and take the feature requests and we fit them in and we do these things and really quick turnaround sprints, et cetera, et cetera.
What I came to develop over time was that practice while in the moment it seems like, that's awesome that someone is in front of you.
You have a vendor in front of you saying, I will do what you want me to do. It's very attractive.
But what I experienced was I ended up breaking more promises to people in that behavior than later.
Now I have a little bit better perspective of
I want to partner with people to solve valuable problems, but I want to do it in a way that is following the trends of the market and will also help them grow.
Because the one disservice I was doing to a lot of people was they were doing the actual work of true product management when they were coming to me saying, build this feature, put this button here, we need that.
What I wasn't doing is I wasn't listening to why do you want that button? What's the problem you're actually experiencing?
And then validating how pervasive that problem was, because when you go out from the one to the many, you understand the problem more comprehensively and you can get ahead and actually say, hey, I know you're experiencing this pain today.
What I'm actually seeing is this pain grows into this and we can build something that helps you anticipate both and working with them towards that.
And then they say, I didn't know that because maybe I'm on my own maturity journey and I haven't grown to experience that other pain yet.
And what you end up doing when you're just saying, okay, cool, you want the button there?
I'll put the button there. When they eventually grow into the bigger pain, then it's okay, now I need all these settings and configurations and now I need this custom report.
Now I need this other thing, because now this has just blown up and scaled way out of proportion.
That probably is the hardest I think in those conversations, because it's probably the most attractive thing for you, to find a vendor that's willing to just run their roadmap based off of the information you're giving them.
But I think what you trade oftentimes for that is stability. And then also most of the time, because in full transparency, this is one of the things I actually love about B2B software versus B2C software is we know this is a business transaction.
We're a business not a hobby.
Every SaaS company is a business, not a hobby. You also are a business.
There's an understanding in that relationship automatically. It's no secret we're trying to make money, but we are also trying to do good.
Benevity in particularly as a B corp, that hybrid balance of corporate responsibility and social responsibility is really important. I
think it's important to have a vendor who will listen to you, but if you get caught up in that feature request, it's more than likely that they're going to have elevated desire to support you as you onboard and in your early age.
But then you're going to have a queue of 100 new clients coming behind you in that pipeline that are then going to get that level of attention on the feature request, feature factory behaviors.
And your needs may cease to get the same level of attention as you once did right at the beginning.
That's the other thing that I always felt.
Early on when I wanted to be the hero, I realized, holy cow, one individual hero and a few engineers, we don't scale the same way.
We're not superman that can fly around the world and save everyone's problems.
And you start to realize I have to prioritize and choose to ignore other people's needs versus this, when you're stuck in that reactive state.
And I think we can talk maybe more later about the proactive scaling. I don't know if that comes up, but I think that point in particular is really important.
Find a vendor that'll be honest with you, that has a strategic perspective, that is leveraging and will listen to your voice, but knows that you are not the only voice, not only among the market as far as companies, but also we should be looking at market trends, talking to industry experts. We should be looking at a lot of the regulatory shifts and changes.
All of these factors can cause problems that come absolutely out of nowhere.
When California and the US releases a new law or when India changes their regulatory elements, all of these things, we have to be proactive looking ahead so that individual companies don't have to, they don't have to turn around and say, now I'm hurting until you can catch up.
It's so true. Which is where I think adjacent to looking at, how are they developing things? Even just how big is the team size. Is a vendor that has 10 employees or 50 employees even, are they really going to be able to keep on top of those changing regulatory things?
Like you said, India, California, how about Europe? Or do they have the teams in place that are able to do that?
There's actually two points that you made and I think we can connect them both.
One is how do we know the health or how do we know maybe the experience of a particular vendor?
And then the second question to that is, there has to be some fine line between customization, which we'll get to the next question, and being able to meet the needs of every single customer knowing there is a queue of customers that are coming in that would maybe require completely different customization.
And that customization would be in contrary to the customization you just did for another client.
So now you're having competition, different types of customization for every single client that is starting to be contrary and there's really no way you can have like, you can't have a product that is completely different for one to another, to another, another, which is very difficult to scale.
That's a good question.
I'll start high level from just product management expertise and then we can get into the details within this industry.
But I think first, defining health is important. What are the attributes of a healthy software company?
And it's very contextual. I'll speak to B2B specifically and illustrate the backdrop of how that's different with maybe a B2C company.
Attributes of a trustworthy B2B Company: Predictability, Scalability, Stability
I think the attributes of a B2B that are core are predictability, these are all elements kind of trustworthiness, predictability, scalability, and then also stability.
The three things, predictability is all related around, you know, if you're buying software, I think all of us can relate to, we don't want the system in production changing every single day.
Most of the time what I've seen is we have awesome champions we're working with on the company side who are supplementing in many cases our documentation materials, best practice recommendations, potentially training stuff on their learning management system software.
They're producing a ton of materials around how to help enable their users to be most successful within the software.
If we're changing every single day and they put a screenshot, they now have to update that image.
That's just one scale of that lack of predictability and consistency in releasing software is really important. I think the health would be, how frequently do you release software?
How do you manage that as well? What does that look like?
And if they're willing to share with you, talk to them about their bug count, their active bug count.
I think that's an important thing too is; you can release super, super fast, but your system can also be very, very bugging and that can create a massive amount of hindrance.
But that's where predictability comes in.
Also, that the company from a strategic standpoint is predictable, that they are planning and managing their targets of what they're trying to build in an effective way that a bunch of individual value tells a story over time.
That's another maturity.
And you can see that by asking them about the roadmap, asking them about their strategy.
If their roadmap looks like a bunch of doorknobs, we say if you're building a house and you ship all the doorknobs first, they can extract the value, build the front room first, and then at least they can sit down and relax while you're building the kitchen, right?
That's the idea, is the way you structure your roadmap is very important as well.
And I think really healthy companies and more mature companies have that perspective.
The other elements of scalability come into what types of technologies are they using?
Do they have cloud-based data stores?
And do they have data residency across and do they auto-scale with bandwidth? And things like that.
That'll make sure that as your force goes up, if you have 100,000 people in the system in the same moment, in the same day, is it going to bring the system down?
Those types of things are important. If you need to run 500,000 lines on a report because you just have that much data, can it process that reasonably?
It doesn't mean that everything has to happen instantaneously.
I think that's a little bit more important on the B2C side where users have become very accustomed to getting everything instantly. I think B2B, we understand a little bit more that's reasonable, but there's ways you can handle scale and to make it feel better.
If you know a report's going to take a long time to process because it's reasonably a large report, give the user an experience that's like, hey, we're processing your request.
We'll deliver it to you when it's ready.
Go about your business.
Don't make them sit there with that spinning wheel of death.
Those are those types of experiences and little tricks of the trade that you can do to make it, that more healthy companies will be thinking ahead of the end user experience and not just the function.
I think when it comes to customization versus configurability as well, the health of a software company can be dictated very heavily based on their business model.
You will be a lot less predictable for a broad market of clients.
You'll be a lot less predictable if you're trying to custom develop for each individual. And you're absolutely right in that.
A company is evaluating certain vendors that they'll promise them a lot of things.
So what are some of the benefits to that? But also I know you've touched on quite a bit of the drawbacks of that.
Benefits or drawbacks of software customization
I guess the benefit is that you get exactly what you say you want. But then at the same time, to me that's the main benefit.
When that benefit will be realized, probably depends on how complex it is to build that thing.
But then if you are saying, because again, it's not uncommon.
I've talked to many, many people who have purchased software in our space who have gone through experiences where they thought they were buying SaaS, they ended up getting some customization.
And then there's a new product release and either, A, you don't get to take advantage of the product release. You're actually locked into what you have now.
You might as well have had some an on-premise installation, because that's just how it is.
By having a customization you don't get to take advantage of anything new.
Or on the flip side, I'm not actually sure if it's better or worse.
They're both pretty terrible.
The flip side is you still get new product releases, but maybe that thing that you're entirely dependent on that they built only for you gets broken, just because something new gets released.
And that is a big problem.
So instead you should be working with someone who says, you show up and you say, I need this thing.
The next thing that should happen is curiosity.
Somebody saying, why do you need this thing? What are you trying to do?
What are you trying to solve?
And even if they say that, but it turns out that they still have to promise to build 80% of what you need, that's probably scary, for all the reasons we've talked about before.
Are they actually going to be able to do it?
Are they only doing it for you?
What does that actually look like?
Now, if you talk to somebody who says, okay, we can't do it exactly like you described, but we can absolutely solve your need and this is how we can do it, and they can do that 80% or more of the time, then you're probably talking to someone who is mature in the space, they're not just trying to catch up to all the players, they're not just me chewing or making promises to land a specific deal.
They actually know what you've been through. They know what you need and it's going to mean some change for your team in how you've managed things.
But if you're looking for a new provider, there's probably a reason.
So is it actually good to replicate your old program on a new system or is it better to be open to the idea of change?
You're still going to solve all the same problems.
You just might do it a little differently, but you'll be able to do it differently also with a vendor that has a community of other people who can help support you, who has been there, who has done that, who can help you with ideas of how to help manage the change in your organization.
I love that community piece too, because probably one of the most telling questions that you could ask a vendor is, right after you say hey, we really have this thing in our program, could you do this for me?
And it usually is some sort of customized feature request or something like that.
Another question you can ask is, are we the only ones that have this problem or have you seen this before? And who else is experiencing this?
And oftentimes too you may even ask, could we talk to them and ask them how they're leveraging the system or how they're solving this?
Great SaaS companies will accommodate that and absolutely will try and find others in the network, others in the community.
Also good product management and product representatives that you're talking with will go and do that investigation.
Sometimes the answer will be, we don't know.
This is actually the first time that we're hearing it. Thank you for bringing it up. And that curiosity should lead to, tell me more about the problem.
Understanding the problem.
Usually the process that my team follows is, first, problem discovery and validation. Second concept formulation and validation.
Then we get into usability testing and actually building. But that problem, understanding that problem is key, because then when I go, there's a big difference between the maturity of a company that goes and says, hey, they asked for a button on this page, would you also like the button on the page?
That's not a great question to ask other people.
But if you say, hey, this other company's experiencing this problem, who else is experiencing this problem?
And you get curious and you go and ask the rest of your network, then you can get a lot of them that resonate and say, yeah, we are actually also feeling that problem.
Because I've experienced this a ton of times, I can't even tell you how many, where I've talked to 20 different companies, they asked me for 20 different customizable features, and then when I dug unto the underlying problem, they all had one same problem.
And then we ended up maybe building on one of the suggestions or in some cases building a whole net new theme.
This happened to me in the work management space that everyone was coming from a space of managing work in spreadsheets.
It was ridiculous that in the last five, 10 years, one of our number one competitors was Excel spreadsheets, crazy, right? In the CSR space we see this as well, spreadsheets all over the place.
And it's awesome because spreadsheets are very customizable, very, very good at catering your thing. And if you're a company solving your own problem, totally makes sense.
If you're a SaaS company and you have a client using Excel spreadsheets that comes to you and says, I want to replicate this in your system. It's one of the worst things you could possibly do.
And we learned the mistake, one because we did it, and then two, it didn't work in market.
And after two years of trying to mold it into something that actually produced value, we ended up turning around and saying, we have to completely rethink of this.
And that's where innovation comes into play, is we as product experts knew what technology could do, understood the problem because we partnered with others and we built a whole entire new product that supported things in a whole new way that they hadn't done it before, but in a familiar enough way that we brought them along the journey and increased their best practices as well.
That I think is key to customization.
And we took a bunch of customized requests and turned it into a non customized solution that's broadly applicable.
I think your first comment as well, Tara, is spot on, in that it is risky to ask for those because the same reason you like it, that they're willing to cater to your specific program and give you exactly what you want, also isolates you.
And that is a reality of, as a product person I'm representing an entire market, I have to think of the needs of the many.
I do care about the individual clients, but automatically when I'm looking at big industry problems, my perspective is always going to be here's the bulk of the trends and everything, and here's those that insisted on continuing to do something completely unique.
I have had those hard conversations and I think it's the right integrity type thing to show of having those hard conversations with large companies that are globally known where I've had to say, you are literally the only one that wants this and therefore we're not going to do it.
And it was hard for them to hear that.
But then the conversation evolved from there of, well, if we're not going to do this, tell me why, why aren't other companies doing what we're doing?
And they got curious and we were able to say, well, because the best practices are moving to this and this is what is leading to better results.
Naturally on their end they said, well, we're open to evolving. We don't want to be stuck in the past. And then they were able to open their eyes.
And I think that's another thing is when you give customization, oftentimes you perpetuate keeping people in a state where they don't evolve with the industry.
SaaS software should evolve, but it's not just about that. The way in which you address it agnostic of software is going to evolve.
This industry, this SaaS industry is evolving rapidly. And so you should also be questioning and checking your practices.
It's so true, because there are times where you can even say, well, okay, not only, why do you want this? But why do you do it that way?
And it's not uncommon for the answer to be, you know what, I don't actually know. This was something that was in place before I even started this role.
Like I said before, the world has changed so much in the last few years, it's demanded a lot of companies, but there are also some companies that have incredibly mature, sophisticated programs, they've had them for decades.
But some haven't even looked at, okay, should we be updating what we're doing? We know we've been doing this for decades.
What should we be doing to change to make sure that we're meeting the changing demands of our employees, of our customers, of our insert, whatever other relevant stakeholder there?
And so looking for a new vendor can be a great opportunity, especially if you can find someone who is consultative to step back and say, what is still serving us and what is no longer serving us?
Rather than being focused on let's rebuild, we just need to take our home and pick it up and build it on a new ground.
Just to round out maybe this question, I think one of another healthy practice it is, that avoids the pitfalls of customization, is when you bring up these questions to either your current vendor or a prospect, their first instinct should be, let me show you where our vision in our roadmap is and see if one of those items that we've already prioritized might fill this problem need.
If they're able to do that, one, that tells you that they're listening to the market and doing the proper amount of research, because oftentimes they're ahead of the pain points, they're already aware.
Two, if they're doing this, this also means that they have probably a little bit more mature practices as a SaaS company and understand that it's better for me and better for you if I can align you to the things that we're building for the many.
In addition to product development practices, is there anything potential software evaluators or people or businesses should consider when they're concerned about the health or longevity of that CSR or social impact supplier?
I really like what you mentioned there about not just being a supplier or a vendor of said technology and configuring it for you, but also being a partner in terms of maybe a year or two, because that business is in the industry, has their ear to the ground and knows about the emerging trends, they can feed it right back to your business and say, hey, have you considered this?
And it's not to upsell you to a new feature, but it's more of like, hey, you may want to configure your software to take advantage of this trend, and it may not be a cost, but in more of just a different perception or a different vision or a different direction for your company.
What to consider when looking at health and longevity of a potential CSR software provider
I think it is that partnership concept that we've been talking about a little bit. Really was touching more on partnership from a software perspective of, in the product development lifecycle, how do you partner with people to validate problems and know?
But you're right, software vendor beyond the development of software has another aspect of partnership where you want to partner with a company and some of the best software companies will not only produce technology, but they will show up as thought leaders as well and experts in the industry. I think that's something you can see is, what other companies are they partnering with bodies and other things like that in the market for CSR?
Do they have great relationships with some of the most established and well known nonprofits, for example, or other things like that?
That partnership is key. But also, where is their voice?
If you can see their voice outside of their own marketing messages where it's their speaking and there's, whether it's, I don't know, a podcast maybe like this or a website or shows up in a news article or somewhere where there is messaging simply for the purpose of furthering the CSR industry that isn't talking about, hey, this is a feature function that we just released, come and buy it.
I think that's a key indicator for me that you probably will find in that a partner who is also in addition to solving your problems with technology, they're going to be a partner that can encourage you to become there.
I think that element is really key in maximizing your benefit. And you're absolutely right in the sense that sometimes from a monetization, because again, we're businesses, we're not hobbies like we are working together.
Sometimes it will lead, quite frankly to an additional add-on product, but not always.
The intent is not always there to do that.
Sometimes recommendations are given like, hey, have you considered running a matching program or a rewards program in X, Y, Z way?
That may not be aligned to a more traditional program or methodology, but the reason we're recommending that is because your engagement numbers or your participation numbers to maximize the benefit of your own program could significantly increase based off of trends that we're seeing.
That's a perspective you'll find in a partner where they're willing to share benchmark data, if not in actual insights anecdotally by saying, hey, we're working with a thousand other companies like you and those that are succeeding the most have these common practices and be able to bring that to you to make you aware.
Essentially the best partner, I guess, in what I'm saying, is going to enhance your program by making you better, not only in software capabilities alone.
I think to keep in mind that, especially true, I've worked at Benevity for over six years now, so I've seen many, many, many of our clients, different sizes, different industries, all kinds of things.
And one of the things that's common is that most are run by small teams, often are run by teams of one, maybe two, and that can be very lonely.
It can be very difficult to think about, how do I do better?
Especially when, even some of our clients are running these programs off the side of their desk, and so what's going to help them? Everybody right now is trying to prove the value of what they're doing.
The economy is changing all the time. And this is especially true for folks in CSR. We recently released a report that said that for employees that use our software of our clients, they have 57% lower turnover than the employees that don't use it.
And companies are trying to figure out, yes, there are layoffs happening at some companies. How do we retain the people that we want to retain when they've laid off a friend?
And again, when you go back to small teams, you want to be in community, you want to work with other people like you, even if they're not at your company, and you want to hear, what are the stories of what other people are doing?
So again, if you can find a vendor who can support you, be that extension of your team, first of all, because again, tiny team, you want the product to solve your problems of course, but even then there's still more to go. You want to hear what other people are doing, what's good?
Who's elevating those voices and telling those stories of the things that are helpful for you to know so that you can run your program either more efficiently, so that you can do it in a way that people care more about?
And so that you see, say if participation is something you really care about, what's going to help you get that better participation?
What are those things that you need to do as a CSR leader to make sure that your work shines to your leadership, so that they understand that what you are doing is absolutely critical to your business. It's actually not a nice to have in times like now.
So how do you have a provider who can help you make that case, who can help you tell that story?
And just lastly, at least lastly for me maybe on this topic.
I really, we at Benevity we obviously talk a lot about doing good in the world and acting as a catalyst for a culture of good.
That's definitely important.
Personally as a software professional in any enterprise company, Benevity or otherwise, one of the most satisfying experiences that I've had is when you know that you've empowered someone else either through prescriptive best practices or software to become a hero.
And I've had this happen before where a champion that you're partnering with that you're really enabling and you showed up as a vendor and helped them completely shift whatever job they're trying to do in a company. And then you hear later that it's like, I got promoted from being a CSR professional to being the VP of social responsibility, corporate social responsibility or something like that.
I love making heroes out of champions. There's nothing more satisfying than that. And I think that that's a really key important thing.
Obviously we have to keep in our mind multiple aspects of helping programs flourish and catering also to the needs of the individuals who are actually committing acts of goodness. But that is one personal thing that I get immense amount of joy on as a partner.
And I think many great SaaS companies do the same. They know. You see this, I'll just call one out, not intentionally to plug Salesforce, but I think Salesforce is a good example of this, there's tons of positions.
You can go browse LinkedIn all over, and you'll find tons of positions and jobs that have been created just because Salesforce helps people become champions.
And now the titles are showing up, Salesforce expert, Salesforce integrator, Salesforce, et cetera. And the way they show up as a vendor to enable that as a platform and that growth is really important.
And I think that a really good SaaS company knows who their champions are and seeks to prop them up.
That's one way maybe to ask a company of just, if I use this software, how will you show up and what support can I expect as I'm seeking to fulfill my program and meet certain targets and grow in industry practices?
That could be a very telling question as well to ask your vendor to see how they respond to that.
Tara and Michael, I know we could talk a lot longer and a lot more about this topic, but if our audience wants to connect with you, what's the best place to reach you both?
You can absolutely please find me on LinkedIn. I'd love to hear from you. I'd love to hear what you think about the episode, if you have any other thoughts, search for Tara Scott at Benevity, and you will find me there.
I'll give two answers because I anticipate there might be varying reasons why someone might want to talk to me.
If you want to talk about just generic software practices, software expertise, recommendations, insights, things like that, I would say same as Tara, reach out to me on LinkedIn. I'm always happy to talk to people that are curious about those types of practices.
If you specifically are listening to this and are like, I have specific ideas for Benevity and its product, you can reach out to me.
My email is Michael.firstname.lastname@example.org You can reach out to me there.
But my recommendation to you is follow your client success manager if you're already an existing or if you're a prospect, talk to the sales rep. That's going to be the best way for us to be able to get in touch to make sure that we hear your voice from the CSR perspective.