Choosing the right grant administration software is one of the most consequential technology decisions a grantmaking organisation makes. The system will shape how your staff work, how applicants experience your organisation, what data you can access, and how you comply with audit and governance requirements. Getting it right has long-term benefits; getting it wrong creates years of workaround and frustration.
This guide is for grantmaking organisations — community trusts, private foundations, gaming trusts, government agencies — who are evaluating or procuring grant administration software.
Most organisations start evaluating software too late — when their current system has already become unworkable. Ideal timing:
Don't let perfect be the enemy of good. A system that's 80% right and live is better than a system that's 95% right and still being evaluated.
Before evaluating any software, document your actual requirements:
Process map your current workflow. How does an application get from submission to decision to payment to report? Document every step, who does it, what system they use, and where the pain points are.
Count your volume. How many applications per year? How many active grants at any time? How many staff will use the system? How many external users (applicants, assessors)?
List your must-haves. What capabilities are essential — not nice to have, but required for your programme to function? Common must-haves include: online application portal, assessment workflow, automated communications, grant tracking, reporting.
List your nice-to-haves. What would improve your process but isn't essential? Advanced analytics, API integration, mobile app, custom branding.
Identify your constraints. What's your budget (implementation plus ongoing licensing)? What's your IT support capacity? Does the software need to integrate with your accounting system or CRM?
Consider your future state. What will your programme look like in 3-5 years? Choose software that can grow with you, not just serve today's needs.
Applicant portal:
- Can applicants create accounts and save progress?
- Can multiple users collaborate on a single application?
- Does it work on mobile devices?
- Is it accessible (WCAG compliant)?
- Can you customise the form fields?
Assessment workflow:
- Can you distribute applications to assessors electronically?
- Can assessors score independently without seeing each other's scores?
- Is there a panel discussion/moderation workflow?
- Does it support conflict of interest declarations?
- Can you configure assessment criteria and weightings?
Communication:
- Does it send automated acknowledgements on submission?
- Can you create templates for offer letters, decline letters, report reminders?
- Does it log all communications against the grant record?
- Can you send bulk communications to groups of grantees?
Grant tracking and management:
- Can you track milestone payments?
- Does it track reporting deadlines and send reminders?
- Can you record funder-grantee contacts?
- Does it support grant variations and amendments?
Reporting and analytics:
- What standard reports are available?
- Can you create custom reports?
- Can you export data to Excel or a BI tool?
- Is a public grants register available?
Grantee portal:
- Can grantees see their application status?
- Can grantees submit reports through the portal?
- Can grantees upload documents?
- Can grantees see payment status?
Security and compliance:
- Where is data stored (NZ, Australia, US)?
- What are the backup and disaster recovery provisions?
- Is two-factor authentication supported?
- Is role-based access control available?
- Are audit logs maintained?
Implementation:
- What does the implementation process look like, and how long does it take?
- What support do you provide during implementation?
- Can we see examples of implementations similar to ours?
- What are the most common implementation problems and how do you address them?
Ongoing support:
- What is your support model (email, phone, ticket system)?
- What are your SLAs for support response?
- Is there documentation and training available?
- What is your product development roadmap?
Data:
- What is your data ownership and portability policy? Can we extract our data at any time?
- How is data secured and backed up?
- Where is data physically stored?
- What is your policy if we decide to end the contract?
Pricing:
- How is pricing structured (per-user, per-grant, flat rate)?
- What is included in the base price vs. add-ons?
- Are there implementation fees?
- How has pricing changed over the past 3 years?
- Is pricing guaranteed for the contract term?
References:
- Can you provide references from similar organisations?
- Are there New Zealand or Australian customers we can speak to?
Selecting on features rather than fit. A system with every feature imaginable but poor usability, weak support, or a pricing model that escalates significantly with growth is a poor choice. Evaluate fit for your specific context, not feature count.
Underestimating implementation effort. Implementing new software requires significant staff time — not just IT, but the grants staff who need to configure the system, test it, and train on it. Most implementations take longer and cost more than expected. Plan for this.
Not involving end users. Selection decisions made by senior management without input from the grants staff who will use the system daily often miss critical usability requirements. Involve the daily users in demonstrations and evaluation.
Failing to test with real scenarios. Vendor demonstrations show the system at its best. Test with real (anonymised) applications, your actual form structure, and your specific workflows before committing.
Not checking references. Vendor-provided references are positive by definition. Try to find current users independently — LinkedIn, peer networks, sector forums — and ask about problems, not just successes.
Choosing the cheapest option without understanding total cost. Initial licensing cost is often a small proportion of total cost of ownership. Implementation, training, ongoing support, customisation, and the cost of switching if the system doesn't work all need to be factored in.
Prioritising customisation over convention. Systems that allow you to configure everything can be configured badly. Systems with well-designed defaults that reflect sector best practice often produce better outcomes than systems that require building everything from scratch.
For significant software investments, a structured procurement process protects the organisation:
For smaller organisations with simpler requirements, a lighter process is appropriate — but the core steps (define requirements, demonstrate with real scenarios, check references, understand total cost) remain essential.
Most established grants management platforms are US or UK-built. Considerations for New Zealand and Australian funders:
Tahua is purpose-built for Australasian grantmakers — with data hosted in the region, support provided during AEST/NZST business hours, and features designed for the specific requirements of community trusts, gaming trusts, and philanthropic foundations in this region.