How We Turned Seven Hundred Proposals Into One-Click Packets

On our first call in February, the founder of a grant consulting firm did some arithmetic out loud. One of his clients runs about seventy locations and wanted to apply for every program his firm offers. Multiply it out and that one client came to about seven hundred proposals.

His firm helps care facilities apply for public funding for programs that improve resident care. Every facility qualifies. The work, and the firm's value, is in producing applications that get approved, at volume, without mistakes.

Mail merge was the right tool until it was not

The person running the process had already done the hard thinking. She had turned every approved program into a template. She had built budget spreadsheets where you enter the facility count and the dates and every total calculates itself. She had an intake form that dropped the basic fields into the application automatically. Her best week by hand was about a hundred and fifty applications, on top of her normal job. She was also, by her own account, one of very few people who could run it start to finish.

Then the volume changed shape, and mail merge could not keep up. Mail merge fills in the blanks in one document. The work had stopped being about documents.

Applications are grouped by state, and no single application carries more than twenty facilities, because larger applications trigger an extra layer of approval. Each facility's administrator signs a letter of support once, and that signature has to land on every application in the facility's group. Budgets change with facility count and start dates. And someone has to know, at any moment, who has signed and who has not.

None of that lives in a document. It lived in her head and in a set of spreadsheets, which worked because she was the one holding it together. At seven hundred proposals for one client, that stops being a sensible thing to ask of anyone.

What we built

We wrote one principle at the top of the architecture before any code: data enters once, and everything else is generated from it.

So most of the build is databases. Facilities. Vendors. Programs, with each program's fixed content and budget template stored once. The state offices the applications go to. A copy of the relevant public dataset, synced every day, so a facility entered with a slightly different name still matches its official record and picks up its details. A portal where vendors onboard themselves.

The generator sits on top. Signature requests go to each administrator automatically, and the signed letters come back into the right record on their own. When a group is ready, one click produces the complete packet: application, budget and letters of support, zipped and ready to submit.

The speed is the obvious gain. The less obvious one matters as much: with the data in one place and the packet built from it, the process is designed so it no longer depends on one person remembering how it all fits together.

We delivered it in the middle of July. Their team is testing it now, starting with one real group of facilities.

What I cannot tell you yet

I do not have the after number, and I am not going to guess one.

The before we have is her best week by hand: about a hundred and fifty applications.

What we have is a demo, and the demo is fast. A demo runs on prepared data. A real Tuesday brings a new client whose facility list arrives in whatever format they happen to keep it in. The number that matters is simple: from opening the tool to having the zip file for a real group, against the same group done the old way. When I have it, I will publish it with the method.

I will also admit the thing we should have done better. We did not time the old process with a stopwatch before we built. We have her count, which is honest, and it is not a measurement. It is the advice I give every client, and we skipped it.

When to stop improving the document

Here is the test I would run on any process that is buckling under volume.

Pick one record, one customer or one facility, and count how many documents its name, address and details get typed into. If the answer is more than two, you do not have a document problem. You have a data problem wearing a document's clothes, and a better template will buy you weeks, not years.

Before you build anything, sit with the person who holds the process together and write down every rule they apply without thinking. How things get grouped. Who signs what. What has to happen before what. That list is the specification, and it is the part no developer can invent.

Then time the old way on a handful of real cases, this week, while the old way still exists.