Editor’s note: The final installment in our series comes from Karen Graham, Idealware’s Executive Director. She used one question as a jumping off point to talk about examples of how processes can affect your software purchase decisions. To get caught up on the whole series, read Eric Leland and Robert Weiner’s posts. Enjoy!
Can you recommend resources for setting policies/procedures for handling donor info, acknowledgement of gifts, reporting, etc.—especially as the guidelines impact selection of software?
I’m going to approach this question at a tangent because it brings to mind an important point about selecting technology.
When you’re selecting new data management software—whether it’s for donors, grantees, or some other type of constituent—it’s often a good time to review and improve your internal processes. Why? Because documenting existing processes helps you understand what you really need from a new software system.
I like to think about it this way: Your processes are real-life use cases that can help you evaluate products.
For example, when I was a consultant I worked with a community arts center that was looking for a donor management system that could handle online registrations for art classes. Sounds straightforward, right? When I talked with the woman who helped people register by phone, she explained that she was doing a lot more than just inputting data. Her process included looking up whether the registrant had any credits for past cancellations due to weather or instructor illness. She also had additional paperwork to fill out if the caller was registering on behalf of a child. As I learned more about the organization’s processes, it quickly became clear that the ability to handle these scenarios was going to be a big factor in choosing one system over another.
Here’s another example of processes informing purchase decisions.
I worked with a reproductive rights organization that identified gift acknowledgement as one of its most important tasks. In every vendor-led software demonstration, staffers asked to see this in detail. They asked questions such as: What if an online donation comes from an individual but we want to acknowledge the household for the gift? It was clear they needed to see the system in action. We set up “test drives” that allowed them to try out their top choices and made sure to structure those sessions around key use cases so that they can get an apple to apples comparison. And it worked! Staffers were happy with their choice and the system met their needs.
One reason to review processes before choosing software is that you might uncover processes that just don’t work.
Organizations that evaluate several software packages and struggle to find one that fits well with their processes should recognize that as a red flag. Do your processes really need to be so unique? Process improvement often goes hand-in-hand with a software conversion. If you can be flexible enough to follow a more typical process, you can significantly reduce your need for customization. Minimizing customization not only saves you money in the implementation phase, but it also makes it easier for your staff to take advantage of vendor-provided training and support, helps new staff to learn the system, and keeps you on a smooth upgrade path with fewer potential glitches when system changes get rolled out.
Then, once you’ve thought about your processes, it’s important that you find a way to institutionalize the ones that work.
One grassroots organizing group I worked with chose to supplement a vendor-provided user manual with its own data entry standards and internal procedures. These internal documents specified which method was used for linking household members, whether to use Street or St, and how often to run pledge reminders, among other things. Creating its own version of the user manual took time, but it also helped the organization achieve broader and more consistent user adoption.
But to answer the original question, here are a few policy/procedure resources out there on the web. Everything we found was created by a vendor and, as an independent voice that takes care to protect ourselves and our audience from bias, we generally we don’t like to link to vendor content. However, in this case, the content is solid and we didn’t want to leave you without anything. Together, these examples give you a good sense of what you’ll need to include in a document that provides guidelines for how to handle donor data. Best of luck!