Use case · Technical bid evaluation
Not what they said they offered. Vendor submissions read against your technical specification and against each other, so every deviation is surfaced with its clause, including the ones nobody listed.
The problem
Technical bid evaluation is done by reading each package against the specification and typing the result into a matrix. Different evaluators read the same clause differently, and the schedule decides how deep anyone gets.
By award, the comparison reflects how carefully each package happened to be read, which is not the same as how well each bidder complied.
A bid evaluation is supposed to compare offers. In practice it often compares how thoroughly three different documents were reviewed.
The bidder who wrote the clearest submission tends to score best, whether or not they offered the most.
The comparison
Each submission is read against the same specification, so the matrix reflects what was offered rather than who wrote the clearest document.
| Requirement | Bidder A | Bidder B | Bidder C |
|---|---|---|---|
| Design temperature | MEETS | MEETS | MEETS |
| Material qualification | MEETS | UNSTATED | DEVIATION |
| Flange rating | MEETS | MEETS | MEETS |
| Testing regime | DEVIATION | MEETS | MEETS |
| Documentation scope | MEETS | MEETS | UNSTATED |
Illustrative. Bidder B looks cleanest on their own deviation list, and carries the one deviation nobody was told about.
The distinction that matters
Bidders submit a deviation list, and a good evaluator reads it carefully. The deviations that cause trouble are the ones that were never on it.
The bidder has told you they are not meeting a requirement and usually why. You can price it, negotiate it, accept it or reject it. It is visible, and it is a normal part of a competitive bid.
Nothing flags it. It passes evaluation, passes award, and surfaces during engineering or at inspection, when the leverage has gone and the change is a variation order rather than a clarification.
Where this is today
A vendor package is a document like any other, so checking one against your specification works today. What is new is holding several against the same requirement set at once.
Clause by clause, with the requirement it failed and the page it came from.
Severity proposed, source quoted, and an engineer ruling on each one.
PDF to attach to a recommendation, Excel to work into your own matrix.
One requirement set, several submissions, and a deviation register across the field.
Related
The requirement set comes from the same library your projects already run on.
FAQ
It is the assessment of vendor submissions against the technical requirements of an enquiry, to establish what each bidder is offering and where each one deviates. standrdX reads each submission against your specification and raises every deviation with the clause it relates to.
It is in development. Checking a single submission against your specification runs today, which covers most of the reading work in an evaluation.
By reading the submission against the requirement rather than against the bidder's own deviation list. Anything offered that does not meet the requirement is raised whether or not it was flagged.
No. It establishes what each bidder offered against each requirement. Weighting, commercial terms and the award decision stay with your evaluation team.
Yes, and that is what runs today. A single-source submission checked against the specification is the same work, minus the comparison.
A findings set per submission, each with the requirement, the deviation and the evidence, exportable to PDF for the recommendation and Excel for your own matrix.
Next step
Load your specification and a vendor package, and see the deviations it raises against the list the bidder gave you.