An organization submits one big application to one big foundation and freezes, waiting. For three months, the organization's whole life is tied to one letter that will eventually arrive. The rejection comes, and with it a feeling that the entire quarter was wasted.
The problem wasn't the rejection, rejections are normal. The problem was that a single application was everything at stake. An organization running twelve attempts at different stages at once experiences the same rejection as an ordinary Tuesday, not a quarterly disaster.
A grant pipeline is your short list from researching foundations, turned into a living table of statuses: which foundations are in research, where an LOI has been sent, where a full application is being written, where you're waiting on a decision, where an answer has arrived. Fundraising isn't a series of one-off heroics, it's a steady stream of attempts at different stages all at once.
The pipeline has stages, and it's genuinely a funnel: many foundations go in, few make it all the way through. The research stage, where a foundation is studied but no contact has happened yet. The LOI-sent stage. The full-application-in-progress stage. The awaiting-decision stage. And the final states: grant received or rejected.
An important numerical expectation follows from the funnel: conversion is low, and that's normal. Out of twelve attempts at the research stage, only a handful will reach a grant, not most. Anyone expecting success from every application lives in constant disappointment. Anyone who understands the funnel calmly keeps enough foundations in the pipeline to reliably produce grants at the output.
A healthy pipeline runs on rhythm: something enters research every month, something goes out as an LOI, something gets finished into a full application. This is a steady flow, not a once-a-quarter scramble against a deadline discovered at the last minute.
Rhythm is exactly what turns grant work from stress into routine. When the pipeline always has attempts at every stage, a single rejection doesn't collapse the whole plan, and the next deadline doesn't catch you off guard. Rejections stay in the table for a reason: a foundation that said no this year often becomes a realistic target next year, and there's a separate conversation about those relationships in Module 11.
A pipeline only works if it's alive. A table filled in once and abandoned is useless: its value is in regularly updating statuses, at least once a week or two. Every row is a foundation, every column answers a specific question: what stage, what deadline, what amount, who's responsible, when's the next action.
The next-action column with a date is especially important. That's exactly what turns a passive list into a working tool: you always see what needs doing this week and for which foundation, instead of trying to hold it all in your head.
Below is a grant pipeline table with filters by stage and deadline month. It's built from your short list of foundations and becomes the main operational document for all grant work.
Your organization's grant pipeline for the coming twelve months, built from the short list of foundations in researching foundations. This is the operational center of all grant work: LOIs from your letter of inquiry, logic models from 10.3, and budgets from 10.4 all feed into it, tied to specific foundations. Keep it alive, update it weekly, and grant work stops being a string of scrambles.
How many foundations should be in the pipeline at once?
Usually around ten to twelve at different stages. Enough that a single rejection doesn't wreck the picture, but not so many you can't attend to each attempt carefully.
What counts as a normal pipeline conversion rate?
Low: out of a dozen attempts, only a handful reach a grant, and that's expected. That's exactly why it's important to keep enough foundations entering the funnel, rather than counting on every application to succeed.
Should rejected foundations stay in the table?
Yes, absolutely. This year's rejection often becomes a realistic target next year, and the history of contact helps build relationships (Module 11). Deleting them means losing valuable context.
How often should the pipeline be updated?
At least once a week or two. The table's value lies exactly in the accuracy of statuses and the next-action column. An abandoned pipeline quickly turns into a useless list.
That closes out the module on grant writing as engineering: you can read an application through a grantmaker's eyes, write an LOI, build a logic model, put together a budget, and run all of it as a flow through a pipeline. But there's a person behind every application, and decisions often get made not by the text, but by the relationship. Next, the course moves to what turns a cold application warm: relationships as currency.