How to Write an IT Services Proposal and Fixed Price Quote

A proposal is a summary of agreement

A strong proposal should contain no surprises. It confirms what you and the buyer already discussed: their problem, the outcome they want, your approach, the scope, the timeline and the price. If the buyer is seeing your price or approach for the first time in the document, you sent it too early. Before writing, check that you have enough from discovery to fill each section. If not, schedule a short call to close the gaps. Write for the person who was not on the call. Often the economic buyer, a partner or a finance head reads the proposal without context. Use plain language, short paragraphs and the buyer's own words for the problem. Keep it as short as it can be while still being clear.

Structure of a good IT services proposal

Most proposals can follow the same order. Lead with the buyer's situation, not your company profile. Put your credentials later, and keep them relevant: one or two similar projects matter more than a long client list. A one page executive summary at the start helps busy readers decide quickly. For a clinic, the outcome section might describe online booking, reminders and a simple dashboard. For a US software buyer, it might describe a dedicated team, working hours overlap and reporting.

• Executive summary: the problem, the proposed solution and the result in a few lines.
• Current situation and goals: in the buyer's words from discovery.
• Proposed solution and approach: what you will build or deliver, and how.
• Scope: what is included and, just as important, what is not included.
• Timeline and milestones: phases with clear deliverables.
• Commercials: price, payment schedule, validity period and taxes.
• Assumptions and dependencies: what the buyer must provide and by when.
• Relevant experience, team and next steps, including how to accept.

Scoping a fixed price quote

A fixed price quote means the buyer pays an agreed amount for an agreed scope. Buyers like it because it is predictable. It is risky for you if the scope is vague, so the work happens before you write the number. Break the project into features or deliverables, estimate each one with the delivery team, add time for testing, project management and deployment, and include a buffer for the unknowns you identified. Never let sales alone estimate technical work. Write the scope so that a third person could check whether each item was delivered. 'Patient booking module' is vague. 'Patients can book, reschedule and cancel appointments for any doctor at either branch from a mobile browser' is checkable. Link payments to milestones such as design sign off, first release and go live.

• Define acceptance criteria for each deliverable.
• List exclusions clearly, such as content writing, hardware, third party licence fees or integrations not named.
• State assumptions, such as 'client provides doctor schedules in a spreadsheet by week two'.
• Describe the change request process: how new requests are estimated, approved and billed.
• Set a validity period for the quote so old prices are not accepted months later.

Fixed price versus time and materials

Fixed price suits small, well defined projects, such as a clinic website or a simple internal app. Time and materials, where the buyer pays for the hours or team months used, suits ongoing development, evolving products, and dedicated team arrangements that are common with US and UK clients. Many teams combine the two: a fixed price discovery or design phase, followed by time and materials or a monthly retainer for build and support. Present the option you recommend and explain why. If a buyer insists on fixed price for a vague project, offer a paid discovery phase first to define the scope. This protects both sides and often becomes the buyer's favourite part of working with you. XDQ Labs teams often use this approach when a buyer's requirements are still forming.

Check your understanding