Every document this business sends anyone is built out of one folder. Proposals, capability statements, contracts. One folder, thirteen fields, and a script that refuses to print a page with a hole in it.
If you run something and you still write your own proposals, usually at night, usually starting from the last one you sent, this is for you. The problem was never the writing. It is that you re-decide the price and re-decide the scope every single time, on your own, at eleven at night, having already decided both of them months ago.
The fix is one idea. Split the document into the part that never changes and the part that does. Almost all of it never changes. Once that part is written down, a call only has to fill the small block near the top.
What follows is not how mine works. It is how to build yours. Eleven prompts, in order, pasted cold into your coding agent. Every step tells you what you should have when it finishes, so you can tell a working step from a broken one.
Nothing is gated. Finish it and you have the system.
Write down what you sell, once
This is the file the whole thing leans on, and almost nobody has it. Not a brochure. The actual answer to what you sell, what is included, what it costs, and what you refuse to do.
Write the refusals down too. A list of what you will never take on is the fastest way to stop scope creep arriving through a proposal you wrote at midnight.
Create a file called what-we-sell.md in this project. Interview me for it. Ask one question at a time and wait for my answer before the next one. Do not write anything until you have asked all of them. 1. What do you actually sell? Not the category. The thing a client receives. 2. What is included every single time, no matter who buys it? 3. What do people always ask for that is not included? 4. Is there more than one way to buy from you? Describe each one, what it costs, and who each one is right for. 5. What do you refuse to do, even for money? Push me for at least three. 6. What do you promise? If you guarantee something, what exactly, and what happens if it does not land. Then write the file. Use my words, not marketing words. Where my answer was vague, write what I said and put a line under it saying it needs sharpening, rather than smoothing it over into something that sounds finished. Show me every place you could not get a straight answer out of me.
read it back and find the sentence you would be embarrassed to send a client. That sentence is the one you have never actually decided.
Decide the price once, not per deal
Pricing inside a proposal is how you end up charging different numbers for the same work depending on how the call went and how much you liked them.
Take it out. Put the prices in their own file, and let the document choose one rather than invent one.
Add a section to what-we-sell.md called prices. Ask me what each way of buying costs, what triggers moving from one to the next, and how payment is split. If I have ever discounted, ask me what the real floor is and write that down as the floor. Then write a short rule for choosing between them, in plain English, that someone who is not me could follow from reading a call transcript. If two of my prices overlap so much that the rule cannot pick between them, say so plainly and tell me which two. Do not invent a rule to paper over it.
hand the rule and a past deal to your agent and ask which price applies. If it has to ask you, the rule is not written yet.
Get the call out of your head
Your memory of a call four days later is a summary of a summary. The words they used are worth more than your notes about the words they used.
Whatever records your calls is fine. Granola, Fathom, Otter, Fireflies, Notion AI, the recording your video tool already makes. The only thing that matters is that the transcript lands somewhere a file path can reach without you copying and pasting it.
Set up a place for call transcripts to land, and tell me how it works in three sentences. Ask me where my calls are recorded today, and whether that tool can export or sync a transcript automatically. It is probably Granola, Fathom, Otter, Fireflies or Notion AI. If it can, wire it up. If it cannot, tell me straight rather than building something clever around it, and give me the smallest manual step that works. Then write a script that takes one transcript and pulls out only these things: - who was in the room and what they do - what they said is going wrong, in their words, quoted exactly - what they said they have already tried - anything they said about budget, timing, or who else decides - every question they asked me Anything the transcript does not contain, it writes as unknown. It never fills a gap with something plausible. Run it on a real transcript and show me the output next to the transcript.
every quote in the output appears word for word in the transcript. If one is close but not exact, stop and fix that before going further.
Give it everything you have already sent
Here is the part almost nobody builds, and it is the one that makes a proposal land.
A prospect does not want to know that you are good. They want to know you have done this exact thing before, for someone who looked like them. You already have that proof. It is scattered across old proposals, finished projects, a testimonial in an email, a number in a spreadsheet, and none of it is anywhere the work can reach.
So: one folder. Everything you have ever sent, everything that worked, and what it was worth. Then the filler picks the right one for this prospect instead of you remembering it at eleven at night.
One thing worth knowing before you build it. Searching this folder by keyword does not work, and it fails quietly. A prospect says they are drowning in reporting, your best case study says "monthly board pack", and a keyword search over your own folder returns nothing at all. It has to search by meaning.
Build me a folder of everything I have already sent, and a way to search it by meaning. First, ask me where these live and go and read them: - every proposal I have sent, won or lost - finished work: what the client had before, what changed, how long it took - anything a client wrote back that was positive, in their words - any number I am allowed to quote, and who said it Write one short file per piece of work, all the same shape: who they were, what industry, what size, what was wrong, what we did, what changed, what it cost, and one line I am allowed to quote publicly. Mark every single one as either public, name-removed, or private. Ask me for each. Never guess this, because using a client's name without permission is worse than having no case study at all. Then set up search over that folder that works on meaning rather than exact words, so that asking for "they are drowning in reporting" finds the board pack project. Use whatever is smallest and runs on my own machine. Tell me what you chose and why. Test it in front of me: give it three phrases a prospect might actually say, and show me which piece of work comes back for each.
search it for a problem in words you have never written down anywhere. If the right project does not come back, it is matching keywords, not meaning, and it will fail on a real prospect.
Split the document in two
This is the step that does the work, and it is the one nobody does.
Open your last three proposals side by side. Almost everything in them is identical. The same explanation of how you work, the same reason you are worth it, the same terms. Only a small block near the top is actually about the client.
That small block is the only part a call should ever fill.
Read my last three proposals. I will point you at them.
Produce one document with two clearly separated parts:
- the standing part: every sentence that was the same, or nearly the same, in all three.
Where they differed only in wording, pick the best version and use it everywhere.
- the part that changes: a short list of the specific things that genuinely differed per
client, with a name for each one.
Then tell me the ratio. How much of the page never changes, and how much does.
If you find something in the standing part that reads badly for every client rather than
just one, say so. A line that is wrong in all three proposals is not a personalisation
problem, it is a line that needs rewriting once.
Do not write any new marketing copy. Everything in the standing part has to come from
something I already sent someone.the list of things that change should be short enough to fit on one screen. If it runs to twenty items, you are personalising things nobody reads.
Make it look like a company sent it
Two jobs here, and the second one is where most people give up and send a Word file.
It has to survive the trip. A proposal gets forwarded, downloaded, opened on a phone, and printed by someone you have never met. So the styling goes inside the file and the logo goes inside the file as encoded text. One file, nothing beside it, nothing to go missing.
It has to look typeset rather than printed from a browser. That comes down to about ten specific decisions, and the reason to write them into their own file is that documents drift. Two of ours were written two hours apart and had already diverged: two different blues, two body sizes, spacing steps of 12px in one and 14px in the other. Nobody saw it because nobody put them side by side. Numbers live in exactly one file or they do not stay the same.
The prompt below carries the actual settings. Change them to suit you, but keep the shape: one small set of values, defined once, used everywhere.
Build the document template from the standing part in step 5, plus one shared stylesheet
that every document I ever send will use.
Put these in the stylesheet and nowhere else. A template may add its own components on top
and must never redefine anything in here.
- One ramp of greys, used in this order and no other: body text, secondary text, labels
and page furniture, hairlines inside a block, borders between blocks.
- Exactly one accent colour. Not two.
- Exactly six spacing values, and every vertical gap in every document is one of them.
Start from 4, 8, 14, 20, 30 and 44 pixels. An ad-hoc 7 or 22 is what makes a page feel
homemade, because the eye reads the inconsistency before it reads the words.
- Exactly five or six type sizes, no more. Start from 24pt for the title, 13pt and 10.6pt
for headings, 10.3pt body, 9.4pt small, 7.8pt for footers and labels.
- Body line height 1.58. Never fewer than three lines left at the foot of a page and never
fewer than three carried to the top of the next one.
- A4, with equal left and right margins around 20mm and a deeper foot around 24mm to hold
the running footer. The same on every document, so two of them stack on a desk and line up.
- One typeface, with a plain system fallback list behind it so it still reads if the font
never loads.
Then the pagination rules, which are the whole difference between a typeset document and a
printed web page:
- a heading is never the last thing on a page
- the first paragraph under a heading cannot be separated from it either
- where a heading is followed by a tall block such as a table or a card grid, wrap the
heading together with that block so the three move to the next page as one. Binding a
heading only to the element immediately after it does not cover this case, and it is the
one that actually looks like a mistake.
Two hard rules for the template itself:
- the stylesheet is inlined into the finished file at render time, never linked
- the logo is embedded as encoded text, never linked from a website
Explain both in a comment: this document gets forwarded and printed by people who are not
on my network, and anything loaded from elsewhere is missing when they open it.
Where a value gets filled in later, mark it with a name in double curly braces, and use that
syntax for nothing else in the file.
Set up page numbering that reads page X of Y. Tell me if the tool you picked cannot do that
and what you used instead, rather than quietly dropping it.
Render it and show me a screenshot before I read any code.move the file to another folder, open it, print it to PDF. Nothing missing, nothing unstyled, and no heading stranded at the bottom of a page.
Build the filler
Now the small piece that joins it all up. It reads the call, reads what you sell, reads the prices, and fills only the block that changes.
Keep it boring. It fills blanks. It does not compose.
Write a script that takes the extracted call from step 3 and produces a finished document. It reads what-we-sell.md for the offer and the prices, uses the rule from step 2 to pick which price applies, and fills only the fields marked in the template from step 6. It also searches the folder from step 4 and picks the ONE past piece of work closest to what this prospect described, then writes it in using their own framing of the problem rather than mine. One, not three. A wall of case studies reads as a brochure and nobody finishes it. If nothing in that folder is a genuine match, it says so and leaves the proof block out. It never stretches a loosely related project into a claim, and it never uses a client marked private or uses a name where the mark said name-removed. It writes the fields into a separate small file first, so I can read and correct them before anything is rendered. Show me that file, then render. It never writes a new section, never rewrites a standing paragraph, and never changes a price. If it thinks a standing section is wrong for this client, it prints a note to me and carries on with the standing version. Explain that last rule in a comment. If a standing section keeps needing changes for one reader, either that section is wrong for everyone, or this is not a standard deal and I need to know that before it goes out.
run it on two different transcripts. Diff the two outputs. The only differences should be inside the block you named in step 5.
Make it refuse
The worst thing this system can do is not a bad proposal. It is a proposal that goes out with a hole in it, and neither of you notices until they read it.
So it refuses. An empty field stops the whole thing. A leftover blank stops the whole thing. Sending nothing is recoverable. Sending a page with someone else's company name in it is not.
Add two hard guards to the filler from step 7, and make both of them stop the run rather
than warn.
- if any required field is empty, it refuses to render and names every empty one
- after filling, it scans the finished file for any leftover blank markers, and refuses
if it finds one
Neither guard writes an output file when it fires. A half-rendered document sitting on disk
is how the wrong version gets sent.
Add a comment saying why this is a refusal rather than a warning: a blank reaching a client
is the worst thing either of us can do, and a warning is something you skim past at eleven
at night.
Prove both guards by deliberately breaking the input twice, and show me both refusals.delete one value from the fields file and run it. You should get a refusal naming that exact field, and no output file.
Write the test that stops you embarrassing yourself
Every business has facts that must never be wrong on a client document. An old office address. A previous company name. A client you are not allowed to name. A price you retired.
Those are not style preferences. They are the things that cost you a deal or a relationship, and they come back the moment somebody copies an old file to save time.
So write them down as a test that fails.
Write a self-test for the document system. Ask me for the things that must never appear on a document I send, and push me until I have given you at least four. Prompt me with these kinds if I stall: a retired address, a former company or employer name, a client under a confidentiality clause, an old price, an old logo, a former partner. Then ask me what must ALWAYS be correct and present: my current registered details, my current logo, the right contact person. Write a test that renders a sample document and fails loudly on any of them. Each check gets a message saying what is wrong in plain words, not a line number. Explain in a comment next to each one why it exists, in my words. A test with a reason attached survives. A test that just fails gets deleted by the next person who is in a hurry. Run it and show me the output.
temporarily put your old address into the template. The test must fail, and the message must tell you what is wrong without you reading the code.
The edit pass, which is yours
The document that comes out is a first draft that already knows the facts. What it cannot do is decide.
What they actually need rather than what they asked for. What to cut so the price is believable. What to say no to. That is the hour worth having, and it is the only hour left.
Add a short checklist at the end of the run, printed to the screen, not into the document. It reminds me to make these calls before anything goes out: - is the thing they asked for actually the thing they need - what should be cut so this lands as one clear piece of work - is there anything in here I should refuse - does the price match what I would say out loud on a call Draft that checklist by asking me what I have changed by hand in my last three proposals. Build it out of my actual edits, not out of general advice. It never edits the document itself.
run the whole thing, then time your edit. If it takes more than about an hour, look at what you changed. Anything you change every time belongs in the standing part.
The contract that follows
The proposal gets agreed and then the paperwork starts from a blank page again. Same job, same rule.
One contract body that never changes, one short attachment per way of buying, and a fixed list of blanks. An empty blank is a blocker, never a guess.
Build the contract the same way as the document. One body that stays the same for every deal, and one short attachment per way of buying from step 1, naming what gets delivered under that one. Then write the fixed list of blanks that has to be filled before it can be produced, and where each one comes from. Two rules go in as comments: - an empty blank stops the run, it is never filled with a best guess - the date comes from the actual clock at the time of running, never from memory Ask me whether my clients are in more than one country or currency. If they are, ask which follows the client and which follows me, and write the answer down rather than converting anything. I am not asking you for legal advice and you should not give me any. Build the filling machinery and leave the words to my lawyer.
try to produce one with a blank left empty. It should refuse and name the blank.
What this will not do for you
- It will not write your offer for you. Step 1 is an interview, and if you cannot answer it out loud, no tool downstream fixes that. That is the real work and it is the reason most people stop here.
- It will not make a weak proposal win. It removes the retyping. Whether the thing you are selling is worth the money is the same question it was before.
- It will not give you legal cover. Step 10 builds the machinery that fills a contract. The words in that contract are between you and your lawyer.
- It will not judge the deal. It fills a page from things you already decided. What they actually need, what to cut, what to refuse, all of that is still an hour of your attention and it should be.
- It will not have a case study for everyone. Step 4 can only find what you have actually done, and it is built to say so and leave the proof block empty rather than stretch a loose match into a claim. That is the correct behaviour and it will feel like a bug the first time it happens.
- It will not pay off on your first proposal. Steps 1, 2 and 4 are most of the work and none of them feel productive. The return starts on the second one and it does not stop.
Don't want to build it yourself?
One working session and it is running. We set it up inside your own coding agent,
Book a call