What we learned
We pay for tools nobody uses
Many organizations have more tools than they use. The problem is almost never the tool: it's that nobody adopted it.

Edmundo SpohrJanuary 20, 2026 · 5 min read
In 30 seconds
- 01The challenge isn't installing a tool, it's getting the team to use it on Monday.
- 02Only switch tools if the new one fully replaces the old one.
- 03Before buying something new, teach your team to use what you already pay for.
Over the past year we talked with many foundations and nonprofits. In several of them, the same scene came up almost exactly: a tool bought with enthusiasm, set up with effort and, months later, forgotten. Nobody chose badly on purpose. The team simply kept working the way it always had.
At Sumadots we see this so often that we've stopped thinking of it as someone's mistake. It's a pattern. And like any pattern, you can see it coming.
Five organizations, the same story
We pulled together what we heard in five different organizations, of very different sizes and causes:
- A project management platform (to organize tasks and deadlines) that was paid for, while the team kept coordinating by email and chat.
- A large donor management system that ended up switched off, because it was far too big for what the organization needed.
- A mass email tool used to send the same message to everyone, without separating people by type.
- A full office suite that the leadership team never learned to use beyond the basics.
- AI licenses paid for every person, without anyone really knowing whether they were helping.
In none of the five cases was the tool bad. In all of them, the same thing was missing: a plan for people to actually use it in their everyday work.
Implementing is not the same as adopting
When an organization buys a tool, it usually thinks the work is done once it's installed and set up. That's when the real work begins. Installing is technical work. Adopting is human work: changing habits, answering small questions, showing that the new way saves time.
Implementing
- The tool is installed
- The accounts are created
- There was an initial training
- Measured by: is it ready?
Adopting
- The team uses it without being asked
- The old way is no longer used
- Questions get answered along the way
- Measured by: do they use it on Monday?
Most technology projects in nonprofits are planned only up to the left column. All the energy goes into choosing, buying and setting up. There's almost never time or budget left for the right column.
We see this again and again. If the new tool does 80% of what the old spreadsheet did, the team will keep using the spreadsheet for the other 20%. And before long, for everything else too. It makes sense: better to stick with what we know than to work in two places at once.
What we do differently
Over the years we've put together a few simple questions we ask before recommending or building anything. They're not technical. They're questions about people.
Before adding a tool
- 1
Name who will use it on Monday
Not the department or the job title: the actual person. If nobody comes to mind by name, it's not time to buy yet.
- 2
Check what you already pay for
Often the solution is a tool you already have that nobody learned to use well. Teaching costs less than switching.
- 3
Require a full replacement
If the new tool doesn't make the old one obsolete, you'll end up with two. Decide what gets switched off the day the new one starts.
- 4
Size it to your organization
A tool built for a company of a thousand people tends to swamp a team of ten. More features aren't better if nobody uses them.
- 5
Plan the first few weeks
Set aside time to support the team after launch: answer questions, adjust, remind. That's where adoption is won or lost.
AI licenses are a special case. They get bought for the whole team on the idea that everyone will figure out how to use them. What we see is that almost nobody figures it out alone. It works much better to choose one or two specific tasks, like summarizing meeting notes or drafting a first version of a report, and teach people to do them well.
Where to start this week
You don't need an audit to get started. An honest conversation with your team is enough. Make a list of the tools you pay for today and, next to each one, write down who really uses it and for what.
You'll probably find surprises: tools nobody opens, others used halfway and some that do the same thing. That list is your starting point. Before buying anything new, decide what to switch off and what to train people on.
And if you do add a tool, make it the smallest one that solves the real problem. You can always grow later. Backing out of something too big is much harder.

Edmundo Spohr
Applied AI, adoption and impact · Sumadots