Product tools · Tender stage
BetaCustomer specification review: turn a customer specification into a cited requirements register
Customer Specification Review reads a customer specification and its supporting documents and lists every requirement in a register. Each line is technical, quality, documentation, test or commercial, and quotes its exact clause. It flags ambiguous requirements and missing information. Bid and application engineers use it to start a tender response.
Customer Specification Review 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.
- Supporting specifications (optional, several files)
- Applicable standards (optional, several files)ASME, EN, API or client standards referenced by the specification.
- Internal baseline specification (optional)Optional. Enables comparison against your own standard.
What it checks
- Extract technical requirements
- Extract quality requirements
- Extract documentation requirements
- Extract tests and inspections
- Extract purchaser options
- Identify ambiguous requirements
- Identify missing information
- Compare against internal standard
What you get out
- A requirements register, one obligation per line, each with its source clause quoted
- Requirements grouped as technical, quality, documentation, tests and inspections, or commercial
- Ambiguous requirements and missing information, such as TBA or HOLD items, flagged for clarification
- Optional differences from your internal standard
- CSV or JSON export
Who uses it: Bid and proposal engineers, Application engineers, Quality engineers, Project managers who answer RFQs.
20 questions about the Customer Specification Review
What is a customer specification?
A customer specification is the document a buyer issues to say what equipment it wants and how it must be made, tested and documented. It may be a project specification, a company standard or a set of both. It usually calls up other standards, such as API, ASME or EN. Suppliers must answer it, clause by clause, when they make an offer.
What is a requirements register?
A requirements register lists every obligation in a specification as a separate line. Each line holds the clause reference, the requirement text, its type and its status. It is the starting point for a compliance matrix and a deviation list. Keeping one obligation per line matters, because a clause with three demands needs three answers.
What does the Customer Specification Review do?
It reads the customer specification and any supporting documents you add and lists every requirement it finds. Each requirement is kept separate, classified and cited to its exact clause. It can pull out technical, quality, documentation, test and commercial requirements and purchaser options. It also flags ambiguous wording and missing information so you can ask before you bid.
Which documents do I upload?
Only the customer specification is required. You can add supporting specifications, the standards it calls up, and your own internal baseline specification. Adding the internal baseline lets the tool compare the customer's requirements against your standard. It reads PDF, Word, Excel and CSV files, so specifications with long tables work as well as plain text.
How do engineers build a requirements register by hand?
An engineer reads the specification from start to finish and copies each requirement into a spreadsheet with its clause number. They split clauses with more than one demand, tag each line by type and note anything unclear. Then they chase the standards the specification calls up. On a long specification this can take days, and requirements in tables and notes are easy to miss.
What are common mistakes when reading a customer specification?
Common ones are missing requirements in tables, notes and appendices, and treating a clause with several demands as one line. Others are skipping the documentation and test requirements, which often sit far from the technical clauses, and ignoring purchaser options that the buyer has not yet chosen. Each missed line can become an obligation you didn't price.
What is a purchaser option?
Many standards let the buyer choose between alternatives, such as an extra test or a different material. These are often called purchaser options or items to be specified by the purchaser. The specification or datasheet should say which ones apply. If it doesn't, ask. The tool can extract purchaser options when you turn that check on.
What counts as an ambiguous requirement?
A requirement is ambiguous when two readers could fairly take it two ways. Examples are "where practicable", a reference to a standard with no edition, or two clauses that conflict. The Customer Specification Review flags these so you can raise a clarification before you bid, rather than finding out what the customer meant after the order.
What does missing information look like in a specification?
Missing information shows up as placeholders such as TBA, TBC or HOLD, blank fields in a datasheet, or a reference to a document that wasn't sent. The tool flags these items so your team can request the data. Pricing against a guess is risky, because the customer can fill in the gap later in a way that costs you more.
What do customers expect a supplier to do with their specification?
They expect you to read all of it, including the standards and documents it calls up, and to answer every clause. Anything you can't meet should be declared as a deviation, and anything unclear raised as a clarification, before the order. Many buyers treat silence as full compliance, so a requirement you missed is still one you must meet.
How does it compare a customer specification with my own standard?
If you upload your internal baseline specification and turn on the comparison, the tool checks the customer's requirements against it. It reports where the customer asks for something different from your standard, with a quote from each document. That shows where your usual design or test plan won't meet the order, which is where most deviations come from.
How are requirements cited?
Each requirement in the register quotes the exact clause it came from, with its location in the source document. Your engineers can open the source and check the wording themselves. A cross-reference to another clause or standard is kept as a reference, not treated as an ambiguity, so the register shows where the full requirement really lives.
Does it read the standards the specification calls up?
It reads the standards you upload with the specification. If a specification calls up a standard you didn't include, the tool can't read its requirements, but it can still show the reference so you know to get it. For a full register, upload the editions the specification names, along with any client standards.
What do I get back from the Customer Specification Review?
You get a register with one obligation per line. Each line has its type, the quoted clause and its source. Ambiguous requirements and missing information are flagged, and differences from your internal standard are listed if you asked for them. You can export the register as CSV or JSON and use it to build your compliance matrix.
How is this different from Document Review?
The Customer Specification Review starts from the customer's documents only and lists what they require. Document Review compares a base document against other documents in both directions and gives each requirement a status, such as complies or deviates. Many teams build the register first, then use Document Review to answer it against their datasheets.
Does it decide whether we comply?
No. This tool lists and classifies requirements; it doesn't judge your offer against them, except where you ask it to compare with your internal standard. Your engineers decide your position on each line. OdysseyGPT does not send anything to the customer, and your team owns the final register and response.
What are the limits of the Customer Specification Review?
It only reads the documents you upload. It reads text and tables, not engineering drawings, so requirements shown only on a drawing need a person to check. It doesn't know unwritten customer preferences. It is in beta, so we review each team's first runs with them and check the register against a specification your engineers know well.
Who uses the Customer Specification Review?
Bid, proposal and application engineers use it at the start of a tender to see everything the customer asks for. Quality engineers use it to pull out test, inspection and documentation requirements. At smaller equipment makers, the project manager who answers RFQs often runs it. It suits anyone who has to answer a long customer specification.
Is the Customer Specification Review available now?
The Customer Specification Review is in beta. You can request access, and we onboard each team ourselves: we pick a real specification to start with, run it with you, and check the register together. That way you see how it handles your customer's documents before you rely on it. Document Review, our production tool, is generally available.
Which tools come before and after the Customer Specification Review?
Before it, Document Review compares your base document with the customer package in both directions. After it, the Datasheet Comparison checks datasheets field by field, and the Technical Bid Evaluation compares supplier offers against one requirement set. The Deviation Register then tracks each deviation through to the customer's decision.
Where it sits in the order lifecycle
Related standards, guides and templates
Try the Customer Specification Review 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.