AnyLearn
All lessons
Businessbeginner

Grant Writing: What Funders Are Actually Reading For

Grant applications look like writing tasks and are mostly evidence and fit problems. This lesson covers what a reviewer is really assessing, why generated applications fail in a specific and detectable way, and how to use tooling on the parts that genuinely repeat without producing an application that says nothing.

Updated · AI-authored, review-gated · how lessons are made

Not signed in: your progress and quiz score won't be saved.
Progress1 / 8

What a grant application is for

An application reads as a request for money and functions as an argument, and knowing which argument determines everything about how tooling can help.

The funder has finite money and more applications than they can fund. Their reviewers are answering a small number of questions, and most applications fail on one of them.

Is this problem real, and is it the problem we said we care about? Fit is the largest single cause of rejection, and it is usually decided before the prose is read closely.

Can this organisation actually do this? Track record, capability, whether the team exists, whether the numbers are plausible.

Will anything be different afterwards, and how would we know? Outcomes rather than activities.

Is this good value compared to the other applications on the pile?

And is this organisation a safe bet? Governance, financial health, whether the money will be accounted for.

Notice that only one of those is about writing quality. An application can be beautifully written and fail every one, which is exactly what a generated application tends to be.

So the useful framing for this cursus. Grant writing has a large repetitive component, which tooling helps with substantially, and a small evidential core that is the entire basis of the decision. Compressing the first is valuable. Generating the second produces a fluent document that reviewers reject, and lesson content that follows explains why they can tell.

Full lesson text

All 8 steps on one page, for reading, reference, and search.

Show

1. What a grant application is for

An application reads as a request for money and functions as an argument, and knowing which argument determines everything about how tooling can help.

The funder has finite money and more applications than they can fund. Their reviewers are answering a small number of questions, and most applications fail on one of them.

Is this problem real, and is it the problem we said we care about? Fit is the largest single cause of rejection, and it is usually decided before the prose is read closely.

Can this organisation actually do this? Track record, capability, whether the team exists, whether the numbers are plausible.

Will anything be different afterwards, and how would we know? Outcomes rather than activities.

Is this good value compared to the other applications on the pile?

And is this organisation a safe bet? Governance, financial health, whether the money will be accounted for.

Notice that only one of those is about writing quality. An application can be beautifully written and fail every one, which is exactly what a generated application tends to be.

So the useful framing for this cursus. Grant writing has a large repetitive component, which tooling helps with substantially, and a small evidential core that is the entire basis of the decision. Compressing the first is valuable. Generating the second produces a fluent document that reviewers reject, and lesson content that follows explains why they can tell.

2. Why reviewers can tell

Funders report seeing more applications that are fluent and empty, and the pattern is specific enough to describe.

A generated application has the right shape. Correct sections, appropriate length, professional register, all the expected vocabulary about outcomes and sustainability and community need. What it lacks is anything only this organisation could have written.

Concretely, the tells.

The need statement describes the problem in general terms, with national statistics, rather than describing what is happening in this particular place to these particular people.

The approach could be delivered by any organisation. Nothing in it depends on who you are or what you have.

The outcomes are round, ambitious and unattached to any method of measurement.

The beneficiaries appear as a category rather than as people.

And everything is smooth. No trade-offs, no constraints, no acknowledgement that anything is hard.

That last one is the sharpest signal. Real programmes have tensions: you cannot serve everyone, some things did not work last time, the model has limits. An applicant who names those reads as someone who has actually run something. An applicant with no difficulties reads as someone who has not.

Which yields the practical principle for the whole lesson. The material that makes an application competitive is specific, local and often uncomfortable, and it exists only in your organisation. No model can supply it, and applications built without it fail regardless of how well they are written.

3. The part that genuinely repeats

Having established what cannot be generated, it is worth being precise about how much genuinely can, because it is a large share of the work.

Most organisations apply to many funders with substantially the same programme. Each application asks for the same information in a different structure, with different word limits, different terminology and different section headings. A grant writer spends a great deal of time re-expressing material they have already written, to a new template, at a new length.

That is reformatting, and it is exactly what generation does well.

The approach that works is a source library rather than a pile of old applications. Maintain, once and properly: your organisational description at several lengths. Your track record with real numbers. Governance and financial information. Staff biographies. Your theory of change. Descriptions of each programme. Standard policies. And your evidence base of what you have achieved, with sources.

Then each application becomes selection and adaptation from that library, rather than composition. The tool reformats to the funder's structure and word limit, and every fact came from material you wrote and verified.

