A proposal template for SEO and web development work in Uzbekistan
Proposals are skimmed and decided on in two minutes. Here is a structure that survives that reading, block by block.
Page one decides everything
Page one needs four things: the client's problem in their own words, what you propose to do, the timeline, and the total in UZS. Everything else is an appendix. If the client reads only this page, they should understand the whole offer.
State the problem as a quote from your conversation, not in your own terminology. 'We need a site that takes measurement requests and shows the catalogue' tells the client they were heard. 'Development of a corporate web resource' tells them they got a template.
Do not bury the price at the end. The client skips there first anyway, and hiding it reads as a lack of confidence in the number.
The scope block
Break work into stages with a deliverable each: research and structure produces a sitemap and wireframes; design produces mockups of key pages; development produces a working site on a staging domain; content produces copy and photography; launch covers analytics, markup and the move to the live domain.
Give each stage a duration in working days and state what you need from the client. The second part matters more: half of all schedule slips come from waiting on client content or approvals, and it is better fixed in writing up front.
List what is not included as its own section: populating the catalogue, photography, buying domain and hosting, accounting integrations — everything a client assumes is bundled. That list prevents more conflict than the rest of the document combined.
Presenting the price
Give three options rather than one: minimal, recommended and extended. Clients almost always take the middle, and having options shifts the conversation from 'is this expensive' to 'which of the three'.
Quote in UZS with a validity date. If part of the work is priced in another currency, say so plainly and state the conversion rate — ambiguity here resurfaces at invoicing.
Separate one-off and recurring payments into distinct lines. The client needs to understand that after launch the site costs money every month: hosting, domain, support, promotion.
The SEO block: what you must not promise
Do not guarantee rankings. Nobody controls the algorithm, so such a guarantee is either a lie or fine print about zero-volume queries.
Commit to what you will do, not to the outcome: how many pages get optimised, how many new texts, technical fixes, reporting and its cadence, and the client's access to Search Console.
Give forecasts as a range with stated assumptions: given the current state of the site and this volume of work, organic traffic growth is expected within this range after so many months. Next to it, list the conditions under which the forecast fails.
Terms and payment
Spell out payment: deposit, staged payments, final settlement. A 50 percent deposit with the balance on acceptance is standard locally, but the term belongs in the document, not in a verbal agreement.
State how many revision rounds each stage includes and how extra rounds are billed. Without it, design gets redone six times and the timeline slips by a month.
Record the handover of rights and access separately: domain and hosting registered to the client, source files and credentials transferred on final payment. This is what clients most often discover too late.
Format and length
Keep the proposal to six or eight pages. Forty-slide decks that open with company history go unread, and the offer gets lost inside them.
Send a PDF rather than an editable file, and mirror a short summary as text on Telegram, where decisions happen faster than by email. Three or four lines: what, how much, how long, link to the PDF.
Keep a master template and change only page one, the scope and the price per client. Rebuilding a proposal from scratch every time is unbilled hours.