Create a proposal your client can understand.

The fields above are deliberately plain, but what you put in them decides how good the finished document is. A proposal built from three vague sentences will read like three vague sentences with better typography. The notes below cover what to write in each part and why it matters to the person reading it.

Give clear project information

Start with the facts you would give a colleague who is picking up the job from you: who the client is, what they do, what prompted the conversation, and what they said they wanted. The project description is the most valuable field on the page, because everything downstream is written from it. Two or three paragraphs of specifics beats a single line every time — mention the industry, the current situation, any constraints such as a fixed launch date or an existing system that must keep working, and any preferences the client has already expressed.

The client goals field deserves separate thought. A goal is not “a new website”; that is a deliverable. A goal is “stop losing enquiries because the current contact form is broken on phones” or “make it possible for the team to publish case studies without asking a developer”. When goals are written this way, the proposal can be framed around outcomes, and the client sees their own problem described back to them accurately, which is the single strongest signal that you were listening.

Define the scope

Scope is the boundary around the work. Use the services field to say what kinds of work are included, then use the additional notes to record what is deliberately excluded. Exclusions feel awkward to write and save an enormous amount of trouble: content writing, photography, translations, hosting costs, third-party licences, integration with a system you have not seen, and ongoing maintenance are all things clients routinely assume are included when nobody said otherwise.

It also helps to name what the client is responsible for. Most delays in service projects are caused by something the client owes you — access to an account, a decision from a stakeholder who is on holiday, copy that has not been written. Writing those dependencies into the proposal is not defensive; it tells the client what they need to prepare, which makes the project start faster.

Describe deliverables precisely

A deliverable is something the client receives and can point at. “Brand work” is not a deliverable; “a primary logo with two lockups, a colour palette, a type scale, and a six-page usage guide supplied as PDF, SVG, and PNG” is. Write one deliverable per line in the deliverables field, and include quantities and formats wherever they apply — number of pages, number of revisions, file types, number of reports per month.

Precision here does two jobs. It gives the client a concrete sense of value, because a list of specific items reads as more substantial than a paragraph of description. And it gives both of you a shared definition of “finished”, so the end of the project is a fact rather than a negotiation.

Set realistic timelines

Put the overall duration in the timeline field and the internal structure in milestones. Milestones are more useful than a single end date because they show progress and create natural review points: discovery complete, first designs presented, feedback consolidated, build complete, launch. If a stage depends on the client, say so next to it, and state the assumption the schedule rests on — for example that feedback arrives within three working days.

Resist the urge to quote your best case. A schedule you can hit builds more confidence over the life of a relationship than a schedule that impresses at signature and slips in week two. If part of the timeline is genuinely uncertain, describe it as a range and explain what would narrow it.

Explain pricing plainly

Use the pricing field to show how the number is composed: a fixed project fee, phases with individual prices, a monthly retainer, or a day rate with an estimated number of days. Clients rarely object to a price they understand; they object to a price that appears from nowhere. Where an element is variable — media spend, third-party licences, print costs — list it separately so it is clear it sits outside your fee.

Payment terms belong in their own field for the same reason. State the deposit, the schedule of remaining payments and what triggers them, the invoice terms, and anything relevant about expenses or late payment. Being direct about money in the proposal is far easier than raising it for the first time when an invoice is already overdue.

Review the generated content

When you generate a proposal, the AI arranges your information into the sections of the template you picked and writes the connecting language. Treat that as a first draft. Read it line by line and check three things in particular: that every claim about your business is true, that every number matches what you intended to charge, and that nothing has been asserted about the client that you did not actually establish on the call.

Generated text can be confidently wrong. It may smooth over a gap in your input with a reasonable-sounding sentence, or use a phrase that is not how you would describe your own work. Every section is editable individually in the editor, and you can ask the AI to rewrite a specific part rather than regenerating the whole document, which is usually the faster way to fix a section you do not like.

Personalise the final version

The last pass is what separates a proposal from a form letter. Add a sentence that could only have been written for this client — a reference to something specific they said, a constraint you are designing around, a risk you noticed and have already planned for. Swap in the case study that most resembles their situation rather than the one you are proudest of. Check that the tone matches the client: a two-person studio and a procurement department want different documents.

Then finish with an unambiguous next step. Say exactly what you would like the client to do, who to contact, and what happens once they agree — when work would start, what you will need from them first, and how long the pricing holds. A proposal that ends with “let us know your thoughts” invites delay. One that ends with a clear instruction gets answered.