Product tools · Tender stage
BetaTechnical bid evaluation: compare supplier offers against one requirement baseline
Technical Bid Evaluation checks every supplier offer against the same customer specification. Each supplier is assessed on its own, with declared and undeclared deviations, gaps and qualified answers cited to the offer. It drafts clarification questions. It never picks a winner. Buyers, procurement and project engineers use the evidence to decide.
Technical Bid Evaluation is in beta. Request access and we onboard each team ourselves: we run your first real documents with you and check the results together.
Last reviewed:
What goes in and what you get out
What goes in
- Customer specification (required)The governing specification issued by the customer.
- Customer datasheet (optional)
- Supplier offers (required, several files)
- Evaluation criteria (optional)
What it checks
- Apply criteria weighting
- Flag mandatory requirements separately
- Draft clarification questions
- Highlight high-risk deviations
What you get out
- One evidence table across all suppliers, with each requirement on its own line
- Each supplier's response to each requirement, cited to its offer
- Declared deviations, undeclared deviations, gaps and qualified responses
- Draft clarification questions for each supplier
- CSV or JSON export
Who uses it: Procurement engineers, Project engineers at EPC contractors, Buyers, Engineering managers.
20 questions about the Technical Bid Evaluation
What is a technical bid evaluation (TBE)?
A technical bid evaluation is the buyer's check of each supplier's offer against the technical requirements. The buyer, often an EPC contractor, lists the requirements and records how each supplier answers them. The TBE shows which offers are technically acceptable, which need clarification and which deviate. The commercial evaluation is usually done separately.
What does the Technical Bid Evaluation tool do?
It fixes one requirement baseline from the customer specification, then checks each supplier offer against it, one supplier at a time. For every requirement it records the supplier's response with a quote from their offer. It finds declared deviations, undeclared ones, gaps and qualified answers, and can draft clarification questions. It never recommends or selects a winner.
Which documents do I upload?
You need the customer specification and at least one supplier offer. You can add the customer datasheet and your evaluation criteria. Each offer can include the supplier's compliance matrix, deviation list, datasheets and appendices. The tool reads PDF, Word, Excel and CSV files, so offers in mixed formats can be compared on the same basis.
How is a TBE done by hand?
An engineer builds a spreadsheet with one line per requirement and one column per supplier. They read each offer and fill in the supplier's answer, often checking the compliance matrix against the appendices. Then they list clarification questions and mark each offer acceptable or not. With several long offers, this takes a long time and is easy to get wrong.
What is an undeclared deviation?
An undeclared deviation is a difference from the requirement that the supplier didn't list as a deviation. A common case is a compliance matrix that says "complies" while a datasheet or appendix in the same offer says something else. The tool checks the whole offer, not only the matrix, so it can find these and quote both places.
What are the most common TBE mistakes?
Common ones are trusting the supplier's compliance matrix without checking the rest of the offer, comparing suppliers against slightly different requirement lists, and missing a qualified answer such as "where practicable". Others are mixing up which supplier said what, and asking clarification questions that don't name the clause. Each can lead to accepting an offer that doesn't meet the specification.
Why are suppliers evaluated separately?
Each supplier is checked against the same baseline on its own, so one offer never colours the reading of another. Supplier identity is kept on every line, so you always know whose answer you are looking at. That makes the comparison fair and lets you defend it if a supplier asks why their offer was marked down.
Does the tool pick the winning supplier?
No. It prepares the evidence a person decides on. It shows how each supplier answers each requirement, with quotes, and highlights deviations and gaps. It never recommends or selects a winner. The technical and commercial decision stays with your team, which is how most buyers' procurement rules require it to work.
What is a qualified response?
A qualified response agrees with the requirement but adds a condition. Examples are "complies where practicable", "subject to final design" or "complies, see note". These are not full compliance, and they are easy to miss in a long offer. The tool reports them separately from clean answers so your engineer can decide whether to ask for clarification.
How does criteria weighting work?
If you upload evaluation criteria and turn on weighting, the tool applies your weights when it summarises each supplier's responses. Weighting is your rule, not the tool's. It only organises the evidence; the final scoring decision remains with your evaluators. If you don't use weighting, every requirement is shown on the same footing.
Why flag mandatory requirements separately?
Some requirements must be met for an offer to be acceptable at all, while others can be traded off. Flagging mandatory requirements on their own lets you see straight away whether any supplier fails one. A supplier who misses a mandatory requirement usually needs a clarification or is set aside, whatever their score on the rest.
How are clarification questions drafted?
When the check is on, the tool drafts a question wherever a supplier's answer is missing, unclear, qualified or in conflict with another part of their offer. Each question names the requirement and quotes the supplier's text. Your engineer edits and sends the questions. OdysseyGPT doesn't send anything to suppliers itself.
What does a supplier expect from the buyer's TBE?
Suppliers expect to be judged against the same requirements as everyone else, using what they actually wrote. They expect clear clarification questions that name the clause, and a chance to answer before a decision. A TBE built on cited evidence makes it easier to explain the outcome to suppliers who weren't selected.
What do I get back from the Technical Bid Evaluation?
You get one evidence table with each requirement on its own line and each supplier's response beside it, quoted from their offer. Deviations, gaps and qualified answers are marked, and high-risk deviations highlighted if you asked. Draft clarification questions are listed per supplier. You can export the results as CSV or JSON.
Can suppliers use this tool on their own offer?
The tool is built for comparing several offers against one baseline, which is the buyer's job. A supplier checking its own offer against a customer specification will usually get more from Document Review, which gives each requirement a status and builds a compliance matrix and deviation list. Some teams run both to see their offer the way a buyer will.
Does it handle offers that use different units?
Offers often state the same value in different units, such as bar and psi. The tool compares each offer against the baseline, and a value it can't match safely is reported for review rather than guessed. Your engineer should still check any finding that turns on a unit conversion before it goes into a clarification question.
What are the limits of the Technical Bid Evaluation?
It only checks against the documents you upload, so a requirement in a missing document can't be found. It reads text and tables, not engineering drawings. It does not do the commercial evaluation and never chooses a supplier. It is in beta, so we review each team's first runs with them against a TBE they have already done by hand.
Who uses the Technical Bid Evaluation tool?
Procurement and project engineers at EPC contractors and owners use it to compare supplier offers. Buyers at equipment makers use it when they buy in components or subcontracted items. Engineering managers use the evidence table to review the decision. It suits any team that must compare several offers against one specification and explain the result.
Is the Technical Bid Evaluation available now?
The Technical Bid Evaluation is in beta. You can request access, and we onboard each team ourselves: we agree a real specification and set of offers to start with, run it with you, and check the results together. That way you see how it handles your documents before you rely on it. Document Review, our production tool, is generally available.
Which tools come before and after the Technical Bid Evaluation?
Before it, the Customer Specification Review builds the requirement baseline, and Datasheet Comparison checks supplier datasheets against yours. After it, the Deviation Register tracks every deviation through to a decision. Once an order is placed, the Quotation-to-PO Review checks what the purchase order changed from the accepted offer.
Where it sits in the order lifecycle
Related standards, guides and templates
Try the Technical Bid Evaluation on your own documents
Tell us which documents you want to check first. We set up your workspace and run the first package with you.