Welcome to TechSoup Talks. This webinar is finding the perfect donor database in an imperfect world. My name is Kami Griffiths, and we'd like to thank ReadyTalk for sponsoring this webinar series. And I'd also like to welcome Robert Weiner and Tracy Crosack. I'd like to have you introduce yourself and tell us a little bit about your organization. So Robert. Hi everyone. This is Robert Weiner. Kami, can you hear me? Yes, I'm loud and clear. So I'm a technology consultant and focus on donor management, donor databases, member databases, etc., and also the fundraising back office, which is often called development services or development operations or advancement services, depending upon the organization. And those are the people responsible for the business processes that support the database. And I've been in this field for about 25 years and on my own as a consultant for the last eight or nine years. Well, thank you so much. And for those of you who are new to this topic, Robert is quite the expert in databases and we're really lucky to have him here. And Tracy, can you introduce yourself? Sure. You can hear me okay? Yep. Terrific. I'm Tracy Cronvac. I am the Technology Manager at the Applied Research Center in Oakland, California. In interest of full disclosure, I actually did work with Robert on one of our database searches, and we'll get to that a little later on in the presentation. But I have been in this position about three and a half years now, and I've seen this organization through two database searches and a major technology transition. So I'm really here today to share from some of my experience going through this process and also some of my observations having gone through this process in an organization in itself undergoing a great deal of change. Well, thank you so much for taking time to join us. And I'd also like to thank Becky Wiegand who is answering chat questions. If you have any issues with Freddie Talk or have any questions, send them via the chat and Becky will help you out. So just to quickly go over the agenda today, we're going to first start out by talking about why we're here, and when is a good time to change your database and what it'll cost, how to choose, and then surviving the conversion. So I'd like to get started by asking, why are we here today? Robert? So we're here, I love this quote from John Kenyon who is a local San Francisco-based nonprofit technology consultant, that after people, data is your most important resource. It's very difficult these days to operate an organization of any degree of sophistication without access to good data. And data is your institution's long-term memory. Otherwise when staff leave, when staff retire, when staff get promoted to new positions, they take all that knowledge about your organization and your donors and your prospects and your supporters with them. And you don't want that to happen. You want that to be available to future staff.  And so what should people expect from a database? So I alluded to this in the previous slide. Your database should in general help you work smarter. And what that means will vary from organization to organization. If you are a fundraising organization, you should be able to track your income and who gave you that money and what it was restricted for if it's restricted and how you used it. It should let you monitor and forecast the performance of the organization. So you should, if you are a good database user, be able to say, well, based on historical trends or based on the initiatives we're launching this year, we raised X last year and we expect to raise X plus X percent or X minus X percent this year. And we are on track or we're not on track. And if we're not on track, how can we refine our work so that we get back on track? And then keep the people who care both internally and externally informed about what you're doing with the money you're raising and what you're doing with the money your donors are giving you.  And then in general to keep in touch with the people who are your supporters or who you would like to be your supporters in the future. Tracy, can you tell us when it's a good time to change? Sure. We came up with this list of points on when to change. And I was thinking about this last night even. The overall theme for us was when we needed to change, it was because our database had no longer become an asset but had become a liability to our business processes. So we were not able to get any sort of coherent viewpoint of the people who supported us and the people who really wanted to be engaged with us. So obviously that includes every single department that you could possibly work with, whether or not the development folks can actually get the reports they need in order to understand how fundraising is going and report back to funders and donors. When your data like it was in our case is spread out across the organization, there's no central repository for that and there's no ability for any staff member to be able to go in and share their experience based on working with that data. And particularly in smaller organizations I've seen this be a challenge and that is if one person is carrying all your data and that person has their own system set up and that information is exclusively in their head, that's a very difficult thing to enable organizational sharing. And one of the things that we did organizationally is we changed our mission and we changed our focus and ergo, we changed our constituents. So another choice that you might have or another decision you might have is whether or not you are changing your organization. And when you're looking at changing, we really had to come to terms with a lot of different constraints on our system. I think one of the things that you're going to hear through this is that you are going to look for the perfect database and there is no perfect database. But the ones that I really want to highlight off of here is that when you do make a change that is as fundamental to the structure and the information sharing as the databases to your organization, one of the things you want to be sure of is that everyone participates and has buy-in to that decision that when you have the moment to examine those databases you do everything in your power to compare them as most similarly as you can. So have your vendors go through the same demonstration scripts repeatedly. And also make sure you understand the true costs. And one of the things that organizations really grapple with is whether or not to have someone administer their database and how that person's job should be structured. So note that when you take on change, the principles of change tell you that there is really no perfect system and you are going to have to examine your organization not just in terms of its database but also in terms of its business processes and its internal efficiencies as you are using them. So Robyn I would like to throw it over to you and let's talk about how much it will cost. So the cost, and there were a lot of questions supplied by the people as they registered, by the attendees as they registered, a lot of questions about cost. And the cost is about as variable as you can possibly imagine. There are a number of systems that are free although some of them are free as in puppies. So you can get the software for free but there is then a lot of care and feeding required after you get the software to understand your business processes and implement those into the software and design reports and develop policies and procedures and train your staff. So there are a lot of hidden costs that are not simply software. But there are some really nice free or very inexpensive databases. And at the end there is a resource slide with a link to an Idealware Report examining 30 plus inexpensive donor databases as they defined them which was I think under $4,250 for the first user for the first year. So there are a lot of systems in that price range. In addition to software you are going to need unless you have online software where the vendor is providing the hardware you are likely to need hardware. Even if the vendor is supporting the software you are going to need some kind of hardware yourself to access the database from. So you are going to need desktop computers or laptops or netbooks or iPhones or something in order to have access to your data. So the price starts at zero and I have a lot of clients who have spent more than a million dollars on their database but there are a lot of excellent excellent systems in the market for well under $5,000 aimed at small nonprofits. In addition to the price to buy and implement the database you have to count on annual ongoing support of the database. And generally you are going to be spending something on the order of approximately 20% of the retail price of the software and that is the last bullet here. It varies from company to company and some companies particularly if they have a free database 20% of free is still free. But for a product that you pay for generally you are going to pay for ongoing support and not doing this is really playing Russian roulette with your database because if anything goes wrong at the software level you are not going to have access to anybody to fix it for you. Now a lot of vendors will take pity on you. Some vendors have a program where you can pay all of the back support for however many years you skipped it and get current but that can be a catastrophic expense. So I strongly recommend paying for the ongoing support and if you can't afford the ongoing support of the database or to train your staff and training is an ongoing expense. You are going to have new staff and databases in general will have new capabilities you will need to learn. If you can't afford the maintenance and the support you should not be using that database. Then there are also some hidden costs here in addition to the ones I mentioned on the previous slide. The middle bullet here is your own staff time and a lot of organizations don't take their own staff time seriously as a cost but it can be a significant cost. You may be taking a staff person out of their regular job for some period of time or taking out at least some big portion of their regular job in order to support the database conversion and perhaps the ongoing support of the database. So you need to consider that as well. So here is a sample budget for a system costing $5,000 in the first year for the software itself. And this could be $5,000 divided in 12 payments because it's an online system or $5,000 because it's a purchase of software that you install on your own servers. And so I put in a budget line here. And this is a made up budget but it's pretty realistic in my experience. So I put in time for training five staff people. Some vendors include that in the cost. Some vendors don't. I assume that you would have to buy or upgrade workstations for those staff. I assume that you'll probably need a new printer because you'll be printing all of these brand new reports. That's not a big part of the cost. I assumed 20 hours of consulting in order to convert your data and help you develop business rules and reports, etc. And then I assumed ongoing support. So this is really actually based on a single purchase of a $5,000 product as opposed to an online system where you're paying monthly. So the support is 20% a year over the course of the next four years totaling out $4,000 ongoing training as you have staff turnover and workstation upgrades somewhere within those five years. So at the end of those five years in this sample budget you've spent almost $30,000 on this $5,000 piece of software. So you need to consider all of the costs when you go into this. And I didn't put anything for staff time here because it is often a hidden cost and I have no idea how much you pay the person who would be supporting this. But it's definitely something to keep in mind. So let's move on and talk about the steps to buying a database. So we're going to cover all of these steps as we go through this presentation. But these are the big high-level steps and each of these break down into lots of sub-steps. But the first step is who should be making the decision, getting the right people involved in making that decision. And then the second is deciding what it is you need and what are your top priorities and which of those priorities are mandatory. And then somehow identifying a pool of vendors and an RFP, a request for proposals or a request for information are pretty common ways to do that but there are many other approaches to doing this. And then how do you test the vendors to make sure that they can actually do what you've asked them to do in your list of top priorities? And then getting a detailed proposal so you understand all those costs that we were just talking about. So the first step really in this process is to convene your team. And frankly, this is something that I've noticed in my experience now going through a couple of searches is more, it's almost equal parts are in science. And I think that the real salient point of this is something I mentioned earlier and that is that your team are going to be the people who are going to help you move this system throughout your organization. So it can't really be, even though it's very tempting to have the most technically savvy person be the team leader, decision maker, and evaluator for the whole process. In fact, what you really need to make sure is that that technical person who may be approaching your database search from an extraordinarily informed perspective on technology is going to be able to get real feedback from people in your organization who are going to be doing it every day in the system. So one of the decision-making processes that I've noticed is that you'll come across really unexpected allies in this process and folks whom will say the most insightful things simply because they're not the team leader on the database search and have to actually work with it every day. And that kind of gets into the question of what do you need to bring your team to a point of understanding where you want to move. So the thing that I want to highlight from this slide is obviously one of the introspection that you'll need to accomplish is an examination of your business processes now. And all the points where you're feeling pain and all the points where you would like to see change. But the point on here that asks what do you really need actually speaks more to a question of priorities for your organization. One of the things that you will need to do is make a sheet of things that are absolute must-haves, things that are things that would be nice to have but not necessary, and things that are simply for your intents and purposes bells and whistles on a database system. And I think it's really easy to get involved with vendor demonstrations and they will show you a lot of cool stuff because it is really the point of your vendor demo to help make a sale for that organization. And it's returning to your priorities and continually asking what do you really need and what are our original goals to come out of this search are really the most salient points. And one of those priorities may very well be what you can afford because we were certainly faced with a choice of a $300,000 database that would have done everything we needed right out of our box. And that was just not a good financial decision for us. So I just wanted to show you quickly one of the frames that you can sort of consider to help you prioritize your needs. And every member of your team should fill these out so that when you pull them together there is a common understanding of these are the things that we absolutely must have in our system. And this is one sort of illustrative tool to help you get to that point. And this is just an example. These may not be criteria that are important to you at all so they might not even be on your list to begin with. It could be that a few of these are. And this comes from End Powers Guide to Selecting Donor Management Software. For me, a 10 means we cannot live without this one feature. If the database could do absolutely everything else on our list but it couldn't do this one thing, we could not use it. For instance, MAC support might be one of your deal breakers. And if the system can't support a MAC, it doesn't matter how good it is at everything else. So the deal breakers should be a small subset of the total, but you have to know what those are. Tracy, anything more on this slide? Nope, I think we can go on to the next slide. Great. So the next step after you know what you're looking for is to identify a pool of vendors who look like they can meet those requirements. And there are a lot of different approaches to those. I talked earlier about requests for proposals and we'll get to that in a moment. The easiest way to do this is to ask similar organizations. So if you have allied organizations who you are connected with who do similar types of work, that's a great place to start. You need to make sure that they are comparable organizations though. So it doesn't do you any good to be a little three person office and find out what your local Red Cross headquarters is using unless you're of a comparable size. You can also ask on general purpose forums like TechSoup, Charity Channel which is now a fee-based forum. It didn't used to be, but they have a lot of different listservs for different kinds of nonprofits. And then there's one called the Information Systems Forum which is a listserv for nonprofit techies. So ask around. The vendors ideally should have experience with your kind of organization meeting the kinds of needs you have unless you're willing to take a chance. Now it could be that no vendor or no vendor you can afford or trust can do what you're looking for. And so you might be willing to go with the vendor who says, well that will be in our next release or we will custom build that for you because we think it's important and of course they want your money. And you need to be willing to then work with them on that and pay them to do that. But ideally the vendor has what you want out of the box and they have experience meeting needs of organizations that are similar to yours. My goal is to have three demos. One demo is not enough to have any comparisons. And two really isn't enough of a comparison.  You just can't remember who the first vendor was despite taking notes which I strongly encourage you to do. So three maybe four is the magic number. Too many choices is a bad thing. It becomes overwhelming. It becomes hard to make a decision when you're faced with 30 or 300 if you're just starting out, starting your search. Too many choices you really need to narrow it down. And also avoid what I call demo fatigue which is just sitting through too many of these to the point where you can no longer think by the end. So a common first step is to issue a request for proposals. And I am skeptical of RFPs because a lot of them really don't get at the right issues and turn out to be big wastes of time for the organization and the vendors. But if you have very specific unambiguous questions that can be answered yes or no it can be a really good tool. So do you support Max? Yes or no? That's an unambiguous question. Can you process, and I've actually had clients who needed this, can you process donations in dollars, euros, pounds, and yen? If you need that, that is an unambiguous question. But not can your system track gifts. That is just way too vague. Every donor database can track gifts but they probably can't track gifts in the way you want gifts tracked. And then you need to spend the time reviewing those RFP responses and assigning scores to them so that you know who did the best. And again you need to know what your mandatory deal breakers are so if a vendor says no to one of them you eliminate them. But again I'm pretty skeptical of RFPs because it's easy for a vendor to say yes we do that but not mean at all what you meant when you asked the question. And leading when you are speaking with vendors in specific, the software demonstrations thing for us was so critical because what I really want folks to take away from this slide is comparing apples to apples and keeping it real. And to both of those points when you have time with a vendor that you've arrived at either through a letter of inquiry and an RFP process or through your own research, your script is going to help you make sure that every vendor you speak with absolutely touches upon all the points of importance to your organization. And what should be contained in that script are the things that are extremely important to your business process and operations every day. And when you're doing the demos you're going to have your team with you. When we did ours we had roughly five or six of us sitting around a computer monitor doing web demos. We weren't able to get in-person demos which is, you know, it's preferable to have someone there that you can speak with in real time but if you're not able to do that, web demos are also good. And I encourage people to stick with one path. So if you're doing them all in person, do them all in person. If you're doing them on the web, do them all on the web because that will give you the most objective kind of background to each of these. And encourage your staff to actually really ask the questions of like, well, when I'm processing a donation and I need to make a credit to one person but that person is affiliated with an organization that I also am getting a matching gift from, show me how you do this in your system. And I think show, don't tell is a very important principle for the vendor demos as well. And if you want to know your demo script really and truly is that opportunity. So here's a few examples of what you might want to conclude from your vendor demos. And those examples that you come up with for your organization, and one of the reasons why our team members are important is because they'll obviously give you your departmental kind of priorities in that area. When you hand the script to the demo, what you also will be able to do is create your own rating and comments on it for the staff who are watching the demo. And when you're doing this, everybody has a chance to sort of say, oh, I really liked how this system handled one or two or three different items, but I didn't like how it handled soft credits. I didn't like how events came in and were hard to sort of sort by. So it's really a pairing of both a script for your vendor and also an evaluation form based on your script for your team to use during those vendor demos that helps make them most successful when you're going back and trying to actually make a decision. So after you've gone through all of these demos, which you have graded, and that has allowed you ideally to identify the top one or two or possibly three, maybe the vendors all looked roughly comparable through the course of the demos, I think it's really important to get your hands on the software and really test it. And every vendor should be willing to give you access to a demo copy of the system. Some vendors actually do have troubles with this, but it's becoming more and more common for vendors to have a way of doing this for you. So some vendors will send you a CD or allow you to download a single user limited time copy of the system, but a lot of vendors, particularly those who have web-based systems, will give you access to a demo account. And essentially you are creating a mini version of that script that Tracy was talking about. So we need to get in and enter some constituents and link them together and add some gifts and add some gifts with soft credits and then design a report or run an existing report in the system. So you'll have a handful of things to test and those tests will be based on the role of the person who is on the committee. So someone doing gift entry would test gift entry. And someone who's a major gift officer would test filing contact reports and logging actions and logging a proposal. Someone an annual giving might segment a list. And it's hard to do these things when you haven't been trained. You don't have experience with the software, so you're going to be fumbling around. But that will tell you a lot about the usability of the system. Can someone with no experience and little or no training, the vendors might be willing to give you some training or be available to you as a help desk to answer questions. But how easy is it for you to figure out the basics of the system with that small amount of experience with it? And you should be grading those tests. So this is an example of a forum that's been around for I think a couple decades called the System Usability Scale. And it asks very straightforward questions. Like I think I would like to use this system frequently, agree, disagree. I thought the system was very easy to use, agree, disagree. That will tell you a lot about how likely your staff are to really use the system in real life. And then the last step in reviewing the vendors is reference checking. And the vendors should all give you a list of references. They will only give you happy clients. If they know their clients well enough, I have had vendors give my clients unhappy references, but that's pretty rare. So you also want to reach out, just like you did to identify the vendor pool, reach out to other organizations who weren't referred to you by the vendors and find out if they're using the software and how well they like it. Does the vendor meet their commitments? And do they do it on time and on budget? But one of the caveat I have at the bottom here is it can be difficult to distinguish client problems from vendor problems. And sometimes the problem is a bad client. They chose the wrong software or they didn't train their staff or they trained their staff 10 years ago, but those people no longer work there or they implemented incorrectly. And so their data is a mess and nobody's keeping it clean. So if you hear that pattern over and over again, it's probably a vendor problem. But if you hear it from one client, you need to keep checking because it may be a client problem. And sometimes it can be really useful to visit other clients that are using the software. If you're in an urban area and there are other organizations around that are comparable to you, it can be really helpful to go look over someone's shoulder and talk to them face-to-face about what it's really like to use the vendor. And you will instantly bond with them and build your own little user group assuming that you choose that software. And then the link at the bottom here is some sample reference check questions just as a starting point. So we've gone through all of the steps of reviewing the vendors. You know what you need. The vendors have shown you whether they can meet those needs. You've done some hands-on testing. You've talked to their references. And now we're down to where the rubber really meets the road. And I talked earlier about the cost that might go into this. Vendors will give you cost proposals at the beginning. And some vendors, their costs really don't vary. So their costs at the beginning of the process will be exactly the same as at the end. But a lot of the vendors will learn a lot about you as they go through the process of showing you the software and talking to you that will let them develop a detailed cost proposal that is truly informed by your needs. So some vendors sell by the module and you may not need all modules. Some vendors price based on the number of records you'll have. Some vendors price based on the number of users you'll have. Some vendors price a combination of all of those. You might need some third-party add-ins. In addition, you're going to have that ongoing support cost. You're going to have training. I think that it's incredibly valuable to have someone who has experienced with the database as your consultant. And I don't do this, so I'm not selling my own services here. But either the vendor or someone who specializes in that kind of software help you go through the conversion. And then you might need help interfacing your software with other pieces of software in the organization or that you're buying as part of the project. So you need to understand all of those costs. So how long this is going to take? It seems overwhelming, so can you break it down for us? Sure. It's funny, we're two-thirds of the way through the webinar and I want to shake people a little bit and say, you'll never be done.  And we've included some estimates what we've seen organizations of various sizes, how long it will realistically take to put your database into a business process and into your organization. But the thing that I really want to highlight in this process is plan for the unplanned. And what I mean by that is that for the folks who might be statisticians, I would say that while you're doing your database search, hold your database search as constant in all of the other processes in your organization, meaning don't try a database search when you're undergoing a strategic plan or don't try a database search when you're undergoing a management transition such as a very important development director or executive director because those things will actually change your priorities and viewpoints on a database and elongate the amount of time it will pragmatically take to implement it. So as much as you can, make your database search a discrete process with significant support from your organization's management in order to actually get it implemented and pushed out so that folks are using it comfortably within a reasonable amount of time. And then the other part of this and why I sort of said, oh, you'll never be done is because in fact when you adopt something as important to your organization's operation as a database system, you're going to have to remember that your users are going to need constant refreshers, little tips on how to do things better and more efficiently with your system, and systems in place for when staff matriculate and new staff come in to get them up to the same speed that your organization is currently working at with your new system. And that will help you both elongate the lifespan of your new system and also make sure that you have consistency of data going in and out of it through the lifespan that it has for you, be that three years or be that another five years. Robert, can you give us an overview, a summary? So this is where we've been. You're starting by getting the right people involved in making the decision, not just techies, and then prioritizing your needs and distinguishing the mandatory deal breakers from everything else and prioritizing everything else because some things will be almost mandatory but you could live without them if you had to. You need to understand the potential costs and then identify a pool of potential vendors who look like they can meet those top priorities and then go through the steps that we've just talked through to test those vendors against your needs coming down at the end to an actual in-depth cost estimate based on not just the software but what it's going to cost you to get live on the software and support it into the future. And the reason that we're here today isn't, this is not a tech talk. This is a management talk. Databases are management tools. The right database should be able to help you work smarter. It should be able to help you focus on the right prospects and understand who your donors are and what they give you and how they respond to different kinds of fundraising appeals. Are they online donors? Are they offline donors? Are they phone donors? Are they face-to-face donors? What level of support are they giving you? What level might they be prepared to give you in the future? If you're running an organization with multiple fundraisers this should help the management understand what their staff are actually doing and are they really talking to donors and are they really raising money. And then the ultimate goal of fundraising, asking the right person for the right gift at the right time for the right purpose. So if you can capture your data in a good usable database that everyone shares and has access to and can actually provide reports for you, you should be able to do everything that's on this list. Go ahead, Timmy. I was just asking you to tell us about this next part which is from my experience and people I know this can be a big challenge, surviving. I think the important thing to note here is to go all the way back to the beginning and that is you will be putting a lot of effort into finding the most perfect database for your needs bearing in mind that there is no perfect database. And if folks are familiar with sort of that age-old triangle of you can't have something that is done well, done cheaply, and done fast all at the same time. You have to pick two of those. And I think from our experience this also held true in a very similar way. And that is when you find a system there's always going to be some trade-offs that you're accepting when you achieve the system. And that might be that it needs customization. It might be that you need to invest a little bit more time into staff training. It might be that your adoption time and learning curve is either steeper or shallower depending upon the project. So this is a reminder to define your success when you start your project and say we're going to get as close to these top priorities as possible and try to meet them. And also remembering too that in fact that your database is your mission-driven tool. So another way of asking yourself your priorities is to say how well will this help us meet our mission if our database can accomplish X, Y, Z, or A, B, and C. And moving to sort of our organization's journey through this we struggled a great deal with this. And actually the first point on here is in 1998 we had a custom FileMaker database made for us. And it was really great. And going on almost 8 years later we had hit a point where our data simply wasn't connecting to anything else we were doing using this system. So we went through a search and we came up with a winner. And addressing a point that I made earlier we also concurrently went through a strategic planner on the same time that we were doing our database search. And we realized at the end of our strategic plan, hey, we're changing. Our needs are changing. This system that we thought would work so well for us isn't going to work at all. So finally this year we arrived in a new, new system which for us just as a point of reference turned out to be Salesforce. And in fact we've had to struggle with a lot of these questions of can we meet this mission-driven kind of agenda now with our new system? And we've finally arrived at a comfortable end. So for us this was a very prolonged process. If you look at it as a start to finish, it was 3 years. And we're still looking at another good year of getting our staff and users up and trained. My hope is that by sort of sharing some of this experience your search can be a little bit less than 3 years. And you can arrive at something sooner by taking sort of care around the parameters that you're building your search and the things going on organizationally that happens with it. So that would be one journey, albeit imperfect, but it is how we arrive to where we are today. And Robert, did you have anything you wanted to add before I moved to questions? I didn't. Okay, so we've got about 20 minutes for questions. We have a bunch that Becky has been saving up so we're going to just start. And these haven't been directed at anybody so either of you can jump in. Michelle has a question. Is there a correlation between campaign size and software cost? That's a really good question. In one of the earlier slides, and let me flip back to it on my computer, I had a rule of thumb about database cost. And my rule of thumb, and this is just a starting point, is that if you're paying for a database, it's going to cost roughly a quarter of a percent to a half a percent of the annual operating budget for the organization. So it's not based on campaign size. It's based on organizational size, which generally tells me a lot about organizational complexity. So an organization with a million dollar operating budget, that's what they spend, not what they raise, it's what they spend, is generally looking in the $2,500 to $5,000 range for a system. And you can add more zeros to all of those as your organizations get bigger. For campaign size, it's more a question of does it have the functionality that you need to manage a campaign, which is generally based around individual giving and large corporate and foundation asks. And can you track all of the steps involved in building that relationship, and who has the ball, and who's supposed to take the next step, and what did they say in response, and reminders to follow up, and also the ability to survive if the fundraiser who is managing that relationship leaves the organization before the ask is brought to a close, so that all of that data is recorded and can be shared with others. And if you are a team fundraising organization that everyone on the team is kept informed and you're not tripping over each other, you're stepping on each other's toes. So that's a general answer. I don't have a specific answer about a rule of thumb for campaign size. Okay. And I wanted to let folks know that we are streaming this webinar into Second Life. So I wanted to address the question that came in from Second Life. And I know this isn't a tool specific webinar. We're talking about the strategy, but there are lots of questions about some of the tools. And I wanted to talk about one or two of the free or open source databases that you know about. Tracy, do you want to hop on that? Tracy, I think you're muted. Well, I can speak for myself. I'm also the executive director of a nonprofit that is very, very small. And we are using Citi CRM. It's free. And our challenges have been training. I don't know how to use it. I don't know how to set it up. My web developer is a board member. And she set it up and she doesn't know what she's doing. So I'm looking for volunteers. And my staff is trying to get it to work. So we're kind of piecing it together and learning as we go along, but I think I'm missing a lot of opportunities. And I don't really know what all of the power that Citi has. But it also has this really great community of people and developers. So if you have the time and you have a techie staff person who's willing to put the pieces together, then I think you're in a pretty good position. That's the only one that I know. Kami, I dropped off for a second, but are we talking about Salesforce? We are talking about open source, free open source tools. And I talked about Citi CRM. So there was someone who wants to know some of the free tools that are out there. I would just say that one addition to all of this, and I missed the first couple of seconds of it, but we wound up with Salesforce which is also extensively a free system. And one of the things that there's actually interesting parallel with is the sort of build versus buy question that I saw a few people ask during the course of the questions. And I think any system really that you get into, but in my experience explicitly some of the freer and open source systems enable you to build so much into them that in some cases it actually becomes doubly important to be sure that what you're doing is actually related to your mission and not just building for the sake of building. So I can only return to the sort of axiom of free like puppies in some cases. And unfortunately where a lot of smaller budget organizations land is they wind up getting a puppy because the puppy came with not a lot of strings attached. I'm going to move on. On my website which is on the resources slide, rlwiner.com, I have a resources page there. And one of the resources is a link to a list of open source donor management systems. But like Tracy said and I said earlier, I think that they're free as in puppies. Okay. So a couple of questions I have to do about to do with interfacing software. Is it important for your packages to talk with your other pieces of software? Some of the things are should it talk to your website and what about it talking to your QuickBooks or your accounting systems? You know, I would actually turn that question around and say how important is it to your mission that it does these things? Because each one of those is a different layer of complexity that you're adding to your system and another requirement that you're putting on it. In our case it was extraordinarily important to our mission that we have a database system that can easily cull from our websites and easily cull through social networks. So that was a priority. It was less of a priority for us to have it interface with something like our organization's installation of QuickBooks. And frankly our accountant prefers that it doesn't because to keep that as a separate business process. So if you're going down this route I think the important things to ask when you're talking to vendors are do you have something called an API? And how accessible is it? Do you charge more for it? How easy is it to program with? And how many things have you made it play with so far? So it's important only to these things that it's important to your mission to have this. There are certainly ways of having your database be at your organization's workstations or hosted in the cloud as we like to say with something like Salesforce where it doesn't have to interface with every aspect of your organization. And there's interfacing and there's interfacing. So a lot of organizations are perfectly fine with an interface that is import-export. So you export the gifts out of your donor database and you import them into whatever your accounting system is and you do that once a day or once a week and that's perfectly fine. Although as Tracy said a lot of accountants prefer to manually enter all of their gifts. It's also a matter of volume. So if you're getting 10 gifts online a month it's pretty reasonable to enter those manually. If you're getting 1,000 gifts online a month you're not going to want to be entering those manually into your donor database. And you always introduce the possibility of mistakes every time you have to retype something. So in general it's worth avoiding but it's not worth spending tons of time or money to build an interface to something that hardly ever gets used. I just want to say I saw like 5 things come up on the chat that said API, API. So A as in Apple, P as in Paul, I as in Interface. But it's an acronym for I believe Application Portal Interface, is that correct? Programming Interface. Programming Interface, thank you. So that is just how programs that are either on your desktop or working online communicate with each other. In real time generally APIs are for almost instantaneous integration versus something that happens overnight or over a weekend. So I'm going to move on to the next question. We are very small. We are very small with a member database as a backend of our website. How does a donor database need to interact with the member database? So I think ideally, and this is related to the question about integration, ideally it's one database. I prefer to have all of the important constituents who you are cultivating or mailing or communicating with or inviting to your events in the same database unless the needs are so specific that they are simply incompatible. So if you need a system that can track people who attend classes and you need a whole class management system, it just might not be reasonable to expect your donor or member database to do that. But whatever reasonable I prefer to have one big database that is the Master Contact Management System. So I would try to find a member database that can handle donations or a donor database that can handle memberships. So there are a couple questions that have to do with advantages, disadvantages of software versus web-based tools, and the fact that some people aren't networked together and are using an online service is the only way for them to go if they are not currently networked. Could you address that? Robert, you want to jump in? Okay. This actually interfaces a little bit with one of the panels that I just spoke on at the nonprofit technology conference about cloud computing. The sort of idea that your database can sit somewhere not at your organization I think is a very appealing thing for what's becoming this new class of distributed organizations where everybody works in Seattle, Washington, D.C., Los Angeles, and Chicago. And those tools there are certainly, and really this is an entire other topic, but there are certainly questions about security and accessibility and the ability for people to feel confident that their data is getting backed up. But I think that they are particularly appealing to smaller organizations who can be much more nimble in making the jump to using a tool that doesn't require sitting on a server in the back part of somebody's office in your organization, and then taking on all of the sort of, you know, programming and kind of support that that engenders. So, you know, that's my little spiel on working in the cloud per se. And I will put this on the chat in just a moment. On my blog a year or maybe two years ago I posted a summary of best practices for hosted data. I think for small organizations generally I am very favorably inclined, particularly for small organizations, to hosted data because the vendors are in the business of managing servers, managing backups, managing the security of the database, whereas nonprofits generally aren't. And I see so many nonprofits that have had catastrophic data losses because they don't have anybody responsible for making sure the data gets backed up on a regular basis. So given that kind of choice I would entrust the data to a vendor. But you are taking a risk there that the vendor could, you know, I mean worst case go out of business, but even without going out of business that your internet connection or the vendor's internet connection could be down the day before your big event. So I always want some kind of backup access to my data if it's in the cloud. And definitely going to what Robert said about, you know, when I look at small organizations and I speak to them I think, you know, also there's so many things that are happening online right now, so quickly in terms of like new vendors and new organizations getting into the game. And the one word of caution I say is if you're looking at a cloud computing vendor, and I keep using that jargonistically but it means essentially, you know, somebody who's going to host your database for you that you would access through a web browser for example, you know, try to get a sense of how established that business is, try to get a sense of how long they've been around and who's recommending them and why because that will give you some sense as to whether or not they're going to be there three or four years from now. And don't be afraid to ask your vendor if you're considering one of them. So what's the exit strategy if you guys need to close doors? How do I get my information out of you as easily as I've hopefully put it into you? So I'm going to move on to a question about new orgs. What are the most common mistakes made by new organizations like new 501c3s that choose a database? Using Excel. Making your own. Using Excel and building your own. And let me just flip to the resources page real quick here. Let's see, on this slide the second to the last line is an article I wrote for N10 probably six years ago on why building your own donor database should be your last resort which means last resort. Don't do it under any circumstances but don't start out that way. And then something that's not on this slide is an article I wrote for Idealware a few months ago called something like friends don't let friends use Excel as their donor database. So those I think are the two most common mistakes and both those articles will go into a lot more detail about why those are mistakes. I also want to echo something we were talking about not too long ago and that is too, there's the phenomenon of my board member's niece or my board member's nephew or my executive director's cousin who is, you know, this person just got out of college. They're really tech savvy. They're maybe a programmer. They maybe know how to do stuff. And that's another organizational mistake that I see young organizations making and that is there is definitely an appropriate use of your volunteers when it comes to managing your data. But it's very hard if a volunteer comes in and creates a system for you that's so critical to your organization's mission. And then when a year's time that organization maybe, excuse me, the volunteer moves on and she or he may not be reachable if you have support questions or may not be reachable if you need to customize something further on it. So that's sort of another kind of sub-point to what Robert was talking about as far as building your own and that is it's really tempting to use those resources for that. But consider first your mission and I think you'll realize that the longevity of that investment as it relates to your mission is not necessarily very high in return. And the sustainability of whatever you're doing, you know, will you be able to keep this database running if the person who builds it moves on? Well, that is all the time we have for questions. And I apologize for those whose questions didn't get answered but we have a lot of great resources on these slides which again I'll be sending a follow-up message that has all of these links in it. And of course this one in particular. And then of course in the PowerPoint you can always open up and use the links here. And if you have additional questions and you want to post them to our community forums, here's the link. I'll be sending that in the post-event survey or sorry, post-event message. And if you're new to TechSoup, we have other things available to you than other than webinar so donated software, community forums, articles, blog posts, posting upcoming events. And we have another free webinar happening next Thursday, Social Media Listening Dashboard. Two really great speakers are presenting for us. And we'd like to thank ReadyTalk. This webinar is made possible by ReadyTalk which has donated the use of their system to help TechSoup expand awareness of technology throughout the nonprofit sector. ReadyTalk helps nonprofits and libraries in the U.S. and Canada reach geographically dispersed areas and increase collaboration through their audio conferencing and web conferencing services. So I want to thank everyone for participating today. And the presenters, thank you Robert and Tracy. This was really, really great information. I hope you all learned something new and come back to a future webinar and fill out our post-event survey. Thanks everyone. Thanks, Kami. Thanks for having us. Thank you, Kami. Thank you for the opportunity. Oh yes, this was fantastic. Appreciate it. Thank you. Bye-bye. Bye-bye. Thank you. Please stand by.