What evidence should a provider give for its managed IT support pricing?

A provider should support its managed IT support pricing with a clear, itemised service scope, pricing assumptions and explanation of what is included or excluded. It should also provide relevant service level commitments, onboarding details and example reporting, so you can assess whether the proposed cost matches the support your organisation requires.

Reliable evidence for managed IT support pricing is a traceable explanation of how the proposed fee relates to the organisation’s technology estate, expected support demand, required expertise and commercial assumptions. A provider should be able to show how it reached the figure, which information it used and how the price would change if those underlying conditions changed.

A documented pricing basis

Ask for a written pricing rationale rather than a single unexplained monthly figure. This should identify the main cost drivers, such as the number and type of users, endpoints, servers, sites, cloud services, network connections and specialist systems being supported. It should also explain whether the price is calculated per user, per device, per site, by estimated effort or through a blended model.

The provider should distinguish verified facts from estimates. For example, an asset count obtained from an assessment is stronger evidence than an assumption copied from an initial enquiry. Any estimates should be dated and accompanied by a method for confirming them before the agreement begins.

An asset and environment baseline

A credible proposal should be based on an inventory of the systems that create support obligations. Useful evidence may include a device register, user list, site information, server and network details, cloud-service records, backup arrangements and known security dependencies. The inventory does not need to expose sensitive information in the quotation, but it should demonstrate that the provider has considered the actual environment rather than applying a generic package.

Check whether inactive, duplicate or unsupported assets have been identified. An inaccurate baseline can produce an artificially low initial price, followed by disputes or additional charges when the provider discovers systems that were not included in its calculation.

Demand and workload evidence

Pricing should reflect the work likely to reach the service desk and the work required to maintain the environment. Ask how the provider has assessed historic ticket volumes, recurring incidents, user onboarding and offboarding, device changes, site activity, maintenance tasks and project-related requests. Where reliable historic data is unavailable, the provider should state that the estimate is provisional and explain how it will be reviewed.

Past ticket data is useful, but it should not be treated as the only indicator of future demand. A low volume may reflect unresolved problems, limited user reporting or an environment that has been poorly maintained. Conversely, a temporary project can make historic demand appear unusually high. The evidence should therefore explain any adjustments made to the raw figures.

Resource and capability calculations

A provider should show, at an appropriate level, how the fee supports the people and technical capability assigned to the account. This may include service desk effort, technical escalation, account management, monitoring, security administration and specialist consultancy. The key issue is not a named individual or a precise internal salary calculation; it is whether the proposed resources are proportionate to the systems and risks involved.

Ask how holidays, sickness, staff changes and specialist escalation are accounted for without relying on one person’s knowledge. The response should also clarify which activities are delivered by the provider’s own team and which depend on third parties, subcontractors or separate suppliers, because those dependencies can affect both cost and accountability.

Risk and complexity assessment

Two organisations with the same number of users may require different levels of support. Evidence should therefore address factors such as multiple locations, legacy equipment, regulatory obligations, remote access, business-critical applications, complex integrations and a history of recurring faults. Security exposure and recovery requirements can also increase the expertise and management effort needed to operate the environment responsibly.

A useful proposal identifies material risks that could affect delivery or future cost. It should not conceal uncertainty behind an apparently precise price. If a quotation depends on replacing obsolete equipment, resolving licensing issues or documenting an undocumented network, those dependencies should be visible to the decision-maker.

Commercial audit trail

Request a version-dated quotation, the assumptions used to prepare it and a record of any subsequent changes. The commercial document should make it possible to reconcile the proposed fee with the assessed environment and agreed purchasing model. If different options are offered, each should be compared on a like-for-like basis so that a lower figure is not simply omitting important work.

Evidence is weaker where the provider cannot explain its calculation, changes the basis between proposals, uses unexplained bundled charges or presents an unusually low price without identifying the resulting limitations. A sound comparison focuses not only on the amount payable, but on whether the provider can substantiate the amount and identify the circumstances that could alter it.

Before approval, the buyer should confirm the evidence against its own records and ask the provider to correct discrepancies. This creates a shared baseline for assessing future pricing discussions and reduces the risk that the recurring fee is based on inaccurate information.

Service-level documentation and reporting examples provide evidence of how managed IT support will be measured after the contract begins. They show whether the proposed price includes a defined operating model or only a general promise of assistance.

  • Ask for the service-level document, including how incidents are prioritised, when measurement starts, how requests are recorded and which types of work are excluded from the stated measures.
  • Request a redacted sample report or reporting template. It should show how open requests, recurring issues, service trends, outstanding actions and agreed improvements will be presented.
  • Check who reviews the information, how often it is discussed and how unresolved issues are escalated. Reporting that is produced but not used for decisions offers limited evidence of value.
  • Confirm that the proposed price covers the reporting and review activities described. If governance meetings, service reviews or detailed analysis are optional extras, they should be identified separately.

These documents also help distinguish measurable commitments from informal assurances. A provider should be able to explain how the evidence will be collected, who is responsible for it and how the findings could lead to changes in support priorities or future pricing.

Managed IT support proposal showing service scope, pricing assumptions and review notes

Discuss your managed IT support pricing requirements

If you are comparing managed IT support proposals, discuss your organisation’s requirements with S2 Technology Group and identify which evidence you need to assess each option fairly.