Outlier Science
Laboratory Procurement Requirements Template
Use this template to translate a laboratory's research needs into an equipment requirements brief and a record of the evidence needed for selection. It is designed to help scientific, facilities and procurement colleagues work from the same assumptions. The complete template is available below, with an editable Word version and no email requirement.
This is an original planning template. It is not a tender document, purchase authorisation, technical certification or substitute for the institution's procurement procedures. Add the requirements of the actual method, facility, funder and jurisdiction with the appropriate specialists. Complete only what applies, and explain material omissions or uncertainties.
Take this resource into your work
Use the complete checklist below, or download the editable Word template for your team. No email required.
On this page 8 sections
1. Define the request and authority
Field | Entry to complete |
|---|---|
Project or laboratory | Identify the requesting unit |
Request identifier and version | Give the brief a stable reference and date |
Scientific lead | Name the owner of the research requirement |
Laboratory operations contact | Name the person responsible for intended use |
Facilities and IT contacts | Identify relevant reviewers |
Procurement and finance contacts | Identify the authorised institutional route |
Decision-maker | State who can approve the specification and purchase |
Funding source and restrictions | Record confirmed conditions and unresolved questions |
Target need date | Explain the research reason and dependencies |
Scope of this document | State whether it supports planning, market enquiry or an authorised procurement stage |
Do not send the template to suppliers until the procurement owner confirms the appropriate process. Describe any adviser’s role separately from the authority to negotiate, contract or purchase. Record relevant supplier relationships or other interests for review under the applicable institutional arrangements.
2. Describe the research use
Field | Entry to complete |
|---|---|
Research questions or intended service | Explain what the equipment must enable |
Methods and workflows | Identify current or proposed methods and dependencies |
Sample or item types | Record matrices, preparation, quantity and relevant restrictions |
Expected volume | State low, expected and high workloads with their evidence |
Peak demand | Describe when capacity is most constrained |
Intended users | Identify roles, experience and access needs |
Existing equipment or facilities | Explain what is already available and why it is insufficient |
Alternatives considered | Record shared access, outsourcing, refurbishment or phased investment |
Future needs | Separate credible planned uses from speculative preferences |
Define workload in terms the technical team can verify: samples, batches, measurement hours or another appropriate unit. Include preparation, quality checks and repeat work where relevant. An advertised instrument rate should not automatically become the assumed rate for the laboratory's complete workflow.
3. Record technical requirements and evidence
Create one row per requirement. Mark it Essential, Preferred or Unresolved and explain the classification. Use performance-based requirements where appropriate and permitted, with a scientific reason for restrictions.
Requirement ID | Requirement and rationale | Target or acceptance condition | Evidence required | Priority |
|---|---|---|---|---|
T1 | Measurement capability needed for the research | Enter justified range, performance or functional condition | Method-based evidence or relevant demonstration | Enter priority |
T2 | Sample compatibility and preparation | Enter sample types and workflow constraints | Supplier documentation and technical review | Enter priority |
T3 | Practical capacity | Enter throughput under stated conditions | Demonstration assumptions and workflow analysis | Enter priority |
T4 | Data output and access | Enter formats, records and integration needs | Example exports and documented capabilities | Enter priority |
T5 | Additional project-specific requirement and rationale | Enter a justified acceptance condition | Define the evidence needed | Enter priority |
Replace the prompts with actual requirements and add rows as needed. Do not leave “high quality”, “advanced technology” or “fully compliant” as acceptance criteria without defining the required property and evidence. Have the relevant technical specialist approve the scientific interpretation.
4. Check the location and operating dependencies
Requirement area | Information to confirm | Reviewer and evidence |
|---|---|---|
Space and access | Dimensions, delivery route, installation access and relevant loading limits | Facilities review |
Utilities | Power, water, gases, cooling or other required supplies | Technical specifications and facilities confirmation |
Environment | Temperature, humidity, vibration, ventilation or other relevant conditions | Site assessment against the actual requirement |
Safety and waste | Hazards, containment, waste streams and required specialist controls | Institutional safety review |
IT and software | Workstations, network, licences, permissions, exports and support | IT and data-management review |
Personnel | Operating, maintenance and supervision roles | Training and competence plan |
Shared use | Booking, access, project priority and responsibility for damage or faults | Approved operating arrangement |
Record dependencies that must be completed before delivery, installation or use. Give each an owner and an evidence-based completion condition. If accreditation or another standard is relevant, identify the actual scope and obtain qualified review. ISO/IEC 17025 concerns laboratory competence and operation; purchasing an instrument does not itself establish accreditation.
5. Build a lifecycle-cost record
Agree the comparison period, currency, volume scenarios and financial method with finance. Identify whether tax, inflation, discounting and residual value are included. The European Commission's lifecycle-cost guidance supports looking beyond purchase price to operating and end-of-life costs. Apply the actual procurement and financial rules separately.
Cost category | Amount and period | Source and date | Included, excluded or uncertain? |
|---|---|---|---|
Purchase and required accessories | Enter amount | Quotation or documented estimate | Enter status |
Delivery, installation and facility work | Enter amount | Supplier and institutional evidence | Enter status |
Initial and continuing training | Enter amount | Scope and relevant rates | Enter status |
Consumables and reference materials | Enter cost per unit and expected volume | Method and supplier evidence | Enter status |
Maintenance, calibration and repairs | Enter annual or scheduled costs | Actual proposed service terms | Enter status |
Software, licences and data support | Enter initial and recurring costs | Licence and support terms | Enter status |
Staff, utilities and operational overheads | Enter defined basis | Institutional assumptions | Enter status |
Downtime or external backup | Enter justified scenario | Contingency assumptions | Enter status |
End-of-life cost or residual value | Enter amount and timing | Documented basis | Enter status |
Other material cost | Describe and quantify | Evidence or uncertainty | Enter status |
Use one consistent calculation for each option. Keep unknown costs visible, test assumptions that could change the decision and avoid double-counting items already included in a package. The lifecycle-cost guide includes a fully labelled numerical example.
6. Ask suppliers comparable questions
Where authorised, send the same brief and scenario to each supplier. Request a response that addresses the requirement IDs and identifies any deviation. Ask for the exact proposed configuration, included accessories, service location, training scope, software conditions, consumable dependencies, quotation validity and unresolved assumptions.
Record each response in a comparison sheet:
Field | Entry to complete for each supplier or option |
|---|---|
Supplier and option identity | Record the official entity, model and configuration |
Requirement ID | Identify the specification item |
Supplier response | Summarise the actual response without improving its claim |
Supporting evidence | Link the document, demonstration or clarification |
Technical review | Record whether the evidence meets the stated condition |
Cost implication | Identify included, additional or uncertain expenditure |
Open question and owner | Assign clarification responsibility |
Relevant interest or relationship | Record for the authorised conflict review |
Keep mandatory requirements separate from preferences. Do not average a failure to meet an essential requirement into an otherwise favourable score. If weighted evaluation is used, define and approve the method through the applicable process before comparing offers.
7. Define acceptance and handover
Acceptance item | Evidence or condition | Owner |
|---|---|---|
Correct equipment and configuration delivered | Match the approved order and specification | Assign owner |
Installation and location requirements addressed | Document agreed checks and unresolved items | Assign owner |
Relevant performance demonstrated | Apply agreed project-specific acceptance criteria | Assign technical owner |
Required documentation received | Manuals, service records, licences and relevant certificates | Assign owner |
Training completed | Record the actual scope, attendees and required follow-up | Assign owner |
Data access and export confirmed | Verify the agreed workflow and permissions | Assign owner |
Outstanding items resolved | Record actions, evidence and authorised acceptance | Assign decision-maker |
Routine operation handed over | Name maintenance, consumable and record owners | Assign operations owner |
Align these conditions with the actual contract and institutional authority. More specialised qualification, validation or technical checks may be necessary for the intended work. Define them with the appropriate specialists; a generic acceptance table does not replace them.
8. Record the decision and review its assumptions
Write a short decision note identifying the requirement, options considered, technical evidence, lifecycle-cost comparison, unresolved risks and authorised decision. Explain the reasons and any conditions that must be met before commitment. Keep the approved specification and evaluation version together.
After implementation, review actual use and expenditure against the important assumptions. Record changes in demand, recurring costs, service experience and capacity constraints. This helps improve later purchases and identifies operational work that may still be needed.
For laboratory equipment procurement advice, an initial inquiry can describe the research use, equipment category and current planning stage. Share technical or commercially restricted documents only through an agreed route. The template is most useful when it exposes the decisions still needed, rather than presenting an incomplete specification as ready for purchase.