Choosing charity systems: compare the workflow before buying the software

Choosing charity software is easier when the organisation first agrees how the work should flow. A supporter platform, finance system or volunteer tool can offer useful features while still leaving staff to bridge the gaps between teams. Procurement should test those handoffs as deliberately as it tests the product demonstration.

The right decision may be to improve an existing setup, connect two tools or replace a system that no longer meets the charity's needs. A vendor-neutral assessment keeps those options open until the evidence supports a choice. It also gives trustees and managers a clearer explanation of the commitment they are making.

This guide provides a practical comparison method for established charities. It does not rank vendors or assume one product suits every organisation. The example scoring and scenarios are illustrative and need to be adapted to your governance, users and operating risks.

Describe the problem before listing features

Ask staff to demonstrate the tasks that currently cause difficulty. Follow a supporter enquiry, a volunteer application or a programme report through the actual systems. Note where information is copied, decisions wait or colleagues rely on an unofficial spreadsheet to complete the work.

Turn each problem into an outcome. “A single view of the supporter” is too vague to test. “Fundraising can see the current communication preference and the status of an enquiry without exporting another contact list” is more concrete. It identifies the user, information and task the proposed system must support.

Separate causes from symptoms. A slow report may result from inconsistent definitions rather than an inadequate reporting tool. A duplicate contact problem may begin with form design or import rules. Replacing the database without changing the intake process can recreate the same issues in a newer interface.

Write a short problem statement and agree its owner. Include who is affected, the frequency of the task and the consequence of failure. This keeps procurement focused when demonstrations introduce attractive features that are unrelated to the charity's main operating need.

Review what the charity already owns

Inventory current tools, licences, renewal dates and the work each one supports. Include small subscriptions and volunteer-managed services, not just major contracts. A useful feature may already be available but inaccessible because permissions, training or ownership were never established.

Ask why existing capabilities are unused. Staff may not know about them, but there may also be valid limitations in accessibility, configuration or support. Avoid treating low usage as a simple training problem until someone has observed the task and understood the difficulty.

Map current connections and exports. A system that appears isolated may feed an essential finance process through a monthly file. That dependency needs to be preserved, redesigned or retired deliberately. Removing an old subscription can interrupt a reporting obligation if nobody identified its hidden role.

Compare improvement options before assuming replacement. A repaired form, a clear approval route or a modest integration may address the problem at lower disruption. Conversely, repeated manual workarounds may show that the current architecture cannot meet the requirement sustainably. Record the evidence for either conclusion.

Build requirements around realistic scenarios

Prepare a few end-to-end scenarios for suppliers to demonstrate using synthetic data. Include the ordinary case and an exception. For a supporter enquiry, the scenario might include a duplicate candidate, a changed preference and a request that needs two teams to respond.

• Show how an authorised user completes the task without administrator assistance.
• Show what happens when required information is missing or contradictory.
• Show how the record reaches the next team and how ownership is accepted.
• Show the history needed to explain a correction or decision later.
• Show how the charity retrieves its information if it leaves the service.

These questions create more useful evidence than a feature checklist alone. A supplier can legitimately answer that a task requires configuration or an additional service, but the cost, responsibility and limitations should be recorded before the comparison is scored.

Ask to see the relevant product and account arrangement rather than a hypothetical future capability. Planned features may be interesting, but a procurement decision should distinguish what is available now, what requires paid implementation and what remains an uncommitted proposal.

Include the people who will operate the system

Invite representative staff and volunteers to assess the tasks they will perform. A finance manager can judge reconciliation; a fundraiser can assess supporter follow-up; an occasional volunteer may reveal usability problems experienced by infrequent users. One confident administrator is not a substitute for those perspectives.

Ask participants to record observations before a group discussion. This reduces the chance that the most enthusiastic voice determines everyone's assessment. Encourage specific evidence: “I could not find the previous reply without opening three screens” is more useful than “the system felt complicated”.

Consider accessibility and different working environments. People may use keyboards, screen readers, smaller screens or shared devices. The W3C accessibility fundamentals provide a useful reference, but practical testing with relevant users remains important. A supplier's accessibility statement should be examined alongside the actual tasks.

Confirm training and ongoing support arrangements for each role. Occasional users may need simple guidance and an internal contact more than a long launch workshop. Include new starters and staff turnover in the plan so the charity does not lose capability as the original project team changes.

Check information access and ownership

List the categories of information the system will hold and who needs access to each. Supporter contact details, beneficiary information, finance records and volunteer applications may require different permissions. A convenient all-staff dashboard is not automatically an appropriate place for all of them.

Ask suppliers to demonstrate permission changes, staff departure and audit history. Can the charity remove access promptly? Can it see who changed a significant record? Are support staff given access under a controlled process? These questions should produce specific answers relevant to the proposed service configuration.

Review the applicable data arrangements with the responsible person. Identify processing locations, subcontractors where relevant, retention options and how deletion or export requests are handled. Do not assume a familiar brand or a charitable discount resolves those responsibilities.

Keep ownership of the configuration clear. If an external implementer creates fields, reports and integrations, the charity needs documentation and suitable administrative control. Otherwise a system can become difficult to maintain or replace because essential knowledge remains with one contractor.

Test integrations as part of the purchase

A product listing “integrates with finance” may describe several different arrangements: a manual export, a scheduled connector or a custom project. Ask what data moves, in which direction, how often and under whose responsibility. Confirm which versions and account tiers the proposed connection supports.

