AI Prompts for Grant Writers and Nonprofits: Needs Statements, Logic Models and Funder-Fit Checks

The call for proposals closes in nine days. You have last year's application, a spreadsheet of programme numbers that three people have edited, and a funder whose guidelines run to forty pages. Nobody has time to start from a blank page, and the temptation is to ask an AI for "a compelling needs statement for a youth literacy programme" and paste what comes back.

Don't. What comes back will be fluent and specific-sounding, and parts of it will be made up. The grant writing prompts below are built around one rule: the model writes and checks, but every fact comes from you, with a source. An invented outcome in a proposal is a credibility problem with the funder and, if it gets funded, a reporting problem later.

These are untested templates. I haven't run them on a live application. The examples are invented and labelled as such. Funder rules change every cycle, so I haven't stated any funder's requirements as fact, apart from the one federal-registration check described below; I'll show you how to pull the rules out of the guidelines you have instead. This post doesn't cover freelancer proposals for paying clients; for that see AI prompts for consultants and freelancers. For donor emails after the grant is won, see AI prompts for nonprofit fundraisers.

How do I check a funder's fit before I write anything?

The cheapest hour in grant writing is the one you spend deciding not to apply. Paste the funder's guidelines (public text) and your organisation's profile, and ask for a fit check that cites the guidelines.

You are helping a nonprofit decide whether to apply for a grant.

FUNDER GUIDELINES (the only source for funder rules):
[PASTE the call for proposals / notice of funding opportunity text]

OUR ORGANISATION (the only source for our facts):
- Legal status and registration: [..]
- Mission: [..]
- Programme we would fund: [one paragraph]
- Geography served: [..]
- Annual budget band: [..]
- Years operating: [..]
- Registrations held (for example any unique entity ID required): [..]

Produce a table: Requirement | What the guidelines say (short quote) |
Do we meet it? (Yes / No / Unclear) | Evidence from our facts.

Rules:
- Only list requirements that appear in the guidelines. Quote the words.
- If the guidelines are silent, write NOT STATED. Do not use general
  knowledge of what funders usually require.
- Do not guess our status. If our facts do not cover it, write UNCLEAR and
  say what we need to find out.
- End with: eligibility blockers, deadlines and format limits (page,
  word or character counts) in one list, each with its quote.

The "NOT STATED" rule is the control. Without it, the model blends this funder's rules with what funders generally want, and you can't tell which is which. Keep the quotes and verify them against the original document. They are your checklist for the final read-through.

One check from a primary page, so you know the extraction habit has a point. On 2026-10-09 I read the Grants.gov grant terminology page (grants.gov/learn-grants/grant-terminology; confirm the wording there, as it changes). It says a non-federal entity is required to have a Unique Entity Identifier (UEI) to apply for, receive and report on a federal award, and that the UEI is obtained from SAM.gov. That's a classic blocker: registration takes time, and the model will only warn you if your prompt includes "registrations held". I could not get a readable answer from the Grants.gov registration pages on how long SAM.gov registration takes, so I'm not stating a timeline. Check SAM.gov and start early.

How do I write a needs statement without invented statistics?

A good needs statement does three things: names who is affected, shows the size of the problem with sourced evidence, and explains why existing provision isn't enough. Only the second part is dangerous. So separate evidence-gathering (you) from prose (the model).

Build an evidence table first:

ID | Claim | Number | Source (title, publisher) | Year | Link or file
E1 | Children below grade level in reading | [..] | [..] | [..] | [..]
E2 | Our waiting list | [..] | Our records | [..] | [file]

Then prompt:

Write a needs statement of about [300] words for a funder reading this
section as [criterion text from the guidelines].

EVIDENCE TABLE (the only permitted facts, quote numbers exactly):
[PASTE]

COMMUNITY CONTEXT in our words (not evidence, do not turn into statistics):
[PASTE short description]

Rules:
- Every number gets its ID in brackets, for example [E1].
- Any claim that needs a number but has none: write [EVIDENCE NEEDED: what].
- No statistic that is not in the table. No named studies, quotes or
  reports that are not in the table.
- Describe people with dignity: no deficit language, no stock stories
  about "at-risk" communities. Use what community members say about
  their own situation only if I supplied the quote and permission.
- After the text, list each [ID] used and each [EVIDENCE NEEDED].

Check the ID list against the table. If a number appears without an ID, the model has gone off-script; delete it. If there are three [EVIDENCE NEEDED] flags, that is the research task for the week, and it's better known now than at review stage.

How do I build a logic model from a programme description?

A logic model is a picture of how your programme is supposed to work. The W.K. Kellogg Foundation's Logic Model Development Guide (updated January 2004; I read the PDF text on 2026-10-09, from a NACCHO-hosted copy because the Foundation's own resource page returned 404 that day) defines the basic model as five parts: resources (also called inputs), activities, outputs, outcomes and impact. In that guide, outputs are the direct products of activities (types, levels and targets of services), and outcomes are specific changes in participants' behavior, knowledge, skills, status and level of functioning. It gives short-term outcomes as attainable within 1 to 3 years and longer-term outcomes within 4 to 6 years, and describes impact as change in organizations, communities or systems, within about 7 to 10 years. Those time frames are that guide's convention. Your funder may use different ones or its own template, so use the funder's format when it supplies one.

