How to Create an IT Tender Document - That Actually Gets You the Right IT Provider

An IT tender document is a formal request issued to potential IT suppliers that sets out your organisation's requirements, environment, and evaluation criteria. It gives suppliers the information they need to submit a structured proposal, and gives you a consistent basis for comparison. A well-written tender covers technical requirements, service expectations, governance and reporting requirements, security obligations, and commercial parameters.

Common triggers include an upcoming contract renewal (typically 6-12 months before expiry), dissatisfaction with your current provider, a significant change in your organisation's size or technology requirements, a merger or acquisition, or a strategic decision to move from in-house IT to a managed service model. Running a tender too close to a contract end date is a common mistake - it reduces your negotiating position and limits the time available for a structured transition.

A well-structured IT tender typically takes 8-16 weeks from initial scoping to contract signature, depending on the complexity of your environment and the number of suppliers being evaluated. Organisations that rush the process - particularly the requirements definition and evaluation stages - frequently encounter problems post-contract. Allow additional time for transition planning and onboarding, which typically adds a further 30-90 days before the new supplier is fully operational.

Three to five suppliers is the most effective range for most organisations. Fewer than three limits comparison and negotiating leverage. More than five creates disproportionate evaluation overhead and can reduce the quality of responses, as suppliers invest less effort when they perceive low probability of success. Shortlist based on operational maturity and sector experience, not just headline pricing.

A comprehensive IT tender should cover: your current environment (infrastructure, applications, user count, locations), service requirements (support hours, response times, escalation paths), security and compliance obligations, governance and reporting expectations, transition and onboarding requirements, commercial parameters (budget range, contract term, pricing model), and evaluation criteria with weightings. Many organisations underinvest in the requirements definition stage, which is the single most common cause of post-contract disappointment.

Define your evaluation criteria and weightings before issuing the tender - not after receiving responses. Typical criteria include operational maturity, technical capability, onboarding approach, governance and reporting quality, security posture, commercial value, and cultural fit. Avoid over-weighting price at the expense of operational indicators. Reference checks with existing clients are one of the most reliable indicators of delivery quality and should be a mandatory part of the evaluation process.

The most common mistakes are: issuing a tender without a clear requirements document, over-weighting price in the evaluation, failing to involve key internal stakeholders (often with conflicting priorities which should be consolidated), not assessing transition and onboarding capability, selecting based on polished sales deck quality rather than operational delivery evidence, having weak internal governance, and not defining reporting expectations before contract signature. Many organisations also underestimate the transition period and do not build adequate stabilisation time into the project plan.

Structured transition planning is the most important factor. This includes a detailed knowledge transfer process, parallel running where possible, a defined stabilisation period after go-live, and clear escalation paths during the transition. The new supplier should be expected to document your environment fully before taking over operational responsibility. Organisations that treat the transition as a simple handover event - rather than a structured operational programme - consistently experience the most disruption. Read our full guide: Switching IT Provider Without Disruption.

For complex environments or organisations without internal procurement expertise, a specialist IT procurement consultant can add significant value - particularly in requirements definition, supplier evaluation, and contract negotiation. However, the most important factor is having sufficient internal stakeholder involvement. Be careful if the consultant simply uses their default tender document which may not capture true business goals. A consultant cannot substitute for the operational knowledge held by your business teams. The best outcomes come from a combination of internal expertise and external process support.

Start with a clear description of your current environment and the outcomes you are trying to achieve - not just a list of services. Define your requirements in terms of business outcomes, not just technical specifications. Include your governance and reporting expectations explicitly. Be honest about the complexity of your environment, including known technical debt and supportability challenges. Suppliers who understand the real environment will provide more accurate proposals and are less likely to encounter surprises post-contract. And remember, asking IT providers a lot of questions, will create large responses, and reviewing five 50 page tender responses is an extremely time-consuming exercise, and rarely delivers the best results (if lots of questions are required, consider a RFI > RFP tender model).

In practice, the terms are often used interchangeably in the UK IT market. A Request for Proposal (RFP) typically implies a more structured evaluation process with defined scoring criteria, while a tender may be more open-ended. For most SME and mid-market IT procurement exercises, the distinction is less important than the quality of the requirements document and the rigour of the evaluation process.

Ask for evidence of certifications (Cyber Essentials Plus, ISO 27001), and what risk frameworks are used, but do not treat certification as a substitute for operational assessment. Review their security incident response process, ask how they handle vulnerability disclosure, and assess their approach to patching and endpoint management. For regulated environments, ask specifically how they support your compliance obligations. Reference checks with existing clients in similar sectors are particularly valuable for assessing real-world security delivery.

A Request for Information (RFI) followed by a Request for Proposal (RFP) is a well-established two-stage approach that can significantly improve the quality of your procurement process. The RFI stage asks suppliers a focused set of yes/no or short-answer questions to establish whether they meet your base requirements - security certifications, sector experience, minimum support coverage, key platform capabilities. Only suppliers who meet those base requirements proceed to the full tender stage. This approach keeps proposals smaller and more focused, reduces evaluation overhead, and ensures you are not spending time reviewing detailed proposals from suppliers who cannot meet your fundamental requirements. One important caution: be careful about excluding suppliers on peripheral yes/no questions that do not reflect genuine operational requirements. An RFI should filter on genuine blockers, not create artificial barriers that eliminate otherwise strong candidates.