The next article in a series about why the strategies that used to work don’t work the same way anymore, and what that means for every decision you’re making right now.
Her name is Ruth. She has been coming to your organization for six years.
She buys four tickets a year, always to the same slot in the season, always with her sister. She gave $250 two Decembers ago, and $250 again last December. Her son took a summer class two years ago, the one where the kids build a set out of cardboard and put on a fifteen-minute show for their parents on the last Friday.
Three different kinds of transactions, with the same organization. Maybe they live in three different databases. Maybe they live in one. Either way, right now, nobody in your building can put them side by side and say: this is one relationship, and here is what it looks like in full.
Ask the ticketing system who Ruth is, and it will answer honestly, from what it holds: a buyer, with a purchase history and a seat preference. Ask the donor database, and it will answer honestly too: a name on a gift list, tracked for renewal. Ask whoever ran that summer class, and you’ll get a registration form filed away in a folder nobody has opened since August. Each answer is true. None of them is Ruth.
This isn’t only a database problem. It’s a strategy problem wearing a database problem’s clothes. Marketing segments ticket buyers by recency, frequency, and depth, but almost always only within performances: how many shows, how recently, how much spent. A giving officer looks at attendance when a donor sits inside a managed portfolio, but the annual fund program, running mail and email to everyone else, rarely varies its ask based on whether someone actually shows up. Education looks outside its own registration list only when marketing helps build a campaign around it, and even then it usually means sending one email to a segment of ticket buyers, not building a shared view of the person. Nobody owns the job of asking what Ruth’s whole pattern means, because the goals sitting above these teams are split by revenue line and program area, and the strategies underneath follow the same lines.
Even when all three of these transaction types already live inside the same CRM, that often isn’t enough on its own. Development teams commonly restrict who can see a donor’s giving history, meaning to protect the donor’s privacy. The side effect is that the box office and the education team can’t see it either, and lose the chance to treat Ruth as someone who has already shown the organization how much she cares.
None of this is a failure of anyone’s diligence. Nobody sat down and decided to keep Ruth in three pieces. The ticketing system was bought to sell tickets. The donor database was bought to track gifts. The class registration form was built by someone who needed twelve waivers signed by Thursday. Each system did its job. Joining them was never assigned to anyone, so it fell into the gap between departments, the way a lot of the most important things do.
Why This Comes Before the Measurement
Say you set out to measure whether your organization actually understands what audiences need from a ticket, or what donors need from a gift. You want real numbers, not guesses. You start listing what you’d have to track for one person: how well you understood their reasons for being there, whether they felt like they belonged, whether the ask matched what they’d already shown you they cared about.
You hit Ruth in the first week.
You cannot measure whether an organization understands a person if the organization cannot see the person. You can measure whether it understood the ticket buyer, and separately, whether it understood the donor, and separately again, whether it understood the class parent. But that isn’t what you set out to measure. You set out to find out whether Ruth feels known. Three fragments of Ruth, each one honestly served, do not add up to a person who feels known. They add up to three emails and two letters landing in her mailbox in the same week, each one certain it is the only one talking to her.
Skip this problem and build the measurement anyway, and every number you eventually produce will describe how well you served three strangers who happen to share a name. It will look precise. It won’t be true.
Transaction Records vs. Relationship Records
A transaction record is built to answer one question well: what happened, and when. It is very good at this. It can tell you, to the dollar and the day, everything Ruth has ever bought. Twenty years of complete, reliable, auditable transaction history is not a small thing. Most organizations have built exactly that, at real cost, over real time, and it works.
A relationship record answers a different question: who is this, and what do they mean to us. It doesn’t replace the transaction record. It sits above it, pulling the same facts into one place and adding the thing no transaction ever captures on its own: that the buyer, the donor, and the class parent are the same woman, and that the way she has shown up in each role tells you something true about what she wants from you.
An organization can hold flawless transaction records in three systems and still be unable to describe a single relationship. That is not a contradiction. It is what happens when three good tools are never asked to introduce themselves to each other.
The Five Questions
Here’s a more useful test than whether your systems can technically be joined. Pull one real person, someone you’re fairly sure has shown up in more than one part of your organization, and ask marketing, development, and education the same five questions about them, separately, without telling each team what the others said:
The five questions the record should be able to answer about one person:
- Every interaction they’ve ever had with us, in one place.
- Across every department and every system, not just the one we happen to be looking at.
- Over their whole history, not just this season.
- What we know they care about, based on what they’ve actually done.
- When we last heard from them, in their own words.
Watch what happens. Does any team attempt the holistic answer at all, or does each one answer only from its own list? If one does reach across, is it because you asked this week, or because it’s something they already do as a matter of daily practice? The gap between those two answers tells you more about your organization than the technical question ever will. A record that could be joined but never is has the same effect on Ruth as a record that can’t be joined at all.
What to Do If the Answer Is No
For most of you, at least one team will come up short. Sit with that for a second before you do anything about it. It is not a verdict on you or on the people who came before you. It is the ordinary result of buying good tools one at a time, over years, to solve the problem in front of whoever was hired at the time.
It is also, often, a story of turnover. Somewhere in your organization’s history there was probably someone who thought about Ruth as a whole person: who kept an informal cross-reference in a spreadsheet, or just carried it in their head because they’d been there long enough to remember her. Then they left for another job, and took the habit with them. Nothing had been written down. Nothing required the next person to keep doing it. The moment that one relational thinker walked out the door, everything reverted to whatever each system already tracked on its own.
This is not a technology purchase waiting on budget approval. The first version of a unified answer is almost never a system. It is a person, running a query by hand once a quarter, pulling three exports into one spreadsheet, and matching names and emails as best they can. It will be messy. It will miss people. It will be enough.
If your transactions already live inside one CRM, the work looks different but the principle is the same. It isn’t a query problem anymore. It’s a question for your revenue leaders: will you unify your reporting across the lines that currently keep it apart, and build one engagement strategy on top of the unified record instead of three separate ones? A unified database that nobody uses to think about Ruth as one person is no better than three separate ones. Let the tooling catch up to the habit, not the other way around.
Take these five questions into a conversation with whoever owns your systems, whether that’s an internal database administrator, a vendor, or an IT contractor. While you’re there, notice whose job it has ever been to think about Ruth specifically. Most databases are run by people who are excellent at the technical work: making a system move data quickly and accurately. Few of them are also asked to hold the relational work, the understanding that people are messy and inconsistent and don’t sort cleanly into the categories a system wants for them. That instinct is closer to what a good development officer or a good teacher already carries about people than it is to a technical skill. If nobody with that instinct has a seat at the table when your systems get built or bought, the systems will keep optimizing for the transaction and missing the relationship, no matter how good the technology is.
The Record Is Not Wrong
None of this is a case against your database. Your database is doing exactly what it was built to do: telling you how much money came in, and when. That is a real answer to a real question, and organizations need it to keep the lights on.
It is just not the question you actually care about when you think about Ruth. You do not lie awake wondering what her lifetime transaction total is. You wonder whether she will continue to transact. No one is asking if she feels like this place knows her, and what action they’ll take if they do. Somebody has to.
Next: Even a fully unified record only holds what your organization was in a position to observe. There is a layer of the relationship it cannot see at all, no matter how well you join the systems, because nobody ever asked Ruth directly. That is where we go next.
If your database couldn’t answer the five questions, the free Audience First Organizational Alignment Assessment will show you where else that gap reaches. It asks whether your systems capture and share audience insights across departments and whether your CRM can support sophisticated audience segmentation. It takes about 10 minutes, and your report arrives in your inbox as soon as you finish.
Leave a Reply