How to Choose Grant Management Software for a Research Institution

What's the difference between research administration and grant application software?

Research administration software manages money coming in from external funders. Application and review software manages decisions going out: who your institution chooses to fund, award or select. The word “grant” covers both, which is why so many buying guides blur them.

If your problem is spreadsheets, inboxes and shared drives full of applications, you're in the right-hand column. Buying a research administration system to fix that is like buying a finance system to run a staff awards night.

Which university programmes need application and review software?

Any programme where people apply and a group decides. Across a university that's usually dozens of programmes, run by different teams, each with its own form, deadline and reviewers.

• Internal research funding: seed, pilot and bridge grants, travel and conference funds.
• Limited submissions: when an outside funder caps how many applications your institution can send, you run an internal competition first to pick the strongest.
• Fellowships: graduate, postdoctoral, visiting and artist-in-residence fellowships.
• Scholarships and bursaries: merit-based, need-based, endowed and departmental awards.
• Prizes and awards: teaching excellence, student achievement, alumni recognition.
• Museums, galleries and arts schools: open calls, exhibitions, commissions and residencies.
• Innovation and enterprise: student venture competitions, proof-of-concept funds and challenge prizes.

The pattern is the same each time: collect, check, review, decide, notify. That's why one platform can run all of them, and why buying a separate tool for each one quickly gets expensive.

What features matter for internal funding, fellowships and awards?

The features that matter most are the ones that make decisions fair and defensible, and keep academics' review time short. Look for these, in roughly this order.

1. Multi-stage review. Most academic competitions run in rounds: an expression of interest, a shortlist, then a full application. Each stage should have its own form, reviewers, scoring and deadline.
2. Rubric scoring and clear criteria. Reviewers should score against the published criteria, with guidance beside each one, so scores can be compared and explained.
3. Conflict of interest. Reviewers should be able to declare a conflict, with a reason, before they score, and the record should stay with the application.
4. Anonymous review. You should be able to hide names and identifying fields from reviewers, and reveal them later if your process needs it.
5. Eligibility checks before review. Ineligible applications are the biggest waste of reviewer time. The system should catch missing documents and failed criteria before anything reaches a reviewer.
6. Many programmes, many teams. One account should hold every department's programmes, each with its own reviewers and permissions, without everyone seeing everything.
7. Forms your team can build. If every new form needs IT or the vendor, you'll launch fewer programmes. Look for conditional logic, steps and templates.
8. Feedback and notifications. Applicants want to know where they stand. Unsuccessful applicants increasingly expect feedback, and sending it shouldn't mean 200 individual emails.
9. Reporting and exports. You'll need to report on who applied, who was funded and how decisions were made, often to a committee or donor.
10. Award tracking. At minimum, record what was awarded and to whom. Deep multi-year financial tracking usually belongs in your finance or research system instead.

What will IT, procurement and legal ask?

Get these answers from every vendor before you fall in love with a demo. They're the questions that stall university purchases late in the process.

• Sign-in: does it support single sign-on (SSO) with your campus login? Can external applicants and reviewers sign in with Google or Microsoft instead of another password?
• Security certification: what can the vendor show? Look for a recognised certification and a clear security page, not just “bank-level security”.
• Data protection: will they sign a data processing agreement (DPA)? Applications hold personal data, and for students may fall under FERPA in the US or GDPR in the UK and EU.
• Roles and permissions: can you limit what each reviewer, department admin and central admin can see?
• Integrations: is there an API, or can data be pushed out automatically to your CRM, research or finance system?
• Contract and exit: can you export everything if you leave? Are there minimum terms?
• Procurement route: check your threshold early. Smaller annual contracts often go through a simpler process. In England, Wales and Northern Ireland, universities now buy under the Procurement Act 2023, and Jisc's guide is a useful checklist even for smaller tools.

Involve IT and procurement in the first conversation, not the last. They'd rather say yes early than block a contract that's already been agreed.

How long does implementation take?

It depends almost entirely on the category. Jisc estimates a research management system takes roughly 12 to 20 months end to end, from defining the problem to going live. That's normal for software wired into finance, HR and research reporting.

Application and review software should take days to weeks. Submittable, for example, says most of its customers launch new programmes in two weeks or less. If a vendor in this category quotes months of implementation, ask why. Usually it means their team builds your forms for you, which also means you'll wait on them every time something changes.

A good test: in the demo, ask them to build a short application form and a review stage in front of you.

Where does AI fit in reviewing applications?

AI is most useful on the admin, not the decision. Applications are getting longer and more polished, partly because applicants use AI to write them, and review committees are feeling it.

Used well, AI can:

• check each application against your eligibility criteria and flag what's missing
• write a short, neutral summary so reviewers can get oriented quickly
• tag and route applications to the right stage or reviewer group
• help you analyse results and build reports once decisions are made

The decision should stay with people. Ask any vendor exactly what their AI does, whether you can switch it off, and whether reviewers can see what it flagged and why. Be wary of tools that score or rank applicants on their own with no human check.

What should you ask in a demo?

Take this list into every demo. A vendor that can show you each one live, rather than promising it, is usually the safer bet.

Which grant management tools do universities use?

Universities typically pair one research administration system with one or more application and review tools. Here's how the main names fit.

Research administration (sponsored research)

• Worktribe: end-to-end research management, used by UK universities.
• Cayuse, Kuali Research, InfoEd: widely used by US research universities for proposals, compliance and post-award.

Application and review (internal competitions, fellowships, awards)

Where Dapple fits. Dapple is application and review software, not a research administration system. It's built for teams running several programmes at once: internal grants, fellowships, scholarships, prizes and open calls. Each programme gets its own forms, stages, Review Rounds, conflict-of-interest declarations and anonymity settings. Dapple's AI checks applications against your criteria, summarises them and routes them to the right reviewers; your people make the decisions. It supports SSO, Google, Microsoft and Apple sign-in, is Cyber Essentials certified, and offers a standard DPA. Dapple works alongside your research system, pushing data out through its API and webhooks.

Frequently asked questions

See it for yourself

Want to see how your internal competitions, fellowships or scholarships would run in Dapple? Explore grant management or book a demo.