How to create a server RFQ.
An RFQ that gets clean responses does two things well: it states one unambiguous requirement, and it tells responders exactly how to answer.
The sections an RFQ needs
| Section | Contents |
|---|---|
| Scope | What is being bought, in one paragraph, including quantity. |
| Specification | The configuration, field by field, with open items marked. |
| Constraints | Rack, power, cooling, site and compatibility limits. |
| Commercial | Delivery window, support term, currency, validity period. |
| Response format | Itemized configuration, per-line lead time, alternatives. |
| Evaluation | What the decision will be based on. |
Ask for alternatives explicitly
The most useful line in an RFQ is often an invitation: if a different configuration meets the requirement better, propose it alongside the requested one. Without that line, responders quote exactly what you asked for, even when they can see a better fit.
Set one deadline and one contact
Clarification questions should have a single route and a stated cut-off, and answers that change the requirement should reach everyone quoting. Otherwise responses end up priced against different assumptions, and the comparison is meaningless.
What to leave out
- Vendor-specific part numbers where a generic requirement would do
- Internal project names and confidential context
- Budget figures, unless a ceiling genuinely needs to be enforced
- Requirements nobody will verify or evaluate
How 46 Systems handles this
Submitting a configuration or a described requirement produces a normalized requirement document and runs the clarification and response process for you, including keeping your identity out of the market where you prefer that.
Turn this into a request.
Configure a server, or describe the requirement in your own words.