When staff are not using new nonprofit software, it is tempting to call it resistance and schedule more training.
Sometimes training is the answer. But staff buy-in can also break down because the system does not fit the work, responsibilities are unclear, the setup creates extra steps, or the change was introduced without enough input from the people who use it.
That makes workarounds useful evidence. A side spreadsheet or manual check may show that someone needs more support. It may also show that the official route is missing something important.
The aim is not to convince people to like a tool. It is to create a setup they can use confidently during real work.
Why nonprofit staff work around new software
People usually avoid a new system for a reason. Common causes include:
- the workflow was never agreed before the system was configured;
- the tool adds steps without removing an older route;
- staff cannot see how the change helps their work;
- ownership, permissions or decision rules are unclear;
- the data is incomplete or difficult to trust;
- training covers features instead of real tasks;
- exceptions still need to be handled through email or memory; or
- staff are expected to learn while already carrying a full workload.
Some of these are training problems. Others are process or setup problems. Treating them all as attitude problems makes adoption harder.
First decide whether this is really a training problem
Ask four questions before planning another workshop.
1. Can the team describe the agreed workflow?
People need to know what starts the work, which steps matter, who owns each stage and what should happen when something falls outside the normal route.
If those answers vary by person, the software is trying to support a process that is not yet clear.
2. Does the system match that workflow?
Check whether fields, statuses, permissions and notifications support the work as it actually happens. Staff should not need a separate tracker to see a basic status or remember the next step.
3. Has the old route been removed?
If people can still complete the work through email, spreadsheets and the new platform, the organisation has created several competing sources of truth. Staff will choose the route that feels fastest or safest.
4. Are people being trained on their own tasks?
A general system tour may help administrators, but most staff need to learn the small set of tasks they perform regularly. They need to know what good completion looks like and where to go when the normal route does not fit.
If you are still unsure whether the software or the underlying work is the stronger issue, use the tool issue or process issue decision guide.
What staff buy-in actually requires
Buy-in is not enthusiasm at a launch meeting. It is a practical level of confidence that the change makes sense, supports the work and will not leave people carrying hidden extra effort.
Staff are more likely to use a system when they can answer:
- What problem are we solving?
- What will change in my work?
- What will stop or become easier?
- What am I responsible for?
- Where should information be recorded?
- What do I do when the standard route does not fit?
- Who can help if something goes wrong?
If the project cannot answer those questions clearly, it is too early to blame adoption.
A practical rollout for a small nonprofit
Start with one workflow
Choose a real, repeated piece of work such as recording a donation, processing a referral, approving an expense or updating a program result.
Map the current route with the people who do it. Mark where they wait, copy, check, chase or make judgement calls. Then show how the new route should handle those points.
Involve the people doing the work
Ask staff to test the proposed setup before it is treated as finished. Their role is not only to find bugs. They can identify missing decisions, unclear labels and exceptions the project team has not seen.
Do not choose testers only because they are comfortable with technology. Include someone who knows the work well and someone who may need more support. Their experiences reveal different risks.
Agree one source of truth
State where the official record will live and which old files or routes will stop. If a temporary parallel process is necessary, give it an owner and an end date.
Train by task, not by menu
Build short sessions around the jobs staff need to complete:
- create or find the correct record;
- complete the required fields;
- move work to the next owner;
- record a decision;
- handle a common exception; and
- confirm that the work is complete.
Leave advanced features until the core route is reliable.
Use safe practice data
Practice should feel realistic without exposing personal or sensitive information. Use a test environment where available, or prepare fictional and de-identified examples that reflect common situations.
Do not use identifiable donor, beneficiary, client or staff records simply because they make the exercise feel more real.
Create one route for help
Staff need to know where questions, errors and exceptions should go. A named owner, shared channel or regular office hour can work. What matters is that questions are captured and used to improve the setup.
Make space for honest feedback
Some rollout teams ask for feedback but only accept comments about training. That misses the most useful evidence.
Ask staff:
- Which task is now easier?
- Which task takes longer?
- Where are you still keeping notes somewhere else?
- Which field, status or instruction is unclear?
- Which exception has no workable route?
- What are you worried will be missed?
Do not promise that every preference will be implemented. Explain how decisions will be made and tell people what changed because of their feedback.
Watch what happens after training
Attendance and completion do not show whether adoption is working. Review the workflow after people have used it during real delivery.
| Signal | What it may mean |
|---|---|
| Staff ask the same basic question repeatedly | The instruction, label or task training may be unclear. |
| People keep a separate tracker | The main system may not provide visibility or trust they need. |
| Records stop at the same stage | Ownership, notification or approval may be unclear. |
| Required fields are skipped or filled inconsistently | The definition may be unclear, the field may arrive at the wrong point, or the information may not be useful. |
| Only one person can resolve problems | Administration and continuity are too dependent on one person. |
| The new route takes longer without reducing later work | The workflow or setup may need redesign rather than more training. |
Run a 30-day adoption review
After the system has been used for a reasonable period, bring together a few users and review one workflow.
Check:
- whether people use the agreed route;
- where work still leaves the system;
- which handoffs or decisions cause delay;
- whether information is complete and trustworthy;
- how much support the setup needs; and
- whether the original problem has actually improved.
Choose a small number of changes. Reconfigure what can be fixed simply. Redesign the workflow where the tool is exposing an unclear process. Provide more training only where knowledge or confidence is the real barrier.
If the organisation has grown beyond an informal setup, read Signs Your Organisation Has Outgrown the Way Work Gets Done. The Operational Continuity hub also covers adoption, ownership and inherited setups.
When more training will not solve the problem
Training is unlikely to fix the situation when:
- the team cannot agree on the workflow;
- the software cannot support a necessary requirement;
- staff are being asked to record information that no one uses;
- ownership and exceptions remain unclear;
- the setup depends on one administrator’s memory;
- old routes remain easier than the official one; or
- several teams need different things and no one can make the trade-offs.
In those cases, stop adding training sessions and investigate the work.
Use a simple onboarding checklist
The existing New Technology Onboarding Checklist for Nonprofits can help you organise the rollout. Use it alongside the workflow and ownership checks above rather than treating onboarding as training alone.
Still not sure why people are working around the system?
Use the tool/process decision guide if the question is still narrow. If the rollout problem crosses teams, ownership, data and workflow—or a costly decision is close—the Nonprofit Operations Review can provide an independent view of what to fix first.
Frequently asked questions
What if only some staff are resisting the new software?
Look at the tasks, information and support those staff need. Their role may encounter different exceptions, permissions or risks. Do not assume the difference is confidence alone.
Should we use staff champions?
Yes, when they are given a clear role and enough support. Do not make one helpful person the permanent unpaid system administrator or the only person who knows how the setup works.
How do we know whether adoption is improving?
Look for fewer side trackers, clearer handoffs, more complete records, less repeated support and evidence that the original operational problem has improved.
