Evaluation criteria for PC and server procurement bids: weights

Why fix criteria and weights in advance

Vague criteria almost always end in disputes. One committee member focuses on lowest price, another on delivery time, a third on warranty and support. If you don’t prescribe in advance what is evaluated and how many points each item is worth, any decision will look like “at the committee’s discretion,” and suppliers will have grounds to complain.

Predefined evaluation rules solve three problems: comparability, transparency and reproducibility. Comparability — all proposals are converted to a single scale (points) and can be compared by the same rules. Transparency — the supplier knows in advance what will earn points and what won’t. Reproducibility — another committee applying the same formulas and documents will reach the same result.

For a government body this is practical. You need predictable delivery (and clear penalties for delays), functioning support (with measurable SLAs) and a full document package so acceptance and payment don’t stall. If a participant promises “24/7” but does not provide a procedure, contacts, reaction times and escalation rules, you cannot compare that promise with a real SLA from another participant.

To avoid differing interpretations within the committee, agree on the rules before publishing the procurement. Usually four decisions are enough:

• separate “admission” (mandatory requirements) and “evaluation” (points)
• agree on weights: what matters most here — price, delivery time, service or documents
• fix which documents prove each point and what counts as “not proven”
• approve a single calculation template so everyone computes the same way

This reduces the risk of disputes, simplifies the committee’s work and gives participants clear rules up front.

Mandatory requirements and evaluative criteria: don’t mix them

The most common cause of disputes is when “admission” and “point-based evaluation” get mixed. The logic should be simple: first the participant passes a threshold (all mandatory requirements met), and only then proposals are compared by evaluative criteria. That way evaluation does not become bargaining.

Mandatory requirements cannot be “compensated” by a low price or attractive promises. If a parameter is critical for operation or safety, it must be strictly yes/no. For PCs and servers, such items typically include compatibility with your infrastructure (OS, domain, security tools, interfaces, rack and power for servers), minimum specifications (CPU, RAM, storage, network ports, redundancy), warranty and repair conditions (for example, not less than 36 months), confirmed service (support availability and request handling procedure), and required documents (certificates, declarations, proof of origin, supplier authority).

If an item is so important that delivery without it is meaningless, don’t award points for it. A typical mistake is “we’ll add points for having a warranty” or “we’ll score certificates on a scale.” Warranty, meeting minimum specs and mandatory proofs should be admission conditions. Reserve points for things that can be better than the minimum: shorter delivery, extended SLA, warranty beyond the minimum.

Write mandatory requirements so they can be checked by documents and specs without interpretation:

• one requirement — one verifiable fact
• concrete numbers instead of “no worse than” or “modern”
• “provide document X” instead of “confirm quality”
• identical wording in the TOR and the bid form (so comparison is mechanical)

This way the committee first filters out unsuitable bids, then calmly tallies points according to preset weights.

How to choose criteria and distribute weights without skewing results

Keep the matrix simple: 3–5 key criteria. The more rows, the more chances for disputes over details that don’t affect the outcome.

Start from procurement priorities, not percentages. For PCs and servers in a government body, three things usually matter: staying within budget, not missing the commissioning deadline, and having support if something fails. If downtime is critical (e.g., for a public service center, hospital, call center), weights for service and delivery time should be higher even if the price is slightly more expensive.

Guideline weights (adjust to your situation, but avoid extremes):

• Price: 40–60%
• Delivery time: 10–25%
• Service and SLA: 15–30%
• Supporting documents (certificates, statuses, letters, warranty): 5–15%

This range helps avoid skewing the evaluation toward a single parameter. If you give price 80–90%, you effectively say timelines and support hardly matter — then don’t be surprised by delivery and repair risks.

A quick sanity check: imagine two proposals. The first is 5% cheaper but takes twice as long and offers support only during business hours. The second is more expensive but delivers faster and provides 24/7 support with defined reaction times. If your weights make the first almost always win even when downtime is critical, your weights don’t match reality.

Record the rationale for weights in the protocol with simple phrases: why the deadline matters (commissioning date), why service matters (downtime risk), why documents matter (verifiability and acceptance). For Kazakhstan, localization and domestic manufacturer status (including ISO) may be a separate topic. If there are suppliers with local production and service networks, like GSE.kz, account for those differences only through measurable criteria and proofs, not promises.

Step by step: building an evaluation matrix for the committee

A matrix ensures the committee compares bids consistently and avoids disputes about interpretations. When criteria and calculation rules are described in advance, participants prepare supporting evidence more easily and reviewers understand the decision logic.

Start with a draft table: criterion, weight, scale, formula, proof documents.

Five steps that usually work

1. Define the procurement scope by scenarios: office PCs for typical tasks, servers for specific services, delivery to remote branches, rack installation requirements. This helps identify where delivery time matters most and where reliability is paramount.

2. Separate mandatory requirements from evaluative ones. Mandatory items are admission criteria (yes/no): compatibility, basic specs, presence of a service network, statuses and certificates. For each, set the confirmation format: product datasheet, manufacturer letter, certificates, reference lists, SLA.