This is the same pattern as the single source of truth in the small business cursus, and it has the same second benefit: consistency. Applications assembled from one library do not contradict each other, which matters because funders talk to each other and because your own reports will be checked against what you claimed.

And it puts the saved time exactly where you want it: into the specific, local material that actually wins the grant.

4. Assembling an application

The workflow that uses tooling on the repetitive layer while keeping the evidential core human.

Start with the funder, not the form. Read what they say they fund, what they have funded before, and what their priorities are this cycle. Assess fit honestly, and this is a decision rather than a writing task: most wasted applications are ones that should not have been submitted.

If the fit is real, pull from the source library: organisational description, track record, governance, financials, staff. The tool reformats these to the funder's structure and word limits, and nothing here is invented because it all came from your own verified material.

In parallel, and this is the part that cannot be delegated, write the specific core. What is happening locally, to whom, and how you know. What your organisation has that others do not. What you will actually do. What will be different, and how it will be measured. What is hard about it.

Those two streams merge into a draft, which a person then reads for the one question that decides everything: does this say something only we could say.

And note where the time goes under this arrangement. Less on formatting, more on evidence and fit, which is where the decision is actually made.

flowchart TD
A["Funder priorities and history"] --> B["Honest fit assessment: apply or not?"]
B --> C["No: do not submit"]
B --> D["Source library: org description, track record, governance, financials"]
B --> E["Written by you: local need, your advantage, outcomes, what is hard"]
D --> F["Tool reformats to structure and word limits"]
E --> G["Draft"]
F --> G
G --> H["Does this say something only we could say?"]
H --> I["Submit"]

5. Numbers in an application are promises

A hard rule that matters more in this sector than almost anywhere else, because of what happens afterwards.

Every number in a grant application becomes something you are accountable for. The people you said you would reach. The outcomes you said you would achieve. The budget you said it would cost. The proportion of income you said comes from other sources. Funders check these in reporting, and a gap between what you promised and what you delivered damages a relationship that took years to build.

Which means numbers cannot be generated, and this is stricter than the general calculator rule elsewhere in this catalogue.

Beneficiary numbers come from your own records, counted the way you will count them in the report. Be specific about what a number means: people reached, sessions delivered and individuals supported are three different figures and applicants routinely blur them.

Budget figures come from a real budget, built up from actual costs, including the overhead that funders increasingly accept you must recover.

External statistics about need come from the named source, checked at that source, with the year stated. A model producing a plausible statistic about deprivation in your area is producing something a reviewer who knows the area may recognise as wrong, and being wrong about your own community is disqualifying.

And projections should be stated as projections with their basis given. A funder is more persuaded by we expect around forty based on last year's forty-three than by a confident hundred with nothing behind it.

The underlying discipline. Write the number you will be able to report against, not the number that makes the application look strongest.

6. Outcomes versus activities

The distinction that most separates funded from unfunded applications, and where assistance genuinely helps because it is a structuring problem rather than an information problem.

An activity is what you do. An output is what that produces directly. An outcome is what changes for someone as a result. An impact is the longer-term difference.

We will run forty workshops is an activity. Two hundred people will attend is an output. Participants will be able to manage their own budgets is an outcome. Reduced financial crisis in the community is an impact.

Applicants overwhelmingly write activities and outputs, because those are what they control and what they can count. Funders increasingly ask for outcomes, because that is what they are buying.

The difficulty is genuine. Outcomes are harder to measure, take longer to appear, and depend on things outside your control. Which is why the credible move is not claiming a large one, but stating a modest outcome with an honest measurement method and being clear about attribution.

Where tooling helps. Working backwards from an activity to the outcome it plausibly produces. Distinguishing the four levels when you have muddled them, which most drafts do. Suggesting measurement approaches proportionate to your size. And checking that what you promise to measure is something you could actually collect.

What it cannot do is know what change your work actually produces, which is a question about your programme and your beneficiaries.

And a note on proportion. A small organisation should not promise population-level impact. A funder reading a modest, measurable, honestly attributed outcome from a small charity finds it more credible than a grand claim, because it demonstrates that the applicant understands their own scale.

7. Volume is the wrong response

The most tempting use of these tools in this sector is also the most damaging, and it deserves naming directly.

If an application takes a day to produce and now takes two hours, the apparent conclusion is to submit five times as many. Some organisations are doing exactly that, and funders have noticed.

