Start with the outcome, then define the work
A proposal should give a client more than a reassuring summary of the project. It should let both sides picture what will be handed over when the work is complete. Begin with a short statement of the goal, such as creating a visual identity for a new product or redesigning a small business website. Then separate that goal from the work you will actually provide. The goal explains why the project matters; the deliverables define its boundaries.
Avoid relying on phrases such as “complete branding package” or “website design” without explaining them. Those phrases can mean different things to different people. Instead, name the outputs: for example, a primary logo, a secondary logo, a color palette, and a short usage guide. If the project has stages, show which outputs belong to each stage. This makes the proposal easier to review and gives later conversations a shared point of reference.
Describe each deliverable so it can be recognized
For every deliverable, answer a few practical questions: What is it? How many versions or pieces are included? What format will the client receive? Is the output intended for review, for publication, or for further development? A description such as “three social media templates delivered as editable design files” is more useful than “social assets.” Where relevant, specify sizes, pages, screens, or supported platforms, but only when those details are known.
Distinguish a concept from a finished asset. “Two homepage concepts for review” does not promise two fully built homepages. Likewise, a page design is not necessarily a coded page. If you will supply source files, say which ones; if you will supply only export-ready files, say that instead. Clear descriptions are not about making the proposal rigid. They help the client judge whether the proposed work meets their needs before either side commits time to it.
It also helps to describe the handoff. Will files be organized in a shared folder? Will the client receive brief notes on how to use them? A modest handoff description can prevent a finished project from ending with avoidable questions about where assets are or which version to use.
Put exclusions where they are easy to see
Exclusions are work that a client might reasonably associate with the project but that you have not included. A logo proposal, for instance, might exclude naming, copywriting, illustration, printing, and trademark searches. A website design proposal might exclude development, hosting, photography, and migration of existing content. Listing relevant exclusions is clearer than expecting a client to infer them from the deliverables list.
Keep the wording neutral. “Not included in this proposal: photography, copywriting, and website development” is direct without sounding defensive. If an excluded service could be added, you can say it may be scoped separately. Do not fill the list with every imaginable task; focus on likely points of confusion. Read the proposal from the client’s perspective and ask what they may assume is part of a “finished” result.
Check that exclusions do not contradict the promised outcome. If the proposal says you will deliver a ready-to-publish landing page, but copy and development are excluded, explain what “ready-to-publish” means or choose a more accurate description. A useful exclusions list clarifies the offer; it should not undo it.
Explain inputs, feedback, and scope changes
Some work depends on materials or decisions from the client. Identify those inputs alongside the deliverables: brand assets, product details, access to existing files, consolidated feedback, or approval from a named decision-maker. Say when they are needed and what may happen if they arrive late. This helps distinguish a change in the work from a delay caused by a missing input.
Define the feedback process in ordinary language. For example: “The fee includes two rounds of revisions to the selected concept. Each round begins when the client sends one consolidated set of feedback.” This tells the client how to participate and makes “two rounds” less ambiguous. You can also distinguish revisions to an agreed direction from a request to explore a new direction.
Finally, describe how requests outside the listed scope will be handled. A simple process is enough: discuss the request, confirm any effect on the fee or schedule, and agree on the change before doing the additional work. The proposal does not need to predict every possibility. It needs to give both sides a way to address surprises without treating assumptions as promises.
Review the proposal for mismatched expectations
Before sending, compare the project summary, deliverables, exclusions, schedule, and fee. Do they all describe the same amount of work? If the schedule mentions a presentation or handoff call, make sure it is clear whether that call is included. If the deliverables include five pages, check that the proposal does not refer elsewhere to an undefined “full site.” Small inconsistencies can create larger disagreements later.
A useful final test is to ask whether someone unfamiliar with your conversations could read the proposal and describe what the client will receive, what they must provide, and what would require a new agreement. If they could not, replace broad labels with concrete descriptions. A strong proposal does not have to be long. It has to make the work understandable enough for both sides to say yes to the same project.