3. Choose 3–6 evaluative criteria and set weights and scales (for example, 0–5 or 0–10). The scale must explain what earns 0, the mid score and the maximum.

4. Prescribe formulas and rounding rules. For price, normalization from the minimum is common; for timelines, points by ranges; for service, measurable parameters (reaction and recovery times). Fix how to handle ties and which fields from the application are used.

5. Do a test run with 2–3 sample proposals. One can be cheaper but much slower; another pricier but with strong service. If the result seems unfair, adjust weights or scales before publication.

Example: if on-site replacement is critical for branches, add a separate criterion “on-site service and coverage.” Proof can be service center addresses and an SLA draft. Suppliers like GSE.kz usually can confirm this documentarily, making scoring straightforward.

Price evaluation: formulas and rules that withstand scrutiny

Price seems the simplest criterion, but it causes the most disputes. To avoid ad hoc judgments, fix in advance what counts as price, which costs are included and which formula awards points.

The clearest option is points from the minimum price. The formula is easy to verify and not subjective:

Баллы_по_цене = (Минимальная_цена / Цена_участника) * Максимум_баллов

For example, maximum points for price are 60. Minimum price is 10,000,000. A participant offers 11,000,000. Then 10,000,000 / 11,000,000 * 60 = 54.5 points.

Main protection against manipulation is comparing like with like. Price must refer to the same configuration and identical delivery terms. Describe in advance what constitutes equivalence (processor, RAM, storage, OS, warranty, number and type of ports, form factor). Otherwise “cheaper” often means “lower spec.”

To avoid disputes about what’s included in price, set uniform rules: evaluate price with VAT or without (choose one), state whether delivery to a specific address is included, define what’s in commissioning (if needed), how extended support is handled (a separate criterion or a priced option), and uniform payment terms and price validity period.

Sometimes it makes sense to consider lifecycle costs, but only if you define and can verify calculations in advance: energy consumption, extended support costs, spare parts replacement, licenses, maintenance. Then evaluation is total cost of ownership for a defined period (e.g., 3–5 years) using a single calculation method for all.

Delivery time and service: measurable indicators instead of promises

To let the committee compare bids without disputes, describe delivery and service as measurable indicators, not vague claims of “fast” or “high quality.” In rules, separate minimum (admission) and what earns extra points.

Timelines: what to count and how to score

A single “overall timeline” can hide risk. It’s easier to break it down: equipment readiness (production or stock), delivery to address(es), commissioning (installation, configuration, verification), transfer of documentation and acceptance acts, training (if needed).

Set a scale by thresholds. Example: up to 10 days — 10 points, 11–20 days — 7 points, 21–30 days — 4 points, more than 30 — 0 points. Clearly state from which event the timeline is counted (contract date, shipment request date, payment date). Otherwise participants will interpret differently.

Verify realism with documents, not assurances. Ask for a delivery schedule by batches (if many workstations), shipment points, and a weekly plan. If a very short timeline is claimed, it must be supported by stock availability or a fixed production schedule.

Service: admission minimum, details for points

For service set a baseline that excludes a bid if absent, then award points for stricter metrics.

Metrics typically understandable for all:

• reaction time to a request (e.g., 30 minutes / 2 hours / 4 hours)
• recovery time (e.g., within 8 hours / 24 hours / 48 hours)
• spare parts availability and replacement time (regional or central stock, days)
• support hours and request channels (24/7 or business hours) with a clear definition of “24/7”
• geographic coverage for engineer visits: list regions and arrival times (in-city — up to 4 hours, out-of-city — up to 24 hours)

To remove ambiguity, define what starts the clock (time of request registration), which channels are acceptable (phone, email, portal), and what “recovery” means (service operability, device replacement, issuing a loan unit).

If a participant claims 24/7 and broad on-site coverage, award points only with an SLA and coverage description.

Supporting documents: how to check and award points

Documents are the easiest part to turn from a source of disputes into a clear matrix: classify them as (1) mandatory for admission and (2) those that earn extra points. Then the committee compares by a checklist rather than by impression.

Start with a list proving the supplier will deliver what’s promised: product datasheet or spec with exact models and characteristics, information on model families and configurations, warranty terms and service format, origin documents and supplier authority.

Checklist for awarding points

Use a simple scale, e.g., 0–1–2 points per item (no, partial, full). The checklist usually includes a complete specification without vague wording, clear warranty terms (duration, coverage, repair location, reaction times), origin and manufacturer status documents (if localization matters), management system certificates (ISO 9001, ISO 14001, ISO 45001) as signals of process maturity, and a neat complete package (readable files, signed, matching dates and names).

ISO certificates are best treated as trust add-ons, not substitutes for concrete technical documents and warranty terms.

When to reject rather than withhold points

