Quotation Management for IT Services: Estimates That Hold Up During Delivery

Every software estimate is really two estimates layered together. One is about the work itself: how much design, build, testing and migration a described scope needs. The other is about the conditions the work will happen in: whether environments exist, whether interfaces are documented, whether the data is as clean as everyone hopes, and how much time the people who know the business can actually give.

Firms estimate the first carefully and the second not at all, which is why overruns so often have nothing to do with the technical difficulty of the build. Writing the second layer down as assumptions is the difference between a delay that is traceable to a specific dependency and a delay that reads as an estimating failure.

Time and materials places the risk of a larger-than-expected effort with the client and demands transparency in return. Fixed price places it with the supplier and demands a scope precise enough to be sized. A dedicated capacity arrangement sells availability rather than an outcome. A managed service sells a running service with its own terms.

None of these is inherently better, and most firms sell more than one. The failure is choosing a model that does not match the state of the requirement, which almost always means quoting a fixed price against something nobody has actually specified. Where the requirement is genuinely unclear, a paid discovery phase producing a detailed estimate is a more honest answer than a confident number, and clients accept it far more readily than most sales teams expect.

Clients evaluate implementation proposals on the implementation figure, which is the least important number in the document over a five-year horizon. Licences, subscriptions, infrastructure, and support all recur, and a proposal that shows only the one-time cost is describing the smaller half of what the client will spend.

Separating one-time from recurring, and showing when the recurring element begins, serves both sides. The client can budget properly and compare proposals honestly. The supplier avoids the conversation, twelve months in, in which a client who believed they had bought a finished system discovers a renewal they had not planned for.

A warranty covers defects in what was delivered, for a defined period. Support covers the running of the thing: user questions, environment problems, small enhancements, incidents at hours somebody has agreed to be available. They are different products with different costs, and a proposal that mentions only the first is very often read as promising the second.

The moment this surfaces is the worst possible one, which is the first weeks after go live, when the client is anxious and the supplier is trying to demonstrate care. Quoting both explicitly, with the warranty duration and the support coverage stated, converts that period from a dispute into a planned transition.

Requirements change during software delivery. This is not a defect in the client or in the estimate; it is the nature of building something that did not previously exist. The only real question is whether a route for handling change was agreed before it was needed.

A defined process, an agreed rate and a lightweight approval step means additions are priced and accepted as they arise. Without one, each request becomes a negotiation held under delivery pressure, and the usual outcome is that the team absorbs the work from a contingency intended for genuine estimating error. That contingency then is not available when a real estimating error occurs, which is when the project actually gets into trouble.

A convinced sponsor is the beginning of the commercial process rather than the end of it. Procurement negotiates rates and terms, a security or vendor risk review examines how data is handled, legal works through liability and exit provisions, and the budget may only be releasable within a particular cycle. Each of these takes time that has nothing to do with how persuasive the proposal was.

Tracking those steps as their own stages produces both a more accurate forecast and a more useful follow-up. Offering to complete the security questionnaire, or asking whether the vendor onboarding forms have been raised, moves a deal further than another conversation about the solution. It is also the point to check whether the validity of your estimate and your licence quotes will survive the timeline the process implies.

A signed statement of work, usually under a master agreement, with a purchase order where the client requires one. At that point the accepted version, with its effort breakdown, assumptions and milestone schedule, becomes the baseline the delivery team works against and the reference every change request is measured from. Backlogs, sprints, issue tracking, timesheets, resourcing, invoicing, tax and your accounts belong to the delivery and finance systems that already run them. What stays here is the commercial history: what was estimated, on which assumptions, at which version, and why the deals that did not close did not.

Read next: all CRM features, lead management software, sales automation, AI CRM, CRM for small business, CRM by industry, and pricing.