How to Run a Grant Programme: From Criteria to Closeout | Dapple

Introduction

Grant programmes fail quietly. Not with a crash, but with a review panel drowning in ineligible applications, a spreadsheet nobody trusts, payments chased over email, and a closeout report assembled from memory six months later.

None of that is inevitable. The organisations that run smooth programmes aren't better resourced — they make a handful of decisions early, in the right order. This guide walks through that order: programme definition, criteria, application design, review, decisions, and the post-award work that most guides skip.

Define the Programme Before the Paperwork

Before anyone writes a guideline document, agree four things in writing:

• Fund size and award shape. Total pot, how many awards, and the range per award. Ten grants of £2,000 and two grants of £10,000 are entirely different programmes with different applicants, review loads, and reporting burdens.
• Who it's for. The narrower the audience, the better your applications. "Emerging artists in the North West" produces a reviewable pile; "creatives" produces chaos.
• What success looks like. If you can't say what a successful grantee will have done in twelve months, reviewers can't score for it and grantees can't report against it.
• The calendar, backwards. Start from the date money must reach grantees and work back: decisions, panel review, eligibility screening, deadline, launch. Panels always take longer than you think — protect that window first.

Write Criteria People Can Actually Meet

Split your criteria into two explicit lists, and publish both:

• Hard requirements — binary, checkable facts: location, organisation type, budget cap, required documents. An application either meets them or it doesn't, and one person (or software) can screen for them without judgement.
• Scored preferences — the things that make an eligible application strong: first-time applicants, community engagement, feasibility. These belong to the review panel, with weights agreed before anyone reads an application.

Mixing the two lists is the single most common source of grant-programme pain. When "must be London-based" and "should demonstrate community impact" sit in the same paragraph, applicants can't tell what disqualifies them, ineligible applications flood in, and panels waste their scoring time doing eligibility screening.

Write it in plain language, publish the weights if you can, and include a short "you should not apply if" list — it saves applicants' time and your panel's.

Design the Application

The test for every question: will a reviewer use this answer to make the decision? If not, cut it. A £2,000 micro-grant does not need a five-year financial forecast.

Principles that hold across programme sizes:

• Match effort to award size. As a rule of thumb, an applicant shouldn't spend more than a few percent of the award's value applying for it.
• Put hard-requirement questions first. With conditional logic, an ineligible applicant finds out in two minutes, not after forty.
• Accept the evidence in its natural format. Portfolios as images or video, budgets as spreadsheets — not everything flattened into PDF.
• Let people save drafts. Grant applications get written over evenings and weekends. A form that can't be left and resumed costs you good applicants — more on this in our piece on why forms lose applicants.

Build a Review Process That Scales

Run review in two distinct passes:

Pass one: eligibility screening. Someone — admin staff, or increasingly software — checks every application against the hard requirements only. Ineligible applicants get a kind, specific explanation. Your panel never sees these applications.

Pass two: panel review. Eligible applications go to reviewers with the scored preferences, agreed weights, and a consistent scoring scale. What makes panels work:

• Every application read by at least two reviewers, with divergent scores discussed rather than averaged away
• Conflicts of interest declared up front, and conflicted reviewers excluded per-application
• Anonymised review where your programme allows it, so work is scored on substance
• Progress visible to the coordinator — who's finished, who's stalled — with reminders sent before the deadline, not after

Our guide to setting up a judging process people enjoy goes deeper on panel mechanics — the same principles apply to grant review.

Decisions and Communication

Decide how ties and borderline cases get resolved before the panel meets — chair's casting vote, full-panel discussion, or additional review — so the final meeting is about applications, not process.

Then communicate on the published date, to everyone. For unsuccessful applicants, a specific sentence about why beats a paragraph of consolation. You don't owe everyone detailed feedback, but the applicants who nearly made it are your strongest future pipeline — treat them that way.

For successful applicants, the offer should include the award amount, the payment schedule, reporting expectations, and the agreement to sign. Getting all four into the first message prevents the drip of admin emails that sours the relationship early.

Disbursement, Reporting, and Closeout

This is where most software stops and most workload starts. Three practices keep the post-award phase sane:

• Pay against a schedule, not on request. Whether it's a single payment, quarterly tranches, or milestone-based drawdowns, publish the schedule in the award letter and tie each release to a named condition — a signed agreement, an approved report.
• Keep reporting proportionate. Ask small grantees for a short update and receipts, not an audit file. What you need is evidence that spend matches budget and activity matches plan — variance, not volume.
• Keep one record per award. The application, the scores, the agreement, the payments, and the reports belong together. The moment they split across a spreadsheet, a bank portal, and an inbox, your audit trail — and your closeout report — is reconstruction work.

This end-to-end record is exactly what we're building Dapple's grant management around: AI eligibility screening, panel routing, Stripe disbursements on drawdown schedules, and variance reports drafted from grantee evidence — with every step on the same record that collected the application.

Conclusion

A good grant programme is a chain of small, early decisions: a defined fund, criteria split into checkable requirements and weighted preferences, an application matched to the award size, review in two passes, decisions on schedule, and payments tied to published conditions. Get those right and the cycle runs itself — and each year's closeout becomes next year's head start.