Name: The Fundraising Efficiency Gap: Why Generic CRMs Are Costing Your Mission
Uploaded: 2026-02-19T19:30:24.620Z
Duration: 56 min 48 s
Description: The Fundraising Efficiency Gap: Why Generic CRMs Are Costing Your Mission

Transcript for "The Fundraising Efficiency Gap: Why Generic CRMs Are Costing Your Mission": Well, good afternoon or good morning depending on where you are located. Welcome to today's session. This session is, titled the fundraising efficiency gap, why generic CRMs are costing your mission. Today's presentation will be Jennifer Alonzo, who will introduce herself here in just a second. I just wanna do a few quick housekeeping items. This webinar audio broadcast through computer speakers, so hopefully, you guys can hear me today. If you encounter any issues with audio or slides, freeze, anything like that, typically, refresh the browser. It does the trick. If you you know, if that's not doing it, do a quick exit, log out, and log back in. That that's it. A few other things just to get yourself acquainted with system here in GoldCast. We have the chat, so feel free to submit any anything you want in there, any questions, any I think we have we're we have a poll question coming here shortly, so feel free to use that. There's also the q and a. We have a team back here that is happy to answer those questions. We also have someone on our team, Sophie Wilson. You can I believe you can direct message her? There she is popping up online here. She is happy to assist you with any questions you have regarding Blackbaud solutions. Sophie, thanks Sophie for joining us. And then lastly, any settings that you guys wanna adjust, there's a little cogwheel on the bottom portion of your screen. Use those to adjust those. And then oh, sorry. Lastly, the last thing that we always get questions about is will I get a copy of this recording? And, yes, of course, you will. You'll get in the next twenty four hours via the email that you signed up for this webinar with. Alright. With all that out of the way, Jennifer, would you mind introducing yourself? Yes. And thank you so much Blake and Sophie and Ashley who is backstage. I appreciate everybody's help getting this together. My name is Jennifer Alonso. I've worked with Blackbaud since May, 2025, so not quite a year. Before that, I ran an implementation team that worked on, Salesforce for nonprofits. Before that I worked for nonprofits as an artist and then eventually as a professor who was running programs and fundraising on my own. So long history since high school just in terms of really helping, working for, and working with nonprofits. I am gonna now see if I can get my speaker mode on. There I am. Alright. So I want to thank you all for joining us today and the goal is to make this genuinely useful. It's an educational session about patterns we see across nonprofit CRM programs. And one thing that when I was a professor that I really found is the more people participating in a conversation and the more helpful it is for everyone. So please do feel free to offer thoughts in the chat and share with each other your experiences, especially if you have had experience working with a more generic CRM that wasn't purpose built for fundraising. So we noticed when organizations adopt commercial platforms, because of that promise of flexibility and power, and I remember how excited I was when I first started working with Salesforce, there is a discovery towards the end that that flexibility has a really long tail in terms of schedule for implementation and especially for budget. So to set expectations here, we are going to talk about generic commercial platforms that can be excellent. In many contexts, if you have the right team and I think most importantly the right government governance, a generic CRM can be the right answer. But today what I really want to talk about is what happens to fundraising operations teams when the CRM is not purpose built for fundraising and where workflows are not out of the box. A little little hint towards with my clients that I had when I worked for a Salesforce partner. They didn't know what they didn't know, and I didn't know what they didn't know. Right? And so that often what would happen is that the expectations were misaligned. And so my hope with this webinar is that, I can help you all align expectations as you either continue with your current CRM or consider moving to another CRM. So basically, there are some traps with the generic CRM and their claims of flexibility that I want to bring to your attention. So to start then, I wanna ground this in reality. So we're just gonna start with a quick prompt. So in the chat, if you, I'd like to know if you can wave a magic wand and change one thing about your CRM and that could be functionality, but it could also be how you work with it, What would it be? And optional, I'd love to know what you're currently using. Most of the pain points fall into a small number of categories. So there's often data entry friction, there may be reporting trust, issues with acknowledgment and receiving, and the hidden cost of customizations over a lifetime. So for you all, feel free to tell me what's your magic wand. If the thing that you could move that creates a lot of friction in your CRM, what would that be? And as you're thinking about that then, I will move on to this next piece, which is just our agenda. So first, we're gonna define what I mean by a generic CRM versus purpose built for fundraising. So we'll talk about then the customization trap and how really well intentioned people, vendors, implementation company, you know, delivery companies like I was and nonprofits can accumulate technical debt that shows up as obstacles later for fundraisers. And then finally we'll share what the alternative looks like and what you can do to really choose a purpose built fundraising system or a more custom system based on a really, really honest, assessment of where you are as an organization. So I think that's really important is that most organizations and implementations with new CRMs do not fail because people made bad decisions. Right? They often fail because the operating model is different from what folks expected. They're really looking for, while they were looking for a more flexible plat platform, the governance documentation, discipline, release management, and admin capacity was never staffed for and really was unexpected. And I'll just report back. Jessica says they're using Virtuos and looking to move due to slow performance, bad support, and reporting troubles. And, boy, those workarounds on reporting troubles can really be, hard. And then that core integrations part. Thank you so much, Jessica. Alright. So we'll go here. What is whoops. I hit the wrong button. Here we go. Alright. I got it here. What is a generic CRM? So what I mean when I say a generic CRM is that it's a platform originally designed for a different primary business problem. So typically that is sales. Financial services come up and another and other industries come up as well. And then they're sort of adapted for nonprofit use. And these platforms tend to be very strong at what they were built for, pipeline management, account hierarchies for forecasting, case workflows, broad integration patterns, they seem really attractive and especially that last one flexibility. And I think especially, right, if you are struggling to get the information you need to make wise decisions, that flexibility part seems quite delicious, right? We can have anything we want. We have reports the way we want them and then all of our problems as an organization will be solved. If we then think about those other purposes and what they assume, that creates a tension. So and the tension for me is this this idea that fundraising is just sales but nicer. And as someone who has always worked for nonprofits, I didn't work for a for profit company until I was almost, 45 years old. And the I found that really hard to swallow. Right? Fundraising has domain specific requirements that are really not considered in something that was primarily built for business to business sales. So I'm thinking of things like soft credits, giving circles, tributes, really complex gift processing where we have many designations across that need to be split across gifts and pledges. And especially I feel like the relationship driven recognition was really ignored in some of the products that I worked with that were more general, and, you can have whatever you want on top of this general piece. So today we're gonna talk a little less on features and really think about the operational reality of what it means to be working on a platform that was really meant for sales or financial services or automotive. And I'm gonna give the automotive example, just because there is a tool that was created, for for automotive by Salesforce, right, that, is a really, really powerful kind of user interface plus logic tool. And here was the problem. I stopped using it for my clients because it was too complex for a single database administrator, which is what I was working on, working with to really handle. Right? And the development teams who maybe my larger nonprofits worked on were really interested in the integration. So we had this tool that was very powerful but meant for organizations that had really different resources than nonprofit. So again, this conflict and tension between what fundraising and nonprofits are versus what other organizations need is really important, and that's going to show up when we hit into this friction. Alright. So what it means when you are retrofitting is that you have to put a lot of different pieces together, and it falls on the nonprofit to actually put all those pieces together, maintain them, and make sure that they continue to work together. And if if any of you all have ever had something that broke that you thought was perfect and you had a third party app and and a customization and it broke, I would love to hear about that and sort of the lessons learned from that. So what happens is that the labels and the objects may still the standard ones may still reflect the original platform purpose. So I, as a fundraiser, may have to use something called a sales process or a sales plan. That you know, I can handle that, but it does kind of irritate me. Right? And then if that flows down through the donors, that really is a problem. The only thing that happens is that the staff is sort of forced to click around objects instead of following an intuitive fundraising workflow because, again, right, the workflow may be built for b to b sales, but then you have to click around to get your recognition credits and your soft credits and your relationships. So the data model starts driving the work instead of the work driving the data model. And that's when we hear we didn't know what we didn't know, it's that missing domain assumption. Right? It is not okay for a gift officer to have to open seven or eight different objects to be able to correctly put together a giving package for a high a high giver, a donor with a lot of with a lot of gifts. So I wanna pause here and say this really clearly again. Right? Teams choose these platforms with really good intentions, and the folks who make them also have really good intentions. And it is possible to thrive with a generic CRM when there's deep admin capacity and strong governance. So the intent is good. The question is whether it's a really good long term model for your organization. So are you going to thrive? I think is a really important piece to consider. So when we're thinking about this generic CRM that was built for something else that has an overlay for nonprofits, the promise we hear all the time is this idea of flexibility. And I think especially, right, if you're really unable to do what you need to do and report against you, that idea of flexibility is really delicious. You can have whatever your organization needs, and it is so true. You can. But every custom process requires additional discovery, stakeholder alignment, design, build, testing, training, documentation, and long term maintenance. So anything you have to customize, like automating your giving circles becomes your responsibility to handle on top of a generic CRM. So this is a permanent cost. So the question we want to explore today is not can you build your fundraising operations on a generic CRM, but really should you and is the juice worth the squeeze? All of that effort to do what you really should expect your CRM to do anyway. And I will I will say I did have many, what to me were embarrassing conversations with clients. You know, in my previous job when I was working on custom implementations when they would look at me and maybe coming off, I'm r e seven and say something like, well, I would have thought a system built for fundraising would have that out of the box. And I would always have to have an answer that says, you know what? There are fields out of the box, but the automation you're talking about is not available out of the box. That's something we have to build. Right. So customization is not itself harmful. There's nothing wrong with doing that. And in fact, all of our products, which are purpose built for fundraising, we'll talk about that in a minute, to have a way to be flexible and extend them. But my argument is altering and what I've seen with my customers, right, is altering core fundraising mechanics can create complications and make something that you could buy out of the box very expensive. So when organizations design and maintain standard fundraising workflows, the intended flexibility results in technical debt. And this debt leads to increased maintenance challenges, reduced scalability, and slower innovation within fundraising operations, which ironically is exactly the thing that, my clients were trying to escape when they moved to a more generic CRM. Right? We wanted that flexibility and suddenly we're locked in, and I'll talk a little bit about how that happens in a minute. Alright. So now I'm gonna tell you what I mean by purpose built for fundraisers. Purpose build doesn't mean no customization. Again, it means the system starts with fundraising mechanics out of the box and then you extend from that really stable foundation that is again meant for fundraisers instead of reinventing core fundraising processes. So when I go here and I talk about this, what this means is that the core fundraising meant for fundraisers really starts with that data bottle and the data model revolves around the constituent and the gifts and avoids confusing labels. So it really thinks about what is the fundraiser going to do all day with those constituents, right? So again, it is really not about sales, right? It's important to get gifts, but what we really care about is building those relationships. So constituents first. Fundraisers are then not thinking about which object am I in? Am I in the party relationship object? They're thinking about, okay, what is the relationship and how do I want to model that with this particular household? They're thinking who is this person and how they how do they relate to others and how do they give? And this really can this really resonates I think with users that what I am doing is relationships. I'm not doing database. Standard fundraising workflows have to exist out of the box. Right? If you're thinking about fundraising first. So standard workflows already exist. There's a robust gift entry system. Right? So you can get everything about a gift into your system, whether it's through an integration or you're getting checks in a party and someone is entering those. Acknowledgement, soft credits, recognition and reporting all come together in a way that fundraisers really care about. And again you're not designing from scratch, you're choosing how your organization applies them. So the distinction isn't choosing versus designing, it's avoiding technical debt. The other thing that I think is really important that kind of blew my mind when I came to Blackbaud is their settings instead of builds. So common fundraising decisions are handled for the whole organization and then they can be handled on a one to one basis with fundraisers. And I think, in a minute, I'm gonna talk to you about soft credits and how that works, but we can even think about giving recognition circles. Right? There really should be a way in a standard fundraising platform for me to say, hey, my bronze, silver and level and gold level gift circles look like this. And once someone reaches those within really simple rules, they should automatically be added to the giving circle. Another example is really thinking about, how, you know, salutations. Right? Am I able to say, normally, we have, an informal salutation and that for this family looks like Jennifer Alonso and Brian Wilson. We say, hey, Jen and Brian. But my parents really need to be called mister and missus Alonso. Right? So we should be able to do those things without building a flow or something on the Power Platform. And then what we do is we say, okay, customization is reserved for what's truly unique for us as an organization. Unique programs, specialized towards your models are mission specific supporting. And that's where you really should be using low code or or pro code. That's where it belongs, where your organization is truly different from other nonprofits. So purpose built CRMs don't eliminate customization. They protect a fundraising foundation so that the what is custom doesn't become a liability. Right? So you are not going to hurt normal fundraising operations if you choose to customize. So when I saw organizations struggle on generic platforms, it's because they were customizing the wrong things. So core fundraising mechanics really should have been stable. And then once those mechanics were set, then then any change or any extension should have been easy. And what really happened is every change became really risky. So if we said for example the gold level looks like $5,000 and above and now we need to change it. Gold is now going to be 10,000 and above. We would have to rewrite an entire flow and all of the logic in it and test it and go through an entire development cycle instead of pressing a couple buttons and saying, There we go. We figured this out. And then every report then becomes really questionable and then staff transition becomes painful. So now that so now that we're really thinking about what purpose built means, what customization means, let's look at what happens when those assumptions are present. And I'm going to specifically talk about automation and maintenance and kind of long term costs. We already did this question. So if you still wanna talk about magic magic one, feel free to put that there. I'm gonna move to the next, piece here. So again, here we have our promise. We have flexibility and power and the result becomes endless customization and custom workflows that require a manual just to send a thank you letter. And now I'm gonna be a little snarky because 100% of my clients did not have a manual because no one kept up with the documentation. And I'll talk about why that is. Right? So so we have our promise of flexibility and power and then kind of a result of really endless cost. So there were two reasons for this. And the first one is without really strong leadership management in an implementation internally, so I'm not talking about the the vendor who is implementing a generic CRM for a nonprofit. But but within the nonprofit, there are choices at every step. How are you gonna do soft credits? How do you want your, recognition recognition circles to work? So we have those and then we have to say, is the button green or blue? Should it be on the right or the left? And everybody has an opinion. And so without really good internal leadership, folks, can really fall into a hole of spending $250 an hour, which was my rate, with a fundraising staff, making no decisions for four hours and $2,000, right? That's a lot of money, for those sorts of things to happen. So one of the things to really think about, right, and what happens with generic CRM implementations is that we get into a cycle of poor management in terms of making decisions for a system. The other thing that happens is that the commercial platform where everything is possible, anything you build becomes your cost. It transfers the cost of standard fundraising right back to the nonprofit. So you have to build it and this is I think everybody kind of understands that, but you have to design it and that's something that maybe if you've never worked in software development, you don't know and that takes a lot of time, and then you have to maintain it. So if something breaks, you don't just call Blackbaud and say, hey. Soft credits aren't working as expected. You have to call your partner or have someone internally who can fix that. The other thing that I think is really important is that we may have generic CRMs with a nonprofit overlay where the shell of the information is there. So, giving circles are there, but the automation is not there. So again, we still have to design and build that automation that says, wow. As soon as you hit 10,000, you become a gold, giving circle member. And that, that happens automatically. No one has to go say, oh, now Jennifer has skipped over to $10,000 in gifts and if only, and she's in our gold circle. Right? So I do when you were thinking about new CRMs, I think being really careful understanding, am I just getting a shell of information, or is there actual functionality that my fundraising team needs that's there? And I am going to go to the next slide and show you kind of what happens. Right? So everyone is doing a really good job. They've engaged someone to help them select. They have gone through an RFP process. They have decided that they are going to work with the generic CRM platforms, and they purchased their licenses for five years. So that is sunk cost. That's forever. Purchase licenses for five years. So now when we get to when it's time to go, they find out that there's a lot more that they hadn't thought about. So the first thing is they probably have to contract with a partner, right, to build the system for them. So they need not only the license, the vendor who sells the platform, but they need a vendor to actually construct the system for them. And that contracting 100% all of the time is going to take more time than anyone thought. And in fact, right, sometimes, if you buy your licenses first, it's it's from a totally different company and they can make some promises that maybe the partner who is contracting for implementation has to disabuse you of. Right? So actually, you are not gonna be able to start at the end of next year. It's going to be, you know, it's gonna be the two quarters after that because that's what's reasonable. Discovery happens for everyone, right? We need to understand what you need to know. But what happens if you're on a generic CRM is that there are going to be gaps. And even though you were really, conscientious and worked with another vendor to put together your RFP, there are going to be things just you didn't know where, what you meant in your RFP is different from what the vendor understood. Right? So do some discovery and find out like, oh, you really expected there to be automation so that as soon as someone donates, they become a donor. Awesome. I didn't know that we can build it, but it's gonna cost some more. So and maybe we really don't think that you should customize this. We really think you should purchase another product. So then you this is so sad. You have to go and do yet another round of vendor consideration. Right? You have to go sit through more demos and understand more about third party apps and how they're going to work and then you have to choose one. Right? And so that can be very onerous that you thought you were done with your buying decisions and there's a bunch more. Your implementation partner then is going to do design in an estimate, bring it back to you and they're going to say, hey, most of the time this is going to cost more than you thought. You need to make some decisions about what are we gonna if you can't change your budget, right, what are we not going to have that we thought we were going to have in order to do these things that we didn't know we needed. And that can be a very painful conversation and that conversation can often happen when put you in a situation where before anyone puts hands to keyboard to design your system that someone has to go talk to the board and explain that you were projecting a cost overrun before one single field has been built. It's a really hard, painful, painful, painful conversation. Right? We haven't done anything and yet this is gonna cost way more than we thought it was, or we're going to have to make some really hard decisions about what we get. And I'm just gonna remind everyone, if you purchase your licenses first, you're stuck. Right? Those you either have to pay for those licenses. You have to pay for those licenses whether you implement or not. So maybe you see, you make those hard decisions and you begin your build. And as you build, there there's often more conflict. Right? Oh, and I'm I'm being a little silly about this. Right? It's a green button and I wanted a blue button or this should happen in a different order. And what happens is folks who are not professional purchasers, and I'm sure none of you are, but if you are a professional purchaser of CRM software, you may have made a lot of decisions here in discovery and design that you regret over here. My clients did, right? And so we again have another hard conversation of, well, you told me that's how you wanted soft credits to work. You said you wanted always for the, for the spouse or the partner in the same household to receive a soft credit. I built it for you that way and now you're telling me that you want an override for that. So that is going to cost even more. And oh, now you have an edge case if you're working with donor advised funds. Right? So even in the implementation, you're having to make decisions and it begins to cost more and create more places where you really have to drive decision making and you have to drive compromise. And again, if you don't have someone who is really skilled with that in your organization, that can cost really a lot of wasted money, which will make your implementation partner, if they're like me, very sad. The other thing that happens is this really painful part, where internal staff starts to starts to resign. So, I'm wondering if anyone can put in the chat if they have had the experience of sort of we call it the CRM graveyard, right, where folks are just like, I'm out. I came to this job to become a to level up as a director of development, and instead, all I am doing is having meetings with an implementation consultant. I don't want that in my life. So that can happen and does really often happen. Right? So there is a cost there of just the difficulty of making those decisions over and over again, regretting those decisions because you didn't know what you didn't know, and then having to at the end say, the whole point of this was to be able to be flexible and integrate, and I have now used up my integration budget building things that should have been that would have been in a fundraising CRM out of the box. So what often happens then is we say, hey, we need to tell the board we've launched. We're gonna launch our CRM. It doesn't quite have what we originally had, and and we're not able to build our integrations. We're still gonna be using flat files. So we're gonna have a phase two later. We're gonna ask the board for more money later. And the sad part for me is that sometimes doesn't happen for an organization. Right? So everything that they really, really thought they were getting has to be moved to, another phase which often they don't have the money for. So worst case scenario, this doesn't happen with everyone, but it really can happen. And I have observed it happen with many, many clients really predictably over the years. Alright. So here's my example of soft credits. Just super easy. Right? They are predictable. Right? You know what the relationship is and you know for your organization how you handle those soft credits. So whether it is me with my employer, whether it's me with my donor advised fund, or whether it's me in relationship with a partner or spouse, you know how you always handle that. That's what I mean by the automated soft credit. So just as an example, Blackbaud CRM has it, RENXT has it, commercial platforms do not have it. All they have is the holes to put soft credits into. So your gift officer, every time there is a soft credit, has to enter it two times, which is a lot. That is a lot. At the same time, right, we do need to override. So my husband was a fundraiser for twenty five years and he this one couple that was very clear that she had her play money and he had his play money and that they should not share soft credits or what what I call it BBCRM recognition credits. Right? Should not be shared. Don't give him credit when it's me. Don't give me credit when it's him. Right? So I, as the gift officer, really need to override relationship levels? Blackbaud CRM has it, Ariana NXT does not have it, and commercial platforms don't have it. But, right, this idea, and I think it's really important to be able to override at least at the gift level is available. So it's all there. You just press the buttons and say, okay, for this organization, this is how we're going to do it. And if you change your mind, it takes a long time to decide and what how you're going to handle things, but actually doing it takes two seconds, which is not the case if you build something like this in a generic platform. So this is a very kind of simple, okay, this is how we are going to do soft credits for this organization in a low code environment. If I want to change any of this, have to open up each one of these little shapes, make changes, and go through the entire development cycle. So you can imagine as a business, right, you're actually more locked in there than what you would have expected if you had adopted a more flexible platform. Alright. So next, I'm talking about this has just becomes a momentum killer. Right? Staff is taking increasing times in your implementation is done. Right? You're still taking a lot of time building records. The fundraising staffs, not the IT staff, but the fundraising staff gets sucked into system design and fix it, which they probably never thought they would do and are not that interested in doing. Reports are, and I'm gonna put in quotations, wrong, and data has to be triple checked. And I'm putting that in quotations because probably the reports are not wrong. How the report was built was wrong. But who cares? You can't trust it. Triple check data is still wrong. Donors notice and they get frustrated and mad. We definitely don't want that. And suddenly everyone is using their own spreadsheet and data becomes siloed. And the whole point of having the CRM goes away. So this is, right, the saddest outcome and it just really happens often. This is the other part, and this is the part that actually, I started really talking about at the beginning of sales when I was working on a generic c r well, with customers who were considering generic CRMs, which is are you considering maintenance? Because I think what is really hard to understand, and I think especially if you're an executive who is old like I am and you used to buy your Microsoft Word in a box and then it was yours forever, is that when we're creating software on the platform, we don't own anything forever, but we do own the cost. So if there's a decision to customize normal functions, you own it. So if something needs to be changed, something breaks, that becomes the nonprofit's responsibility. If you cut training in favor of functionality, you cannot rely on product documentation. Right? You have to have your own trainers and your own training or you have to have a partner do it for you who understands who built your system because you did everything different from everyone else. And right? If you move from one generic CRM to that same generic CRM with someone else with somewhere else, it behaves differently. So you don't you're not able to get that sort of everybody uses it this way and we know how to use it. Everyone cuts their documentation. Right? And then you don't have a way to go back. And then often folks borrow from support and maintenance budget if they had it at all towards their implementation. Right? And then if people quit, if something breaks, if new functionality comes online, you as an organization don't have a way to understand any of that because you don't have the money to purchase that support. So very, very hard and sad even if you had a perfect implementation and things started out exactly the way you wanted them. Alright this is a technical debt slide. You all are getting this, I'm not going to read this out to you, but what I want to hit the headline here that decisions in terms of what platform you use and your implementation decisions become expensive maintenance decisions later. So if you cut training, if you're relying on folks who it was me. It was me who suddenly said, you know, this technology stuff is kinda fun. It's like a puzzle. I can do it. I'm an accidental admin, and I built something that totally is not stable. Until I learned to be an architect. But right at the beginning, you know, helped organizations by creating really unstable environments for them, and I I regret that a lot. Right? So so you put yourself in a place where you are really reliant on the people who understand the system and they may move on. And then you don't have a way to understand your customizations. You were put in a third party situation where is it one or two of your third party apps? Is it your customization or is it the platform itself that is broken? And unfortunately, the person the organization, you the person who has to resolve that right in the middle, it's you. It can be very, very taxing. And then, of course, your board and execs might not understand. So we are creating platforms that folks can't repair or use. And, unfortunately, when we do that, it is the organization itself who has to who has to pay for that. Alright. Alright. So this is a real new question. I would love to know if you are really having trouble with your current CRM, what would you be doing for your organization with that time and treasure that your current CRM eats up right now? So what would you rather be doing? I'd love to hear. I think I saw the list and you all do some really good work. So I'd rather I'd really love to know what would you rather be doing than struggling with reports if you are at all. Alright. So I'm gonna talk about the better way. So this is again not about smart teams versus not smart teams or good decisions versus bad decisions. It's really about this operating model. Generic platforms, excuse me, can absolutely succeed if an organization has capacity to build and maintain what the fundraising team needs over the long term. And that really does mean a lot of time and treasure into governance, architecture discipline, documentation training and ongoing maintenance. But I'm just most nonprofits don't have that capacity permanently funded. And I think again, they would rather spend their time and their time and treasure on their mission. So this begins to feel like an obligation. Really we have to do data governance again. Oh, Soft credits are broken again. So ordinary fundraising work turns into a design problem, and the organization starts to accumulate that technical debt. So we have some symptoms, and I'll be interested if they are happening with you are. Fundraisers get pulled into their fixates, reports become debates. So if you've ever debated a report, I would love to hear that. Spreadsheets proliferate, and the system becomes harder to change safely over time because nobody knows how it's working in the first place. So what we mean by the better way isn't no flexibility. It's really thinking about the stable foundation and understanding what your core fundraising mechanics are. Are they built, supported, and consistent with the platform you're choosing? So that anything that is custom is really thoughtfully engaged in. Alright. So the first thing to do is to really ask yourself, do we have the time, money, infrastructure, and appetite for risk to build and maintain a custom fundraising system? That is what you are buying if you purchase a generic CRM with an overlay on it. And then I think, have we planned for the unhappy path? And what I mean by that is you can say, okay. I've talked to you. We're choosing this generic CRM, this commercial CRM. We know what our license costs are going to be, and they have given us an estimate and a range for implementation. Have you thought what if the implementation costs more than that? And have you even more, thought like, okay. It could cost in that high level, and have we communicated that with our board, and do we have contingency plans? Have we put contingency on our on our budget? I I used to do this webinar called your budget is not your estimate. Right? Make sure your budget is bigger than your estimates so that you have so that you can make wiser decisions, right, if something comes up, which it will. Are you thinking about enabling fundraising work? So do you if your fundraisers are the folks who you think are gonna build your generic system, really think about that. Do you and your staff have time and talent to design, build, document, maintain the system, and train for operational resilience on your own? If you don't, then really do think about, okay, we need a purpose built system so that we are doing less of that or we're only doing our integrations or we are only doing what's custom for us. Think about the money. Think about your full infrastructure that you have to support. So if you put all of your attention into fundraising operations and you're not thinking about your integrations and making sure those are healthy, you know, what'll happen is, right, fundraising operations are gonna go first and those integrations fall out and are not maintained as much as they should. So really think about the whole of what you're doing, not just, not just the the piece that seems, super yummy right now. And then really think about risk. Have you planned for that unhappy path, which I've already talked about, but it's really important. And what are the consequences if you go over budget? Okay. Really wanna evaluate what actually needs to be custom. So you wanna describe the work's impact without referencing that internal systems name just as an aside. So I did make it my business to move people from RE7 to Salesforce a long time ago. That was my job. And the number of times I rebuilt Salesforce NPSP to be exactly like our e seven is a little embarrassing. Right? And it was because we couldn't get past, like, what is actually the work outside the system versus what the system's doing right now. Really think about what is standard required or and truly unique for you all. So and I think I think one of the things I mean, this is true. Every organization has a really special mission run by really special people with within a really special environment. That is 100% true. What is not true is that your fundraising operations are vastly different from anyone else. I really believe that. So I had so many organizations who really felt like they were different and they were, but their operations and their system were pretty much like everyone else's. So really think what's standard and what should I expect to be standard and how do I ask about that? What is mandatory? What do we really have to have? And really think about the work flow more than the information. And just a, you know, a hint, tracking is not functionality. So if you say to me, I wanna track soft credits, I say, okay. We got that. If I'm on a commercial system, if you say, I want soft credits to be automated for these five ways, that's a different question and it makes your estimate better. Really think about would donors notice if the work that we're doing disappears in the system, right? If we're not doing X, Y or Z in the system, does it change our decision making? Does it hurt or help our donors? And any decisions we're making, what happens if staff turns over? And again, if you were doing a lot of customization and there's only one person who knows how it works and that person leaves, boy we're in trouble. So really avoid customizing foundational practices. And then there are things that truly are custom. I worked with an organization, this is super cool, they had to have, hardware with CRM fields in it that they could use out in the field in really rural areas and then upload via satellite to their generic CRM when they came to a city. Totally unique. Yes. That had to be custom, and that was a totally appropriate way, thing to do to customize that. So really, you know, think about that. They're fundraising just like everybody else. Okay. Think beyond your licensing costs and never ever ever buy licenses before you fully understand your implementation. So really think I really ask, can you offer a fixed price implementation? The answer probably, if it's a custom system, maybe no. Right? So and really think about that. Why is the answer no. What should I budget for maintenance costs? And believe believe it when people tell you it's more. You also want to think about what is it going to cost? This isn't even on here, but what is it going to cost for me to have someone who knows how to maintain a really custom system? I don't think it's a big secret, but, particular database administrators are expensive. Right? So I think many of my clients did not believe me when I gave them the range for what they should expect to pay a skilled Salesforce administrator. And then they were very sad when they hired someone who broke the system. And then really think about what documentation is included if I'm going to customize. Whose responsibility is it? Is it if something breaks? What sort of governance and training am I, the organization responsible for versus you, the implementer, or the vendor? And if we decide to build this custom, what should our cost considerations be if we change our minds? Right? So in really thinking in that discovery phase, what if we change our minds? What are the cost implications implications? There we go. Okay. Alright. So this summarizes everything we discussed. I really, you know, I think it's really worthwhile to sit through this list whether you consider Blackbaud or another platform. You know, what's there, what has to be designed and really think with your really think through your talking through your account executive and helping work with them to really help you understand what are you buying. Alright. So when fundraising is standard in the system, right, you end up with less time fixing and validating, faster stewardship, cleaner hands off, hands with gift ops, less technical debt, less dependence on single admin, safer growth and change over time. So buying a CRM is mind bogglingly hard because it is a really high stakes decision, right? It's more it costs more than anyone's house probably is going to ever cost. So really thinking about what are the fundraising fundamentals that we need as an organization and are they already built in is really important. So really have to say, right, better is not more buttons or more complexity. Better is a system that allows you to work well as an institution with those limitations that you have. And I, you know, I was, my first career was as a director in the theater and my set design teacher said to me once, you know, limitations are your friend. So if you think about that time, that treasure, that budget, that infrastructure and appetite for risk, those are your limitations and it's really important not to trick yourself into thinking that they aren't limitations. Alright, I am done with the part of my talking part. I would love to see it looks like there are some questions. I'll see if there are some questions. I think I can go do that. This is my first time. No questions yet. So if you have a question, have, you know, like I say, I've had experience building for nonprofits. I'm here at Blackbaud now. So if you have a question particular to your organization, I am absolutely happy to, answer it. One thing I'll add thank you, Jennifer. That that was great. One thing I'll add, I just opened up the poll for you guys. So it should be let's just say poll, I think, in your top right hand side of your screen with a little red dot. All that's saying is, hey. Would you like to learn a little bit more about Blackbaud Solutions? If you'd like to dig into some of the things that Jennifer is talking about, some of the differences between Blackbaud and Salesforce or Virtuos or what have you, whatever CRM that you are currently on, you can indicate that in that poll. And then, yes, we will take a couple minutes here and wait for some questions to come into the q and a. So feel free to put those in now. So one of the things that that I think folks, you know, sometimes sometimes think about is, right, how to get started. So is anyone thinking about switching CRMs right now? Alright, Jeff. I got one question that came in. So this person is on not sure what CRM, but they were they're wondering about the data migration process from their system to a new system, what that looks like. Yeah. I think that's actually, I think that's really important, and it again can be really, it can be a hard conversation. Right? Because I think at first, what you'll probably get is you'll get a statement of work that says we're going to move these objects. Right? You as an organization really need to think through, right, is that enough so that your estimate is complete. Right? So so, right, probably all of your constituents, probably a subset of your gift information, Some of, you know, your older information can maybe be, you know, kind of pushed into smaller fields and that sort of thing. But I think it's really important right now. If you were thinking about in the next five years, we're gonna move to a different CRM to think through what what are we gonna want to keep and why. So and I'll I'll give an example that the that data management can create big fights in the middle of implementation. Right? Everyone wants to keep going into sometimes some wise decision. You know, wise decisions aren't made because there's a sort of panic. So really thinking about what information are we using, what are we reporting on, what's important for our donors, and only move that. And if you have a hoarding tendency, I do I do I do, what if I need it later? I think the thing to really think about is you can keep the information if you need it later. So if you're on Salesforce right now and you're thinking about moving to Blackbaud, RNXT, or Blackbaud CRM, right, that information can be stored as tables, you can get to it. You just can't get to it easily. So thinking about, you know, at the press of a button. Right? So really thinking about what do we need for our business operations and to serve our donors. It's really important that conversations should happen right now. Right? And if you're thinking, we're not changing CRMs, it really is important to understand what data is important to you. Awesome. Thanks for answering that one. Looks like I'll just put that in the in the chat there. She's asking about the relationship between Blackbaud and Salesforce. Does Omedic allow them to integrate seamlessly? Do they sync both ways? So I guess she's asking about Oh, yeah. Oh, this is a fun yeah. This is super fun. So so and we work with the clients like this all the time here at Blackbaud, and I think Audra and I, I'll be interested in what, you know, what you all are doing. But, you know, if Salesforce is absolutely working for you in terms of programs or in terms of, you know, how you manage students. Awesome. Great. It does some things really, really well. Service Cloud. Does it great. Right? So if you want to say, hey. I want to use Blackbaud fund you know, Blackbaud CRM or ArianXt for fundraising because that's right for us, and we don't have to build a bunch of stuff on Salesforce to get the automations we need. No problem. Right? So you can use Omatic, BrightVind, Datalink, to move that information, back and forth, and it can it can be absolutely seamless. So if you want that, right, I really want to connect my fundraising to my programs and my results that are stored in Salesforce. No problem at all. There are ways to move that information. And if you're always know, if you're already using Omatic, all the better and we have other recommendations for that. Absolutely. Happy. I'm happy to help. And so this is and I will just say my approach is for everything is use best in class for all the things. Right? And then and then use your integrations to move that information back and forth. And, I mean, we're lucky. We're in the age of we're in the age of fabric and data cloud and data lakes. And AI really soon is gonna be able to do this too to kind of get that information at your fingertips even if it's not actually, like, in your CRM. So I think I think we're actually in a place where technologically as a world, we're gonna have more at our fingertips. Awesome. Well, I think that covers all our questions today. Jennifer, I wanna thank you for your time. Absolutely. We will around this here in the background so you guys can still technically ask any questions, but we will be gone from the stage. But, yeah, thank you, Jennifer, for for the great presentation. Again, few few things that are out there. You can schedule some time with, Sophie directly, via that link she put in the chat. There's that, poll, to indicate if you'd wanna learn a little bit more about, Blackbaud Solutions. Otherwise, I hope you all have a wonderful day, and thank you for your time. Thank you all, and thank you, Blake. Of course. Bye.