Welcome to part three of “Everyone’s database sucks.” If you haven’t caught parts one or two, you might want to check them out to see the framework for this series and to first think through misguided perceptions about your database can cause issues, and what people you need in place to manage a database.

In this piece, we will move onto the third—and most overlooked—roadblock to a flourishing database: processes.


Setting your organization up for success involves not just “what you do” but also “how you do it.” This is as true for databases as it is for anything else. One very common theme that I see among clients is trouble correctly discerning how they should be doing something. Leadership doesn’t give any direction, end users don’t have any clue, and administrators don’t have any authority . . . so everyone just starts doing whatever they think is right.

It’s important, however, to take the time to think about how your database functions—what is going into it, what is coming out of it, how is it serving your needs—and then thoughtfully setting database processes to ensure a useful database. Without taking the time to do this, your database might suck.

You should think through each of these process topics: do we have these issues? Is this written down? Understood?


Data entry matters. “Garbage in, garbage out,” as they say. If you’ve invested in having and maintaining a database, don’t let it be garbage. Be thoughtful about what’s in there.

Uniformity in how and why data is entered is key. Here are a couple of guidelines:

Before you start moving massive amounts of data into the database, take the time to figure out what changes need to be implemented to the database and what processes need to be put into place to ensure that good data goes in. And that admins aren’t stuck endlessly cleaning up messes.

Hard and Soft Credits matter—and should be simple. Everyone makes this more complicated than it needs to be, but it is something you want to get right, and then maintain consistently.

In most cases, no one thinks of hard or soft credits because they are generally never split. If John Smith gives $100, you thank him, steward him, and life goes on. No consideration of “hard” or “soft” crediting whatsoever. The confusion comes in when someone gives through a different vehicle than their personal checkbook.

Let’s say John Smith has multiple vehicles through which he gives: He has a plumbing company from which he cuts an annual check. He also has a family foundation from which he directs money to you as well. And sometimes he just signs you his own check. Suddenly you have three different entities all giving different donations, but all connected to each other and the same donor.

Here are three rules to make hard and soft crediting easy.

  1. Rule #1: The Hard Credit is who the IRS cares about: Where the money literally left the bank. The plumbing company, the family foundation, etc. This entity gets the tax receipt.
  2. Rule #2: The Soft Credit is who you, the nonprofit, care about: Who directed the money, who you steward, who you maintain a relationship with. This entity gets the “thank you.”
  3. Rule #3: Don’t use them for anything else. Do not use hard or soft credits for anything more than this. Don’t use them for tributes. Don’t use them to recognize other donors that may have instigated or connected you to this gift. Don’t use them to partially credit members of a household.

Every system implements Hard and Soft Credits differently, but keeping your crediting process simple and effective is invaluable.

Grants management matters, too. Grants management is not the same as donation management. Don’t use the same process for both. Your donation process is to track individual transactions and gifts.

Grants management is more protracted, more involved. There’s the initial qualification process with letters of inquiry, proposals, and applications. Then there’s the decision, memorandum of understanding, acceptance letter, and disbursement. Then there’s the reporting and renewal phases. Unlike a donation, you are generally working on a grant for months and sometimes years. Sometimes there are multiple reports due. Many times the same grant has multiple disbursements over multiple months or years.

In other words, donation and grants management have different requirements and require different systems. To be clear: grants and donations are connected. A grant will have one, sometimes many donations. But they are not the same thing, and should not be managed identically in your database.


Integrations don’t always matter as much as you think. And they’re not always simple. Maybe more than any single area, integrations exemplify our worst instincts when it comes to setting up database processes. The desire to connect disparate systems without clear end goals and justification can lead to enormous issues like data duplication, partial data entry, and gaps in institutional knowledge.

As I said in part one of this series, not everything needs to be—or should be—integrated. Here are the five discerning questions to ask before you integrate:

  1. Why do you want these systems to share data?
  2. What data specifically do you want shared?
  3. What direction do you want the sharing to go?
  4. Who will fix the integration when it breaks?
  5. Is this integration scalable?

Justify every connection before diving in. If you are not careful you will create a Jenga tower of complexity just waiting for the weakest link to fail.

Automations: another solution you may not need. “Automate!” is another hand-wavy word that people use when they want to make things better and don’t want to put the work in to think through a process. Automations can be a useful, even integral, tool in your arsenal.

But they are not magic. And they are not always needed. If you have any structural or procedural problem currently, any new automation is only going to . . . well, automate your problems, too.

You’ve heard this one: “Don’t have enough money to pay your cable bill? Just setup autopay!” Gee, thanks. Why didn’t I think of that?

The same principle applies here: if you can’t “afford” something without an automation, then you can’t afford the automation. In other words, you should only use automations to scale processes that are proven successful when done manually. An automation provides speed and capacity. It automates an already existing manual task. It does not provide a magic ability to do something altogether new.

If you do decide you set up an automation, you also need to test that automation manually to review each step of they process before “pressing play” for everyone. Once automations are live, be ready to continue tweaking them as needed. Don’t just setup a new donor welcome series or donation payment receipt and then close the lid for the next 5 years.

As with all things database, “set it and forget it” is not the motto here.

Automations require regular attention. Your admins will be much more efficient if they aren’t sending out thousands of emails, but they will still need to be checking receivability, building segmentations, and fixing breaks that inevitably happen at any point in the sequence. The very worst thing you can believe is that automations remove the need for admin oversight.

Here’s the key insight about automations: Automations do not remove work. They change the work you do and increase capacity.


When confronted with problems that involve the database, it’s easy to confuse the database itself as the source of the problem. In reality, it may well be “us”—not the system. In other words, it’s how we are doing something that is really causing the issue, and the database merely makes it more obvious.

When creating a task or process, start in analog. Pretend that all you have is a pen and paper. How would you go about doing it? Once you know what you want, then bring the database in to accomplish that task rather than expecting inspiration to spring from within or forcing yourself to work within the constraints it presents.

These are only a few examples—what others can you think of? What sort of major problems or friction do you face with your data? Is it possible that some of the issues with the database are in your database processes? Share your thoughts in the comments!

This article is part three of a four-part series. You can read part one here, part two here, and part four here