What small organisations should prioritise before buying new technology

1. State the problem without naming a product

Write a short description of the current difficulty, the people affected, and the consequence for their work. Be specific. A need to know which enquiries are awaiting a response is more useful than a general request for a customer management platform. It leaves room to consider a better process, an existing feature, or a new service rather than assuming the answer.

Follow the work through its handovers. Determine whether the obstacle is missing information, unclear responsibility, duplicated entry, unreliable equipment, or an unsuitable tool. Ask staff to show an ordinary example using non-sensitive information. A real task often exposes requirements that a feature checklist misses.

• What should someone be able to do that is difficult today?
• Which step causes delay, uncertainty, or avoidable rework?
• What would acceptable improvement look like to the people doing the task?

2. Check the capabilities already available

Review existing subscriptions, equipment, and supplier arrangements before adding another platform. You may already have a suitable shared workspace, form tool, reporting option, or support entitlement. Check whether people know how to use it and whether its configuration fits the task. A modest improvement to an established system may be easier to adopt than a fresh start.

This is not an instruction to force every process into a tool you own. Compare its suitability honestly, including accessibility, information handling, reliability, and administration effort. An improvised workaround that depends on one person's complex spreadsheet can be harder to sustain than a well-chosen specialist service.

Look for opportunities to retire duplication. If a new purchase is justified, identify which existing tools or manual steps it should replace. Without that decision, the team may end up maintaining both old and new records indefinitely.

3. Separate essential requirements from preferences

Create a concise list of capabilities that must be present for the service to work. Include everyday constraints such as intermittent connectivity, supported devices, language needs, accessible interaction, and collaboration with external partners. Describe required integrations as actual information exchanges, including direction, frequency, and who resolves errors, rather than accepting an integration logo as proof of suitability.

Consider how the service will handle organisational information. Ask about account administration, access controls, export formats, deletion, recovery, and the contractual responsibilities of each party. Where personal or sensitive information is involved, involve the person responsible for data protection. Product marketing is not a substitute for assessing your own obligations.

• Mark a requirement essential only when its absence prevents acceptable use.
• Keep desirable features separate so they do not overshadow basic suitability.
• Turn each essential requirement into a question or task that can be verified.

4. Budget for the whole working life

Compare costs beyond the advertised price. Setup, migration, integrations, devices, connectivity, training, support, and staff administration all affect affordability. Check whether the plan being demonstrated is the one being quoted. Features needed for account management or data export may sit in a different tier, and introductory or eligibility-based pricing may not describe the ongoing commitment.

Read the renewal, cancellation, and licence assignment terms. Understand how charges change when staff numbers grow, volunteers rotate, or usage increases. For an NGO, confirm whether funding restrictions allow the recurring expenditure and what happens when a project grant ends. A purchase that fits today's budget can still create an unsupported obligation later.

Include the cost of leaving. Ask how records, attachments, and relevant history can be exported in usable formats, and what assistance costs. Ownership of information is much more practical when there is a tested way to retrieve it.

5. Test a representative workflow before committing

Use a bounded evaluation with clear questions and a named owner. Choose an ordinary workflow that includes the awkward parts: correcting a mistake, handing work to a colleague, producing an output, and finding a previous record. A polished demonstration usually follows the supplier's preferred route; your evaluation should follow the organisation's real one.

Use synthetic or appropriately approved test data. Involve people with different responsibilities and support needs, not only the most confident user. Check performance on the devices and connections staff actually use. Capture friction as well as successful tasks so the decision includes the likely training and support effort.

• Confirm essential tasks without relying on promised future features.
• Test permission changes, export, and a realistic support request.
• Agree what evidence would justify proceeding, extending the evaluation, or stopping.

6. Plan adoption and ownership before launch

Name a business owner who can decide how the tool should be used, and an operational owner who can maintain accounts and handle problems. In a small team these may be the same person, but an authorised alternate and clear documentation still matter. Establish who maintains the process when staff or suppliers change.

Plan the transition, including data preparation, user guidance, support availability, and any period of overlap. Set conditions for retiring the previous arrangement and retaining the records still needed. Avoid declaring success solely because the system is live; check that staff can complete the intended work without maintaining unnecessary parallel records.

Review the decision after people have used the tool in normal conditions. Keep what is working, address practical difficulties, and revisit assumptions when necessary. A considered decision can still lead to a small purchase, a larger investment, or no purchase at all.