It's not the technology. That's the short answer, and we'll come back to it at the end. But when we're brought in to assess why a CRM isn't being used, why outcome reporting is still a fire drill, or why the system built by last year's student placement is now a mystery to everyone currently employed — the technology is rarely the actual problem.
The actual problems are sequencing, fit, and documentation. They happen in predictable patterns. Here are the four we see most often.
The four patterns
Tools that don't fit the budget
"Free for non-profits" is one of the more misleading phrases in tech marketing. The free tier is almost always designed to get the organization hooked — and it works, because the tool is genuinely useful at small scale. Then the team grows, or the grant ends, or a feature the org depends on migrates to a paid plan, and suddenly the consultancy who configured it is getting a call about enterprise pricing.
Salesforce Nonprofit Cloud is a legitimately powerful platform. It is also catastrophic overkill for a 15-person org running community programs. The licensing, the implementation, the ongoing maintenance, the staff training — the total cost of ownership at that scale is higher than most program budgets. NeonCRM is a tighter fit for non-profits, but it's complex enough that configuring it correctly usually requires someone who knows it well. If that person is a consultant who leaves after setup, the org is holding a system they can't maintain.
The right tool for most Canadian non-profits in the $200K–$2M budget range is usually one of three things: HubSpot for Nonprofits (which is a genuinely free tier for qualifying organizations, not a bait-and-switch), a Google Workspace form and Sheet setup built around the organization's actual data capture moments, or a small Power Apps build when the org is already in Microsoft 365 and needs something more structured. All three can be configured correctly, documented, and handed over. None of them require a consultancy on retainer to keep the lights on.
Outcomes nobody can prove
Funders want outcome reporting. They want to know how many participants completed the program, what placement rates looked like, how this cohort compared to the last one. The organization has stories — good ones, often compelling ones — but the data underneath those stories is scattered across attendance sheets, email threads, and a shared spreadsheet that three people have edited in incompatible ways.
The gap between "we know this program works" and "we can demonstrate it to a funder" is almost always a data collection problem, not a data analysis problem. The data that would prove the outcome was never captured in a form that could be aggregated. Trying to reconstruct it retrospectively — pulling emails, counting sign-in sheets, asking coordinators to remember — is slow, inconsistent, and produces numbers nobody fully trusts.
The fix is a system designed to capture the outcome data at the moment it occurs: a registration form that feeds into a tracker, an attendance system that records completion, a follow-up touchpoint at 30 or 90 days that captures placement or next steps. None of this needs to be sophisticated. A Google Form feeding a Sheet that rolls up into a Looker Studio dashboard is adequate for most non-profit outcome reporting needs. The complexity isn't technical. The complexity is deciding what outcomes to track before the program starts, and then building the capture around those decisions.
Documentation that lives with one person
The person who built the system and knows how it works is usually a volunteer, a student on a practicum placement, or someone who moved on six months ago. When they left, they took the institutional knowledge with them. Not intentionally — there was just no documented record of how the system was configured, what the field names mean, or what to do when the form stops submitting.
This problem gets worse in non-profits than in corporate environments because of higher staff turnover, heavier reliance on volunteers and placements, and thinner administrative capacity to maintain documentation. The organization gets a system, it works for a while, and then something small breaks and nobody knows how to fix it.
The fix isn't a better system. It's documentation and training baked in from day one — before the person who built it walks out the door.
That means: a short written guide to the system, in plain language, stored somewhere the whole team can find it. Loom walkthroughs of the three or four operations staff do most often. A named owner who participated in building the system and knows how it works — not just a user, but someone who understands the logic underneath. These aren't expensive things to produce. They're just things that need to be built into the engagement scope rather than treated as optional.
Funder reporting as a fire drill
Quarterly grant reports get assembled from memory, email searches, and whatever spreadsheet is nearest. Everyone knows where the data should be. It's just not there, or it's there in a form that requires hours of reformatting before it's reportable.
This is almost always a configuration problem, not a data problem. The data exists — somewhere. The issue is that the system wasn't configured to produce the output the funder wants. The registration form captures names but not postal codes. The attendance tracker records who came but not which program stream they were in. The outcome data is in a different system than the demographic data, with no shared key to join them.
The fix is designing the data collection around the reporting requirement, not the other way around. Start with the funder's template. Work backwards to what fields need to exist, at what point in the program cycle, in which system. Then configure the intake forms and trackers to capture exactly those fields. The report becomes a scheduled export rather than a research project.
What actually works
The right answer for most Canadian non-profits in the $200K–$5M budget range is less exotic than the demos make it look:
- A genuinely-free or low-cost CRM — HubSpot for Nonprofits if the fit is right, or a Power Apps build for more complex workflows where the org is already in Microsoft 365.
- A lightweight outcome-tracking layer built in Google Workspace or Microsoft 365, designed around the funder's reporting requirements from the start.
- Training that's been recorded and documented before anyone transitions out of the role. Loom walkthroughs, a plain-language operating guide, a named internal owner who knows the system well enough to maintain and teach it.
The goal is a system the organization can run without the person who built it. That's the test. If the system only works when a specific consultant or volunteer is involved, it's not done yet.
We lean hard into the free and non-profit tiers of tools that genuinely offer them. HubSpot for Nonprofits. Microsoft 365 for Nonprofits. Google for Nonprofits. Looker Studio for reporting (free). We only recommend a paid tier when it clearly earns it — and we're explicit about what "clearly earns it" means in that context before any commitment is made.
Common questions
"Will you teach our team, or do we depend on you forever?"
Knowledge transfer is the deliverable. We've written the long form of this argument, but the short version is: Stage 05 is built into every engagement we run. Documentation, Loom walkthroughs, hands-on training sessions, a named internal owner who has been part of the build from the start. We design for independence. The goal of the engagement is to make you not need us for the system we built. If you want ongoing support after that, we offer it on a clearly-defined retainer. If you don't, we leave and the system still works.
"Can we use free or non-profit tiers of tools?"
Yes, and we lean into them when they fit. HubSpot for Nonprofits, Microsoft 365 for Nonprofits, Google for Nonprofits, Looker Studio are all genuinely useful at the non-profit tiers and genuinely free or close to it. We only recommend stepping up to a paid tier when the free tier clearly can't support the workflow — and we'll say so on the fit call, not after you've signed.
"Do you do one-time projects or only ongoing retainers?"
Both. A defined-scope project — "build us a donor tracking dashboard and document it" — is the right shape for many organizations. We scope it, price it, deliver it, hand it over. Multi-stage end-to-end engagements are for organizations that need the full lift: process definition, system build, training, and ongoing support while the team gets comfortable. Tell us your situation on the fit call and we'll tell you which shape makes sense.
"Are you a charity?"
No. We're a for-profit consultancy. We're honest about that because it matters for how you evaluate us. What we do offer is sliding-scale pricing — 50–70% of commercial rates depending on org size — some pro-bono work for organizations under $500K, and the 32-module digital literacy curriculum as a standalone resource any community organization can access. Tell us your budget on the fit call. We'll tell you what's possible at that number, and we won't waste your time if the answer is nothing.
The consistent theme
Across every non-profit engagement we've done, the root cause is almost never the technology. The technology is usually fine, or would be fine if it had been chosen to fit the actual workflow instead of the vendor demo. The problems are sequencing and documentation.
The technology was chosen before the workflows were defined. It was deployed before the team was trained. It was left undocumented when the implementer moved on. And now the organization is holding something expensive, or something that sort-of-works, or something that nobody is actually using.
The fix is sequential — and the sequence matters:
- Define the process first. What does the program actually do? What data does it need to capture? What does the funder need to see?
- Choose the right-sized tool second. The tool that fits that process, at that budget, at that team size.
- Configure it around the actual process third — not around the vendor's default setup or the demo they showed you.
- Train the team and document everything fourth, before anyone leaves.
In that order. Every time. It's not a complex framework. It's just the sequence that actually works, and it's the one that gets skipped when an organization is moving fast or a volunteer is building something in whatever time they have available.
We're not the only people who can help with this. But if you've been through one of the four patterns above and you're looking for a team that's done this before — bring us in for the fit call and we'll tell you honestly what we think.