Build it around the decision they have to make
A proposal asks for a yes, so organize it around what the reader needs in order to give one. A well-built proposal spells out the objective, the scope, the timeline and the budget, so nobody has to dig through old emails to find them.
Tailor the opening to the client’s needs rather than your own history. Name their situation first, then say what you’ll do about it.
Two additions are worth considering: a short list of what is not included, and one next step with a date. Neither is a formal rule. Both answer questions the reader would otherwise have to ask.
A filled-in example: an on-site bike repair pilot
The sample on this page is a fictional proposal from a mobile bike mechanic to a coworking space that wants to offer members tune-ups at work. Every name, price and date in it is invented.
Three choices in it are worth copying. The ask comes first, in two sentences, before any detail. Each price sits beside what it covers, so the total never floats free of its reason. And the commitment is a single pilot day with a review date, which gives the reader a small yes instead of a yearlong one.
Headings, short lists and a table keep it easy to scan, which helps when the reader forwards it to someone who wasn’t on the call. Swap in your own facts and the same order works for a service quote, an internal pitch or a class project proposal.
File or link? Follow the instructions first
If the request says PDF or Word, send PDF or Word. A bid, grant portal or course assignment may specify the format, and a link doesn’t meet that requirement.
Each route has a fair use. A word processor template is the shortest path when a DOCX is required. A design-tool template suits work where the visual layout carries weight. Hiring a writer can make sense for a high-stakes bid. A web page fits a different case: the reader asked you to send something over, a link is acceptable, and the details are likely to change after they read it.
Building yours with AI, if you want help with layout
An AI chat assistant can turn your notes into a single HTML file, the file type a browser opens as a web page. You supply the facts; it handles structure and styling.
The prompt below asks for that, plus the constraints that keep the page usable: readable on a phone, real headings for screen readers, enough text contrast, and [TBD] markers wherever a fact is missing instead of invented numbers. Replace everything in brackets. The bike-repair examples only show the level of detail that helps.
Before sending, check every date and figure against your notes. The AI can format a price, but it can’t know whether the price is right.
After you send it: fix the words, keep the link
Suppose the coworking manager in the fictional example replies that the pilot should move to May 2 and asks where the work happens if it rains. With a file, that means editing the source, exporting again and resending, and the reader now has two versions in their inbox.
If the proposal is an HTML page in NOS, you can edit the rendered text directly, changing the date and adding a rain-plan line without asking the AI to rebuild the page. The share link you already sent stays the same, so the manager reopens it and sees the new version. They don’t need an account to view it.
Text is what you can edit this way. If a page ever includes something that calculates, such as a running total, update and check those numbers yourself rather than assuming they adjust.
Start with what you already know: the objective, the scope, the dates, the price. Fill the brackets, check the numbers, and send the format the reader asked for.
A prompt to adapt
Create a one-page proposal as a single, self-contained HTML file. Put all CSS in one <style> tag. Do not use external scripts, fonts, images, forms, buttons that submit anything, or API calls.
My details (replace every bracket; the examples in parentheses are fictional and only show the level of detail):
- My business or role: [WHO YOU ARE, ONE LINE] (example: a mobile bike mechanic who services bikes on site)
- Reader: [CLIENT OR APPROVER AND THEIR SITUATION] (example: a coworking space that wants to offer members tune-ups at work)
- Objective: [WHAT THE READER WANTS TO ACHIEVE]
- Scope, what I will do: [LIST]
- Not included: [LIST]
- Timeline: [DATES OR PHASES] (example: confirm by March 28, tune-up day April 18, review call April 25)
- Price: [LINE ITEMS WITH AMOUNTS AND THE TOTAL EXACTLY AS I WANT IT SHOWN]
- Reader provides: [SPACE, ACCESS, CONTACT PERSON, ETC.]
- Next step and deadline: [E.G., REPLY TO CONFIRM BY DATE]
- Contact: [NAME, EMAIL, PHONE]
Structure, in this order: a two-sentence summary of the ask, objective, scope, not included, timeline, price table with total, reader responsibilities, next step, contact.
Rules:
- Use only the facts above. Where something is missing, write [TBD]. Do not invent testimonials, past results, client names, statistics or credentials.
- Show prices and the total exactly as I give them. Do not calculate new figures.
- Plain, direct sentences. No slogans or hype words.
- Mobile: the page must read cleanly at 375px wide with no sideways scrolling of the page; on narrow screens let the price table scroll inside its own container or stack each row.
- Accessibility: exactly one h1, headings in logical order, a real <table> with <th> header cells and a caption for the price, body text at least 16px, text contrast of at least 4.5:1, and no meaning carried by color alone.
- Return only the complete HTML code, nothing else.