Why it fails on its own terms. Success rates are driven by fit far more than by volume, and applications to funders you do not fit are rejected regardless of quality. Five poorly-matched applications produce fewer grants than one well-matched one, and they consume the relationship capital you have with each funder you approach badly.

What it does to the sector. If every applicant multiplies their submissions, reviewers face more applications for the same money, so success rates fall for everyone and assessment gets more superficial. Some funders have responded by tightening eligibility, requiring conversations before applying, or moving toward invitation-only rounds, all of which advantage organisations that already have relationships.

That last effect is worth sitting with, because it runs against the sector's interests. Tooling that appeared to level the field between large and small organisations can push funders toward relationship-based allocation, which favours the well-connected.

The better use of recovered time is the opposite of volume. Fewer applications, better matched, with more of the specific evidence that decides them. And time spent on the thing that most predicts success and is least automatable: talking to funders before applying, so you know whether it is worth applying and they know who you are.

One strong application to a funder who knows you beats ten to funders who do not.

8. Disclosure, and what funders are asking

Funders are beginning to ask about AI use in applications, and the sector has not settled on an answer. Some practical guidance.

What funders are actually worried about. Not that a tool helped with formatting. That the application misrepresents the organisation's capability, that the claims are not real, or that they cannot tell whether they are funding an organisation or a document.

So the honest position maps onto what this lesson has argued throughout. If the specific, evidential content is yours and the tool reformatted and tidied it, you have done nothing a funder objects to, and that is true whether or not they ask. If a tool produced the substance, the application misrepresents you, and disclosure is not the problem: the misrepresentation is.

Where a funder asks directly, answer honestly and specifically. We used it to adapt our standard organisational description to your word limit is a good answer. It is also verifiable against the application, which a vague answer is not.

And note the practical asymmetry. Funders can rarely prove a document was generated, but they can very easily notice that an application says nothing specific, and can check claims against your accounts and your public record. The exposure is not detection; it is emptiness.

One further point specific to this sector. If your application wins funding based on capability you do not have, the failure arrives during delivery, in front of beneficiaries who were promised something. That is a worse outcome than not getting the grant, and it is the strongest argument for keeping the substance honest.

Check your understanding

The lesson ends with a 5-question quiz. Take it in the player above to see your score.

  1. What is the largest single cause of grant rejection?
    • Fit with what the funder actually funds, usually decided before the prose is read closely
    • Poor writing quality
    • Insufficient application length
    • Missing supporting documents
  2. What is the sharpest tell of a generated application?
    • Excessive length
    • Everything is smooth, with no trade-offs, constraints or acknowledgement that anything is hard
    • Use of sector jargon
    • Absence of national statistics
  3. In the activity-to-impact chain, which is 'participants will be able to manage their own budgets'?
    • An activity
    • An output
    • An impact
    • An outcome
  4. Why should numbers in an application never be generated?
    • Funders run automated statistical checks
    • Application software rejects inconsistent figures
    • Every number becomes something you are accountable for in reporting, where funders check it
    • Generated numbers are always mathematically wrong
  5. Why is submitting far more applications a poor use of the time saved?
    • Funders limit applications per organisation
    • Success is driven by fit rather than volume, and mass applying pushes funders toward relationship-based allocation that favours the well-connected
    • Application portals throttle submissions
    • It increases the risk of factual errors

Related lessons

Business
beginner

Communications, Donors, and Running on Almost Nothing

Nonprofits carry the workload of larger organisations with a fraction of the staff. This lesson covers where tooling genuinely relieves that: supporter communications, donor operations, reporting back to funders, and the free-tier trap that puts beneficiary data somewhere it should not be.

8 steps·~12 min
Business
beginner

Knowing Whether It Worked, on a Small Charity's Budget

Every funder asks for impact and few organisations can afford real evaluation. This lesson covers what you can honestly claim, the biases that make feedback flattering, where AI genuinely helps with qualitative data at scale, and why generating impact claims is the one thing that ends an organisation.

8 steps·~12 min
Business
intermediate

Keeping Your Voice When the Machine Drafts

Generated prose has a recognisable register, and writers who lean on it converge toward it. This lesson explains why that happens mechanically, what voice is actually made of, how to use a model as an editor rather than a ghostwriter, and why the skill you lose is the one you needed.

8 steps·~12 min
Business
intermediate

Reporting, Writing, and Which One Is Actually the Job

Journalism and content writing look like writing jobs and are mostly not. This lesson separates reporting from composition, explains why AI compresses the second and barely touches the first, and covers the verification standard that makes fabricated detail a categorically different problem here.

8 steps·~12 min