Agree record ownership for shared fields. Communication preferences should not be overwritten by an older import. A financial adjustment should not be interpreted as a supporter preference change. The charity finance and fundraising guide explains why these distinctions matter for reliable reporting.

Demonstrate a failed connection and its recovery route. Who is notified, where does unfinished work wait and how is a retry prevented from creating duplicates? An integration that works in a supplier's clean demonstration still needs evidence for the charity's real volumes and exceptions.

Include monitoring and maintenance in the commercial proposal. Connected services change over time. Identify who checks compatibility, applies necessary updates and pays for support when an external interface changes. Without those arrangements, a useful launch connection can quietly become a recurring manual task.

Compare the total operating commitment

List setup, migration, licences, training, integration, support and internal staff time. Note any volume-based charges or features requiring a higher plan. Use a realistic planning period and state assumptions instead of presenting the first month's subscription as the whole cost.

Include the cost of running old and new processes during transition. Staff may need to reconcile records, answer questions and complete ordinary work while learning the new tool. This capacity is not free merely because it does not appear on the supplier's invoice.

Record renewal and exit conditions. Charitable pricing may have eligibility rules or a limited period. A low introductory fee can be useful, but the charity needs to understand the ongoing arrangement and what happens if its size, usage or qualification changes.

Use an illustrative comparison worksheet with separate columns for confirmed costs, estimates and unresolved items. Do not treat a missing price as zero. Ask suppliers to clarify material unknowns before approval, particularly for migration, custom reporting and work needed to make a promised integration operational.

Plan migration as an operating change

Identify which records need to move and why. Moving every historical field can carry old duplicates and unclear classifications into the new system. Equally, omitting important history can prevent staff from understanding a supporter relationship or meeting a legitimate retention need. Decide the scope with the responsible teams.

Agree how records will be matched and reviewed. Test a sample containing duplicates, changed contact details and unusual historical entries. Keep a reconciliation of source and destination counts with explanations for deliberate exclusions. A successful file import does not establish that the transferred information is usable.

Protect current preferences and suppression records during migration. The new system must not make a person eligible for promotion simply because an old export contains a positive flag. Treat conflicts as a review question and preserve the evidence needed to understand the decision.

Define a cutover and fallback. Which system is authoritative during transition? How are changes made while the final import is prepared? Who decides whether to proceed? The automation rollout guide offers a broader framework for testing and controlled release.

Use a transparent decision record

Agree essential requirements before scoring optional features. A product that fails a critical permission or export requirement should not win simply by accumulating points for attractive extras. Record why a requirement is essential and who can approve a change to it.

Weight other criteria against the charity's priorities, using clearly defined evidence. An illustrative score could distinguish demonstrated, partly demonstrated and unverified capability. Avoid excessive numerical precision; a score of 8.3 does not become objective if the underlying judgement is vague.

Document trade-offs. One option may offer better usability while requiring a separate reporting connection. Another may reduce integration work but create more training needs. A useful recommendation explains those consequences, the remaining unknowns and the reasons the selected approach fits the organisation.

The Charity Commission's financial-controls guidance is relevant to charities in England and Wales considering financial systems and controls. Trustees and management should apply the guidance and professional advice appropriate to their own jurisdiction, responsibilities and purchase.

Commission independent help where it adds clarity

A vendor-neutral adviser can help map tasks, prepare scenarios and compare the evidence without starting from a preferred product. The scope should make clear whether the adviser receives referral fees or has implementation relationships that could affect the recommendation. Transparency helps the charity interpret the advice.

Our charity operational transformation service can examine the workflow and existing tools before a major software decision. The useful output may be a procurement brief, an integration plan or a recommendation to improve the current setup rather than replace it.

Ask for reusable documents: the requirement set, scenario results, cost assumptions and migration risks. The charity should be able to explain the decision after the consultant leaves. A supplier shortlist without the reasoning behind it provides little support for later governance or contract review.

Keep approval separate from optimism. A convincing demonstration can justify further testing without justifying an immediate multi-year commitment. Use staged decisions where appropriate, with clear evidence required before the charity moves from evaluation to implementation and then ordinary operation.

Ask suppliers to demonstrate an exit

Include an exit scenario in the evaluation. Ask for an export of the synthetic records used in the demonstration, including relationships, important history and communication preferences. Check whether the files are understandable outside the product and whether essential attachments or configuration definitions require a separate process.

Ask who performs the export, how long it takes and whether additional charges apply. Confirm what happens to information after the contract ends under the applicable arrangements. A promise that data can be exported is incomplete if the charity cannot recover the relationships needed to use it.

Record any dependency on a specialist implementer or proprietary connector. The charity may reasonably accept that dependency, but it should understand the practical consequence and have an appropriate continuity plan. Review the exit evidence alongside the attractive launch features so the decision considers the full operating relationship.

Review the purchase after it becomes daily work

Return to the original tasks after a suitable operating period. Can staff complete them with the intended permissions and handoffs? Which workarounds remain? Are the expected reports understandable? Compare the observed experience with the procurement evidence rather than judging success by launch completion alone.

Assign remaining issues to an owner and distinguish training gaps from product or process limitations. Repeating a workshop will not repair a missing integration, while custom development may be unnecessary if a role has never received appropriate guidance. The response should match the cause.

Maintain the system inventory and review key contracts before renewal. An informed renewal considers usage, support quality, unresolved risks and the organisation's current needs. This turns procurement into an ongoing management responsibility and helps the charity avoid another cycle of disconnected tools and unplanned replacement projects.

Checked sources

• W3C WAI: introduction to web accessibility
• Charity Commission: internal financial controls (England and Wales)