List critical mismatches as reasons for non-admission. Examples: missing mandatory documents listed as required; specs in documents don’t match the bid; warranty is stated in words but not confirmed by contractual text; origin/manufacturer status documents are absent when localization was required; contradictions between files (different models in different documents, inconsistent timelines).

A simple example: two participants offer the same price. The first provides exact specs and a 36-month warranty with clear reaction times plus proof of manufacturer status and ISO. The second provides a general brochure and “warranty by agreement.” By the checklist the first gets more points and the decision is easy to justify in the protocol.

Example scenario: comparing two proposals without disputes

The committee procures 200 PCs and 10 identical servers delivered to two addresses in one city. Compatibility, configuration, warranty and security requirements are identical and set as mandatory conditions.

The preset matrix applies:

• Price (50 points)
• Delivery time (20 points)
• Service and SLA (20 points)
• Supporting documents (10 points)

Two suppliers:

Supplier A: price 100 million KZT, delivery 25 days, basic service (reaction 8 hours, fix in 5 business days). Supplier B: price 106 million KZT, delivery 10 days, extended service (reaction 2 hours, next-day on-site, loan units available).

The committee uses simple formulas for price and time to avoid subjective judgments:

The difference is easy to explain: B is more expensive but wins on delivery and service, which the weights account for.

To avoid oral arguments, comments should record only matrix items:

• which metric was claimed
• which document proves it
• which matrix item was applied
• how many points were awarded

Reviewers then see a transparent result: a matrix, formulas, proofs and calculations.

Common mistakes that make procurements disputable

Big disputes usually stem from fuzzy evaluation rules rather than “bad” suppliers. If a participant can interpret a clause their own way, they will.

Typical mistakes:

• overloading evaluation with dozens of items and subjective terms like “best,” “maximally reliable,” “high quality” without measurable metrics
• awarding points for unverifiable claims: “we guarantee quick on-site visits,” “we have a strong team,” “high satisfaction”
• comparing bids under unequal conditions: different configurations, payment terms, delivery and installation conditions, included or excluded commissioning
• assigning weights by habit rather than by risk (e.g., giving service only 5% for servers in critical infrastructure)
• not specifying tie-break rules: what to do with equal prices or total scores, how to round, how to treat partial deliveries

A small scenario: two participants offer “same-class” servers, but one includes extended 24/7 warranty and regional on-site service, while the other offers only service-center repairs. If service is one line and has a small weight, the committee effectively compares different products under the same label.

To remove disputability before publication, add clear rules:

• tie every evaluative item to a document or metric (a number, a term, an SLA format)
• fix the baseline configuration and what counts as equivalent
• state which costs are in the price (delivery, lifting, installation, training)
• define a single tie-break: lower price or shorter delivery (pick one, no ambiguity)

If delivery is nationwide, ensure service-network requirements and coverage are proven by documents, not promises.

Quick pre-publication checklist for criteria

Before publishing, run a quick check: the committee should compare bids by numbers and documents, not impressions.

• Mandatory vs evaluative are separated. Mandatory requirements are verifiable (a document exists or not) and do not duplicate points. If you award points for 24/7 support, don’t make it an admission requirement as well.
• Each criterion has a scale and a data source. For price — a formula; for time — calendar days and a start point; for service — measurable metrics; for documents — a list and verification rules.
• Weights have no hidden factors. Total is 100%, and everything affecting the final score is described. “At the committee’s discretion” is replaced with a scale.
• Test calculations on sample bids. Make sure one criterion does not overshadow all others.
• Assign responsibilities: who checks price and arithmetic, who checks timelines, who checks SLAs and documents, and what to do if disagreements arise.

If after this check you can explain to a participant in 10 minutes how their final score was calculated, the criteria are ready to publish.

Next steps: simplify the committee’s work and reduce risks

Start with a short internal one-page document that records the priorities of your specific government body. When agreed in advance, the committee argues less about “what matters” during bid opening and evaluation.

To solidify the approach, answer a few questions and get them approved by responsible parties:

• Which timelines are critical: immediate delivery or phased commissioning?
• Is 24/7 service required and what maximum downtime is acceptable?
• Which documents are mandatory and which earn extra points?
• How important are localization and supply-chain transparency?

It’s useful to check these formulations with the market, but do so without tailoring to a particular supplier. Request sample SLAs and document packages (certificates, manufacturer letters, service network info) from several potential suppliers. This helps remove ambiguous items that later cause disputes.

Prepare unified templates for the committee: a specification with a fixed structure and a comparison table where each criterion maps to one field and one proof document. Then any committee member sees the data source for each score and the decision is easier to defend.

If localization and supply-chain transparency matter, create a separate block: which proofs are accepted and exactly how they affect points (domestic manufacturer status, management system certifications, service coverage confirmations by region).

To make timelines, service and document packages realistic, consult manufacturers and system integrators in advance. For PC and server deliveries, participants like GSE.kz can advise achievable production and delivery times, 24/7 support formats and typical document packages. This helps screen out “nice promises” that cannot be verified or fairly compared.