Almost no nonprofit works alone. A youth program refers kids to a health provider. A foundation supporting athletes has to stay in step with the governing bodies that certify them. A housing organization shares client status with a county agency and two service partners. In every one of those relationships information has to cross from one organization to another, and in nearly every one of them it crosses as a spreadsheet attached to an email.
You know the rhythm. The file goes out on Friday. The partner opens it Monday, fills in their columns, sends it back Wednesday. By then you've enrolled three more people and changed two statuses, so the two files no longer agree. Someone reconciles them. The reconciled version goes out again. After a few rounds nobody is sure which one is current, so both sides quietly keep their own.
I understand exactly why this is the default, and I don't think anyone should feel bad about it. A shared spreadsheet needs no agreement, no budget and no technical staff. It works on day one. The alternative, a direct connection between the two organizations' systems, needs things most nonprofits of this size simply don't have lying around.
It needs someone who can sit down with the partner's technical team and understand how their system lets data in and out. It needs an agreement about which fields mean what, who owns which record, and what happens when the two sides disagree. It needs someone to actually build the connection, test it, and keep it working when either side changes software. And it needs the relationship handled well the whole way through, because you're asking the partner to spend time on a project that mostly helps you.
That last part is the one that kills it. You need one person who can hold the relationship conversation and the technical conversation at the same time. Most organizations don't have that person, so the spreadsheet stays.
Shane at American Paragons said something about this that has stuck with me. When we went and got the foundation direct API access with its partner organizations, sitting down with their technical teams and working through their requirements, he said those integrations were the kind of thing most small nonprofits never get, precisely because there's no one to hold both conversations. I'd add that most partners have been waiting for someone to suggest it. They're sending spreadsheets too.
The cost of the spreadsheet is partly the hours. Preparing, sending, reconciling, chasing. Multiply by the number of partners and how often the file moves and it's a real, recurring, invisible slice of a coordinator's week.
The cost I think about more is the person in the middle of it. When two organizations hold different versions of someone's status, that someone can fall through the gap. An eligibility change one side recorded and the other hasn't received yet is a service delayed or refused. A referral that lives in an email thread instead of a system is a referral that can just be forgotten. These failures make no noise. They don't show up in any report, because the report is built from the same spreadsheet that missed them.
There's also the awkward question of what's actually in those files. Personal information about participants, moving through email between organizations, is precisely the kind of thing funders, auditors and privacy rules are asking harder questions about every year.
None of this requires anything exotic. Connecting two organizations' systems is ordinary work; commercial companies do it constantly. What makes it rare in the nonprofit world is the absence of anyone to do it, plus a belief that it must be expensive.
In practice it comes down to four things. A conversation with the partner's technical people about how their system can send and receive records, which nearly every modern system can in some form. A shared definition of the data: which fields, in what format, with which organization treated as the owner of each. A built connection that moves records automatically when they change, both ways where it matters, and keeps a log so either side can check what moved. And a person responsible for it over time, because both systems will change.
Once it exists, the coordinator stops sending files. Athlete records, program participation, eligibility, whatever the shared data is, stays in step between the two organizations without anyone doing anything. Questions from the partner get answered by looking at the system rather than hunting for the latest version. And the person in the middle is seen the same way by both sides at the same time, which is the whole point.
If you want to start somewhere, start with whichever partner the spreadsheet moves to most often. Before any technical talk, write down on one page what's in the file, who touches it on each side, how often it goes back and forth, and how many versions currently exist. That page is enough to have a real conversation with the partner about doing it differently. In my experience they say yes faster than you'd expect.