- Start with discovery, not demos. Get clear on your goals, problems, and stakeholders before you look at any software.
- Integrations come in different shapes. Decide which data needs a two-way sync and which can stay a nightly upload.
- Phase your integrations. A smaller first phase builds the momentum you need for the rest.
- Check your processes before you replace a system. Sometimes the CRM isn’t the problem.
- Adoption needs owners. Name your subject matter experts and stakeholders.
Evaluating software, connecting systems, and deciding whether to fix or replace what you have are decisions a nonprofit team has to make. If you’ve ever sat through a demo and wondered whether it would solve your actual problem, or inherited a set of tools that don’t talk to each other, this post is for you.
We recently brought two people who work in this world every day onto The Responsive Lab, our podcast on fundraising, technology, and nonprofit leadership. Scott Holthaus hosted a conversation with Dave Malda, Chief Partnership Officer at iPass, and Mark Becker, founding partner of Cathexis Partners. They covered how to evaluate software, how to think about integrations, when to connect and when to start over, and why adoption goes sideways. Here is what we took from it about building a healthy nonprofit tech ecosystem.
You can watch the video of their discussion here:
Start Your Nonprofit Tech Ecosystem Evaluation With Discovery, Not Demos
The place to begin is with your own team.
Mark said it directly: “It’s gotta start with discovery and not demos.”
Get clear on your goals and problems
Before you get serious about looking at software, you need to know:
- What your goals are
- What problems you’re having
- Where your team spends (and wastes) its time
Then bring in every stakeholder. Gather requirements together and talk through what is currently working and what isn’t. Only after that does it make sense to figure out the right solution.
Let your direction shape the demo
Letting a demo set your direction is a poor way to start. Decide where you’re headed first. Then you can decide which rocks to turn over and which doors to knock on.
Skipping discovery has a cost. If you gloss over it, you may set the wrong expectations or miss a nuanced piece that deserves a closer look.
What Nonprofits Now Ask For in a Software Evaluation
The questions teams bring to an evaluation have changed. Three themes came up in our conversation.
1. AI and automation
Teams want software that tees things up and walks them through a process. The goal is to streamline day-to-day work and remove unnecessary tasks from the day-to-day work of supporting the mission.
A line from Nathan Chappell at Virtuous is worth repeating here: just because you can do something with AI doesn’t mean you should.
2. APIs and modern technology
Older systems create friction. Whether it’s an ERP, an accounting package, or a CRM, a system built on older technology can make data flows a little more cumbersome and a little more manual.
Newer technology with APIs gives you something to lean on. When a nonprofit uses Virtuous CRM+, for example, a middleware partner can use its APIs and an integration that is already built. That part of the project gets much simpler.
3. Best-in-class point solutions
Ten or fifteen years ago, teams often felt they had to compromise and choose one system to rule them all, because the integrations weren’t there. APIs have opened that up.
Now you can choose the best-in-class point solution for a specific job and feed it into the right CRM. That supports automation, makes people’s jobs easier, and gets you the reports you need.
How to Design Integrations Around What You Need
Software websites talk about integrating with everything, and there are different types of integration, each with different capabilities. Some are one-way. Some are two-way. Some systems talk to each other, while others simply work alongside one another.
The way through that spectrum is the same as before: discovery.
Map the process first
Sit with the people involved and ask:
- Who is involved, and who touches which system?
- When does the data need to move?
- What does it need to look like when it gets there?
- Does it need to go both ways, as constituent data and addresses often do?
Separate the must-haves from the wish list
People often arrive wanting every integration, with the kitchen sink thrown in. Once you peel it back and talk it through, the list usually gets shorter.
A few examples of what that can look like:
- A nightly or weekly file upload might be fine to leave as it is, even if stakeholders first said they wanted it integrated.
- An address update that currently takes extra manual steps might call for a two-way sync, so a change in either system updates both.
- A one-way sync might need to become bi-directional.
- One need might call for a brand new integration that has to be built.
The pattern is that your real priority list tends to hold fewer items than your first draft.
Phase the work
Once you know your priorities, put them in order. Phase one might include a few integrations, and the rest can roll out over the following eight to twelve months.
Smaller beginnings pay off later. In Dave’s words, “not taking too much on in the beginning allows you for some success at the end.” Your team sees a win, gets energized, and is ready for the next integration.
Connect What You Have or Start Over?
When a tech ecosystem frustrates a team, rip-and-replace can feel like the obvious fix. Sometimes it is the right call. Sometimes it isn’t, and these are the signals to look for.
When connecting is the better call
If your systems are capable and working for you, connect them and make sure the data flows so you can see the full picture.
Frustration with a CRM can also come from somewhere else. When you dig in, the cause is often that your other point solutions aren’t talking to it. Getting them connected can solve the problem you thought required a new system.
When it’s time to move on
If the real issue is how a system handles households, relationships, communications, or automation, connecting more tools around it won’t fix it.
Where partners fit
Integration partners can describe what your options would look like. They can show how your project changes if you stay with your current tech stack, or if you move one or two things to a more modern platform. For the rip-and-replace decision itself, an integration partner would lean on a technology consultant. Partners can also help lay the groundwork on cost and other factors.
Why Adoption Goes Sideways (Even When the Software Is Fine)
The software is only part of a nonprofit tech ecosystem. The process around it carries the rest.
Here is where adoption most often stalls.
Skipping change management and ownership
Name subject matter experts, the go-to people for different parts of your system, and make sure ownership is clear. Plan for regular maintenance, like de-duping. You take care of your car to keep it running, and your systems need the same attention.
Missing stakeholder buy-in
Without buy-in from the right people, two things can happen. First, you may not get the information you need about where important data lives. Someone who isn’t invested can say the data is in the CRM somewhere, or in the accounting system somewhere, and the devil really is in the details of where.
Second, if a team buys an integration and no stakeholder at the organization owns it, it can take a very long time to launch or never launch at all.
Taking on too much at once
Years ago, one organization wanted twelve integrations. That was boiling the ocean. A better approach is to put some water in a pan, get it boiling, and then move to the next one. The team sees success quickly and gets excited about the next integration.
A First Step You Can Take This Week
If your technology isn’t working for you, a short list is enough to get moving:
- The one task that takes too long
- The one place you enter the same information more than once (or every place you do)
- The one report you can’t get reliably, or the reports where different people get different numbers
- The one spreadsheet or workaround you can’t operate without
Then ask your coworkers to do the same. Combine the lists, and you have the start of your requirements. You may also find your team has been putting up with, and wasting, way too much time.
The other half of the first step is to bring those pain points to a conversation with someone who will ask good discovery questions. Begin with what’s hurting, and let that drive which systems need to be connected.
Putting Your Nonprofit Tech Ecosystem Into Practice
A strong nonprofit tech ecosystem starts with knowing your own problems. Discovery comes before demos. Integrations work best when you prioritize and phase them. Connecting capable systems can be the better call, and when starting over is the right call, your processes deserve a look first. After you choose your tools, ownership and buy-in keep them working.
If you’re ready to see how a connected CRM can anchor your tech stack, Get a demo of Virtuous CRM+.
FAQs
Where should a nonprofit start when evaluating new software?
Start with discovery. Define your goals, the problems you’re having, and where your team loses time, and involve every stakeholder before you look at demos.
What is the difference between a one-way and a two-way integration?
A one-way sync moves data in one direction. In a two-way (bi-directional) sync, a change in either system updates both, which matters for data like constituent addresses.
Do all my systems need to be integrated?
No. Once teams talk through priorities, the list of needed integrations usually shrinks, and some processes, like a nightly file upload, can stay as they are.
When should a nonprofit replace its CRM instead of connecting its tools?
If your systems are capable, connect them. Consider moving on when the CRM itself falls short on how it handles households, relationships, communications, or automation.
Why do software adoptions fail even when the tool is good?
Common causes are skipping change management, lacking designated owners, missing stakeholder buy-in, neglecting regular maintenance, and taking on too many integrations at once.
