So the boss dropped an RFQ on your desk. “We need new thingamajobs!” they declare, having just read a blog post about “optimizing synergies” or some other nonsense. Now it’s your job to translate that managerial grunt into a document that won’t make vendors laugh, weep, or—worst of all—submit a bid so vague you’ll be arguing about what you actually bought for the next three years.

Welcome to the thunderdome of writing a hardware specification for a commercial Request for Quote (RFQ). This isn’t poetry. It’s a legally-adjacent piece of technical warfare. Do it wrong, and you’ll get a box of mismatched bolts and shattered dreams. Do it really wrong, and someone might get hurt. But hey, no pressure.

I’ve seen specs written on napkins (literally). I’ve seen 200-page treatises that somehow forget to mention the operating voltage. Let’s try to land somewhere in the middle, shall we? Forget “professional” writing guides. This is from the trenches, where coffee is cold and patience is thin.

Part 1: The “Why Are We Even Here?” Foundation

Before you type a single word, answer this: What is this thing supposed to DO? Not what it is. What it does. “It’s a pump” is useless. “It must move 50 gallons per minute of 30% sulfuric acid solution at 80°C from Tank A to Tank B against a 15-meter static head, with a ±2% flow control, and it must do it while sitting in a non-conditioned outdoor shed in Saskatchewan” is a start. The function is king. Every single line in your spec should trace back to fulfilling that core mission.

Also, decide early: Is this a performance spec or a design spec? This is where most people faceplant.

• Performance Spec: You describe the problem, the environment, the required outcome. “Make it work like this.” Vendors can propose their own designs. This can get you innovative solutions. It can also get you proposals you can’t even compare because they’re all so different. You need strong evaluation skills.
• Design Spec: You describe the exact solution, down to the bolt threads and paint color. “Make it exactly like this drawing.” This is good for replacements, or when you have a specific patent or integration need. It also makes you responsible for every single flaw in the design. The vendor just has to follow your possibly-idiotic drawings. Choose your poison.

Part 2: The Meat & Potatoes (Slightly Burnt)

Structure? We don’t need no stinking structure! Okay, we do. But think of it as a messy checklist, not a dissertation. Use sections. Number your requirements. For the love of all that is holy, make them individually traceable. REQ-1, REQ-2, etc. You’ll need this later when a vendor says “we met all requirements!” and you get to say “Show me where you meet REQ-47, regarding the galvanic isolation.”

Here’s what goes in, in roughly this order:

1. Scope & Overview

Two paragraphs. What this is, what it’s for. Don’t blather. If it’s a “submersible slurry pump,” say that. Not a “fluid dynamic transfer apparatus.”

2. Applicable Documents & Standards

List EVERY standard, code, internal guideline, or previous spec that applies. ASTM, ASME, ISO, IEC, NEMA, UL, CSA, your company’s “Widget Design Manual 007.” If you forget to cite a standard, and the vendor builds to a cheaper one, you lose. This is a CYA section. CYA.

3. Functional Requirements

The “what.” What are the inputs? What are the outputs? What are the control parameters? Flow rates, pressures, speeds, tolerances, setpoints, accuracy. Use numbers. “Fast” is not a number. “Cycle time less than NA seconds” is a number. Include all operating modes: Normal, standby, emergency, maintenance, etc.

4. Physical & Interface Requirements

The “how big and how does it connect.” Dimensions. Weight. Mounting points. Connection types (Flanges? NPT? SAE? Quick-disconnect? Pinouts?). I/O interfaces (Ethernet IP? Modbus TCP? 4-20mA? Dry contacts?). Power requirements (Voltage, phase, frequency, inrush current, power factor). If it needs to fit in an existing hole, include the drawing of the hole. “Must interface with existing system XYZ” is useless. Provide the interface control document for XYZ.

5. Environmental & Duty Cycle Requirements

Where does this poor thing have to live? Temperature range (operating and storage). Humidity. Ingress Protection (IP rating, NEMA rating). Chemical exposure. Shock and vibration specs. Expected service life (e.g., “20 years operation with less than 2% failure rate”). Duty cycle (e.g., “24/7 continuous operation” vs. “30 minutes on, 30 minutes off”). Don’t just say “outdoor.” Say “Outdoor, sheltered, IEC 60721-3-4 Class 4C2.”

6. Material & Construction Requirements

