Grant guidelines are the most consequential document in a funder's toolkit, and they're consistently the most poorly written.
The applications you receive are a direct function of the guidelines you publish. Vague eligibility criteria produce a wide, shallow applicant pool — lots of applications, most of them irrelevant. Unclear scope criteria produce applications that technically meet eligibility but aren't what you're trying to fund. Inadequate budget guidance produces applications with fantasy budgets that have to be renegotiated before contracts can be signed.
The effort you put into writing clear guidelines pays off many times over — in assessment time saved, in better applications, in fewer support queries, and in decisions that are easier to defend.
Before writing (or rewriting) your guidelines, it's worth being clear about the three things they need to do.
Define who is eligible. This is the gate. Eligible/ineligible should be determinable from the guidelines alone, without reference to a programme manager. If an organisation has to call you to find out whether they're eligible, your eligibility criteria are unclear.
Define what you will and won't fund. This is the scope. Within the eligible pool, applicants need to know what kinds of projects or activities you're looking for. This is where most guidelines fail — they describe the funder's values and aspirations, but not the specific scope of the programme.
Set clear expectations for the application itself. What does a strong application look like? What information do you need, and in what form? What will make an application unsuccessful?
Guidelines that do all three of these things well will reduce your ineligible applications by 20–30%, reduce your support query volume by 30–40%, and produce a higher-quality pool of eligible applications.
The natural instinct when writing eligibility criteria is to be inclusive — to err on the side of allowing more organisations to apply, to avoid excluding someone who might be a great fit. This instinct is well-intentioned and counterproductive.
Vague eligibility generates work. Every application that isn't quite eligible — but isn't clearly ineligible — has to be manually assessed at the eligibility stage. That takes time, creates inconsistency, and produces defensibility problems when excluded applicants challenge their exclusion.
Write eligibility criteria that clearly define who is in and who is out. The best eligibility criteria are binary: the organisation either meets the criterion or it doesn't, and a reader can determine which without calling you.
Good eligibility criteria are specific about:
Organisational type: Not "community organisations" but "registered charities, not-for-profit incorporated societies, or local authorities." Not "NGOs" but a defined legal structure.
Geographic scope: Not "organisations working in the region" but "organisations whose primary place of operation is within [specific boundaries]" or "projects whose beneficiaries are primarily located in [specific area]."
Organisational size: If you have a preference or requirement around turnover, employee headcount, or years of operation, state it. "Organisations with annual income between $50,000 and $2,000,000 in the most recently completed financial year" is clear. "Small to medium community organisations" is not.
Exclusions: Be explicit about who cannot apply. Organisations that are primarily commercial, government departments, organisations with unsatisfied conditions on prior grants from your fund, organisations that have received funding in the last [X] years. Explicit exclusions prevent the ambiguous cases that cost you assessment time.
The scope section is where most guidelines become useless. Funders write about their values, their theory of change, and the kind of world they want to see. They don't write about what they'll actually fund.
Compare these two scope descriptions:
Version A: "We fund projects that strengthen communities, build resilience, and create pathways for people to thrive. We believe in the power of community-led solutions and are particularly interested in projects that address systemic inequalities and create lasting change."
Version B: "This round funds projects that provide direct services to young people aged 15–24 who are not in employment, education, or training (NEET). Eligible activities include: job readiness training, mentoring programmes, vocational skills development, and supported employment placements. Activities that are not eligible include: capital expenditure, advocacy campaigns, and projects primarily focused on populations outside the stated age range."
Version A sounds better. Version B is better guidelines. Version A tells applicants about your values. Version B tells them what to apply for.
Your scope description should include:
What you will fund: Specific activity types, populations, geographies, or approaches that are within scope. The more specific, the better.
What you will not fund: Explicit exclusions. Capital expenditure (or not). Salaries (or not). Research (or not). Projects in progress (or not). Every item on this list prevents an ineligible application and reduces support query volume.
Scope priorities for this round: If you have strategic priorities within the eligible scope — populations you're particularly interested in, approaches you want to test — say so. This allows strong applicants to make the case for why their project aligns with your priorities, and it improves the quality of applications you receive.
The application form questions are part of your guidelines. How you frame a question determines the quality of the answers you get.
Common mistakes in application question design:
Too broad: "Tell us about your organisation." What specifically do you need to know? Financial health? Governance structure? Track record? Management capability? Ask what you need. "Tell us about your organisation" produces 300-word responses that say nothing useful.
Too compound: "Describe the project, including the activities you'll undertake, the beneficiaries you'll serve, and the outcomes you expect to achieve." This is three questions in one. Applicants will answer one of them properly and gesture at the other two. Ask them separately.
No guidance on evidence: "Demonstrate the need for this project." What evidence are you looking for? Statistics, community consultation, prior research? Without guidance, answers range from a paragraph of assertion to ten pages of referenced data. Tell applicants what kind of evidence is most useful.
Unmarked relative importance: If your assessment rubric weights community need evidence at 30% and organisational capacity at 20%, tell applicants. An applicant who doesn't know that community need carries more weight than budget breakdown will write a generic application. An applicant who knows will put their best evidence where it counts.
Budget-related questions are among the most under-specified parts of most application forms. The result is applications with budgets that require extensive renegotiation before contracting.
Budget guidance should specify:
What costs are eligible: Staff time (direct project staff only? management overhead?). Contractor fees. Equipment (capital vs operational). Venue and travel. Evaluation costs. Overhead or indirect costs (as a percentage, or not at all?).
Funding limits: Maximum grant amount. Whether you'll fund 100% of project cost or require co-funding. Whether you'll fund the same organisation in multiple consecutive rounds.
Budget format: Do you want a line-item budget? A cost-per-participant calculation? An Excel template? If you have a preferred format, provide it. If you don't specify, you'll receive 80 different budget formats.
What you won't fund: GST-exclusive or inclusive? Retrospective costs? Contingency reserves?
The more specific your budget guidance, the more comparable your applications will be, and the less pre-contract negotiation you'll need to do.
Every set of guidelines generates a predictable set of questions. Before your round opens, give your draft guidelines to someone who hasn't been involved in writing them and ask them to read it as an applicant. Ask them: what are you unsure about? What would you call to clarify?
The questions they identify are the questions that will clog your query inbox. Answer them in the guidelines. Add a clearly signposted FAQ section. Invest 30 minutes answering the top ten questions in writing, and you'll save weeks of query management after the round opens.
Every sentence in your guidelines should pass this test: would a first-time applicant, with no prior knowledge of our organisation, be able to act on this information?
If the answer is no — if the sentence is describing your values rather than your requirements, or using jargon that assumes prior knowledge, or leaving something ambiguous that a reader would need to call to clarify — rewrite it.
Good guidelines are generous with information and economical with aspiration. They tell applicants exactly what they need to know to decide whether to apply, and exactly what to include if they do. That specificity is a service to your applicants and an investment in the quality of your round.
At minimum: who can apply (eligibility), what the grant funds (scope), how much can be applied for, how applications will be assessed (criteria and process), how to apply, and key dates. Each section should be written in plain language, with common borderline cases addressed explicitly.
Define who you want to fund (positive framing first), then list explicit exclusions, then address common borderline cases. Avoid trying to enumerate every possible scenario — define the principle clearly and handle edge cases through your query process. Test the criteria against real examples from your expected applicant pool before publishing.
Eight to twelve pages for most programmes. Below that, applicants can't determine eligibility or what you're looking for. Above fifteen to twenty pages, the essential information gets buried and you disadvantage smaller organisations without staff to parse complex documents.