The most common error is putting an output in the outcome column ("50 workshops delivered"). A workshop count is an output. An outcome would be a change in participants. Ask the model to do the sorting and challenge you.

Draft a logic model for this programme using these columns:
Resources | Activities | Outputs | Short-term outcomes | Longer-term
outcomes | Impact.

PROGRAMME DESCRIPTION (only source):
[PASTE: who, what we do, how often, how many people, staff, partners]

Rules:
- Outputs are things delivered and counted (sessions, people served).
  Outcomes are changes in people (knowledge, skills, behaviour, status).
  Put each item in the right column and tell me if I described an
  outcome as an output or the reverse.
- Do not add activities, partners, numbers or targets that I did not state.
  Write [TARGET NEEDED] where an output or outcome needs a number.
- For every outcome, give an indicator (how we would know) and a data
  source (who collects it, how). Mark the ones where we have no data
  collection in place as [NO DATA SOURCE].
- List the assumptions the "if... then..." chain relies on.

Every [NO DATA SOURCE] is something you'd be promising to measure and can't yet. Fix that or lower the promise before the funder does it for you.

How do I draft outcomes and evaluation without making promises I can't keep?

Overpromising is the quiet failure in grant writing. The model will happily write "participants will improve their reading by two grade levels" if you hint at ambition. Give it your real baseline and a rule.

We need outcome statements for [PROGRAMME].
OUR REAL DATA (only source): [past results with numbers and years, or
write NONE if this is a new programme].
Funder's required outcome language (if any): [PASTE]

For each outcome write: the outcome statement, how it will be measured,
when, and the evidence this target is realistic (cite my data by label).
If I have no past data, do not propose a numeric target. Write
[TARGET: to be set from baseline in the first [N] months] and suggest how
to measure a baseline.

New programmes can legitimately say "we will establish a baseline". Funders generally know that; claiming a precise lift with no evidence is the riskier choice. I haven't checked what any particular funder prefers, so read their guidance on evaluation and ask them if it's unclear.

How do I use AI to review my draft like a funder would?

This is the best use of the model in the whole process, because it reads against criteria without being tired or attached to your sentences.

Act as a reviewer for this funder. SCORING CRITERIA (verbatim, with
weights if given):
[PASTE]

OUR DRAFT:
[PASTE]

For each criterion: a score from 1 to 5 as a reviewer might give, the
sentence(s) in the draft that earn it (quote), what is missing, and the
single change that would most improve it. Then list:
1. Claims with no evidence or source.
2. Places where the draft and the budget disagree (numbers, staffing).
3. Jargon a non-specialist reviewer would stumble on.
4. Anything that reads as a promise we cannot evidence.
Do not rewrite the draft. Do not add facts.

The scores are the model's opinion, not the funder's; use them to rank where to spend your remaining hours, not to predict results. The budget cross-check often catches the real errors: a coordinator at 0.5 FTE in the narrative and 1.0 in the spreadsheet is the kind of thing that surfaces in due diligence.

A worked example (illustrative)

An invented organisation, "Riverside Reading Circle", runs after-school reading sessions for 40 children. Their records show 31 of the 40 children attended at least 20 of 24 sessions last year, and teachers' end-of-year survey (their own, invented here) had 22 of 29 responding teachers marking "more willing to read aloud". They have no test-score data.

A correct reply to the outcome prompt would look like:

Outcome 1 (short term): Children attend regularly. Measure: sessions
attended per child. Evidence: 31 of 40 attended 20+ of 24 sessions [R1].
Outcome 2 (short term): Children are more willing to read aloud. Measure:
teacher survey. Evidence: 22 of 29 respondents [R2]. Note: self-reported
by teachers; not a test of reading level.
Outcome 3 (longer term): Reading level improves.
[TARGET: to be set from baseline] [NO DATA SOURCE] - propose a
standardised assessment at entry and exit.

It refuses to promise a reading-level gain it can't evidence, flags the survey's limits and proposes a baseline. That's a less glamorous paragraph than the one a model writes unprompted. It is also the one that survives a reviewer's question.

Where this goes wrong

What not to automate

• The facts. Outcomes, numbers, budgets, quotes and community data come from your records, with sources.
• Eligibility decisions. The model flags; the person who signs the application confirms with the funder if unsure.
• The budget. Do the arithmetic in a spreadsheet; use the model only for narrative around it.
• Beneficiary stories. Use real stories only with the person's informed consent. Never ask a model to make up a representative case and present it as real.
• Funder relationships. A program officer's email deserves your voice and your judgement.
• Compliance statements and certifications. Read and sign them yourself. Some funders have rules on AI-generated content in applications, so look for that in the guidelines and follow it.

For why the "use only these inputs" pattern works, read avoiding hallucinations, and how to fact-check AI answers is a checklist to run over any draft's numbers. Giving context explains why your programme description matters more than the instruction, and the prompt library has more templates you can copy.