What’s it made of? This is critical for corrosion, wear, hygiene, strength. Don’t just say “stainless steel.” Say “AISI 316L stainless steel, passivated per ASTM A967.” Or “Polypropylene copolymer, UV-stabilized.” Specify material grades. If it’s painted, give the paint system (primer, topcoat, thickness, application standard).

7. Performance Testing & Acceptance Criteria

This is where you separate the professionals from the cowboys. How will you prove it works before you sign the check? What factory acceptance tests (FAT) are required? What site acceptance tests (SAT)? Be specific: “Supplier shall conduct a 4-hour continuous performance test at maximum rated load, recording data every 60 seconds. Test report must include all data and be signed by a responsible engineer.” What instruments? To what accuracy? Who pays for what? The vaguer this is, the more you’ll fight later.

8. Documentation & Deliverables

What comes in the box besides the widget? You want drawings (format? PDF? Solidworks?). You want manuals (language? In electronic searchable PDF?). You want test reports, certificates of conformance, material certifications, lubrication charts, spare parts lists. List it all. “Appropriate documentation” will get you a poorly Xeroxed sheet from 1982.

9. Commercial & Logistics Stuff

Packing requirements (crate? anti-corrosion? moisture absorber?). Shipping markings. Incoterms. Warranty (duration, what it covers, what it excludes). Lead time expectations.

Part 3: The Landmines (Where You Will Screw Up)

• Ambiguity: The devil lives here. “High-quality components.” What does that mean? To you, it means name-brand bearings. To the low-bidder, it means the cheapest thing that won’t fall apart in the first week. Quantify everything.
• Conflicting Requirements: “Total weight not to exceed 50 kg.” “Construction to be from 1/2-inch thick carbon steel plate.” One of these is wrong. Have someone review the spec who will actually think about it.
• Assuming Intelligence: Don’t assume the vendor knows your industry, your process, or your slang. Define acronyms. Explain context. You’re not writing for your buddy in the next cubicle; you’re writing for a global supply chain.
• Forgetting Maintainability: How do you change the filter? How do you lubricate the bearing? Is there an access panel, or do you need to disassemble the whole universe? Think about the poor maintenance tech at 2 AM.
• The “Or Equal” Trap: You write “Brand X Model 1234 proximity sensor, or equal.” Great. Now you have to evaluate what “equal” means. Is it just the datasheet specs? What about mean time between failures (MTBF)? Supply chain reliability? Form/fit/function is not enough. Either specify the exact part, or write a performance spec for the sensor and let them propose.

Part 4: The Grumpy Expert’s Bonus Rant

• Use Appendices: Put big drawings, data sheets, existing interface documents here. Don’t clutter the main spec.
• Write for Evaluation: Make your spec easy to turn into a vendor scorecard. Each clear, numbered requirement can be graded: “Compliant,” “Non-Compliant,” “Deviated (with explanation).”
• State the Obvious: “All fasteners shall be metric.” “All text shall be in English.” “All electrical connections shall be labeled with permanent, legible markers.” You think it’s obvious. It’s not.
• Kill the Marketing Fluff: Vendors will skim your spec for requirements and ignore the fluff. Don’t waste your time writing “This system will revolutionize our productivity…” Save that for the internal justification memo.

The Final, Unforgivable Sin

You spent weeks on this. You got beautiful bids. You selected a vendor. They built the thing. It passes all your tests. You’re ready to install it.

STOP.

Did you talk to the Authority Having Jurisdiction (AHJ)? No, not your boss. The AHJ. The building inspector. The fire marshal. The electrical code official. The environmental regulator. That entity whose badge and rulebook trumps your beautiful, perfect spec.

Your state-of-the-art, spec-compliant machine might violate local electrical code amendments. Its emergency stop might not meet the latest safety standard enforcement in your county. The paint finish might not be allowed in that classified area. The noise output might violate a new municipal ordinance.

You can write the greatest hardware spec in history, but if you ignore the AHJ, you own a very expensive, non-operable paperweight. Or worse, you create a hazard. The vendor did what you asked. You didn’t ask the only people whose opinion actually matters for turning it on.

So, do your homework. Call the inspector before you finalize the spec. Build their rules into it. This isn’t a suggestion; it’s the last line of defense between you and a world of very expensive, grumpy pain.

Now go write your spec. And make it less terrible than the last one.