A Good RFQ Makes the Quotations Boring to Compare
A C&I BESS RFQ should define three things before asking for a price: what the system must accomplish, exactly what the supplier must provide, and how performance will be accepted. At minimum, specify site/load data, required kW and kWh, operating modes, grid conditions, supply scope, standards, communications, FAT/SAT requirements, warranty, delivery boundary, and commercial milestones.
DOE's current BESS procurement resources follow the same principle: technical requirements should be defined during procurement rather than left for clarification after supplier selection.
I know an RFQ needs work when its technical section says:
Please quote 500 kWh commercial BESS.
The supplier knows the battery capacity.
Almost everything else is still unknown.
Give Suppliers the Problem Before the Product
Instead of starting with a cabinet size, describe the duty.
For example:
Application:
factory peak shaving + backup
Maximum site demand:
780 kW
Target grid limit:
600 kW
Critical backup load:
120 kW
Required backup duration:
60 minutes
Existing PV:
300 kWp
Grid:
400 V, 50 Hz
Transformer:
1,000 kVA
Now Supplier A and Supplier B are at least trying to solve the same problem.
For peak-shaving projects, attach 15-minute or finer interval load data where available. For backup, include the critical-load schedule. For PV integration, provide PV inverter and generation information.
A monthly bill alone cannot show whether a 180 kW peak lasts fifteen minutes or three hours.
That difference can change the battery substantially.
Separate kW From kWh—and Define the Measurement Boundary
Suppose the project specification calls for:
250 kW PCS
500 kWh battery
I would immediately add several definitions.
Is 500 kWh:
nominal/nameplate energy?
usable DC energy?
guaranteed usable AC energy?
Likewise, is 250 kW continuous at the expected site temperature and SoC, or merely a nominal converter rating?
A useful technical schedule might look like this:
| Requirement | Buyer Should Define |
|---|---|
| PCS power | Continuous kW and overload requirement |
| Battery energy | Nominal and required usable energy |
| Duration | Required duty at specified power |
| Efficiency | Measurement boundary and test conditions |
| SoC window | Operating/reserve requirements |
| Ambient range | Site minimum/maximum temperature |
| Degradation | End-of-life performance requirement |
| Grid | Voltage, frequency, connection point |
For industrial lithium batteries, IEC 62619:2022 covers safety requirements and tests for secondary lithium cells and batteries used in industrial applications, including stationary ESS. Certification requirements should identify the actual applicable standard and offered model rather than simply saying "IEC certified."
Scope Is Where the Cheapest Bid Usually Changes Price
Before looking at the total, I would mark every item as:
Included / Excluded / Optional / By EPC / By Owner
Do that for:
battery cabinets;
PCS;
BMS and EMS;
HVAC or liquid cooling;
fire detection and suppression;
AC/DC protection;
transformer and switchgear;
metering and SCADA interface;
communication gateway;
cables;
foundation drawings;
spares;
FAT;
commissioning/SAT;
training;
remote support.
Imagine two bids:
Supplier A: $205,000
Supplier B: $178,000
Then you discover A includes commissioning, EMS, spare parts and the transformer interface while B excludes all four.
The $27,000 difference was never purely a price difference.
It was a scope difference .
DOE procurement guidance similarly treats hardware, controls, technical specifications, commissioning, interconnection, and related project responsibilities as procurement-stage issues.
For a Ruibit/Dawnice RFQ, I would therefore ask for a line-by-line compliance and scope response instead of accepting one bundled price.
Communications Need an Owner
I would include a simple interface schedule:
BMS ↔ PCS
PCS ↔ EMS
EMS ↔ site meter
EMS ↔ SCADA/BMS
Remote monitoring ↔ cloud/local network
Then specify required protocols where relevant:
Modbus TCP/RTU
CAN
Ethernet
digital I/O
and the required data points, alarms, historian access, time synchronization and cybersecurity requirements.
But the most important column is:
Responsible Party
Because "Modbus supported" does not tell me who must make two devices actually communicate during commissioning.
If the battery supplier, PCS vendor and EPC each assume somebody else owns integration, the owner eventually owns the problem.
FAT and SAT Belong in the RFQ, Not in an Email Before Shipment
Do not write:
Factory testing required.
Define what acceptance means.
Depending on the project, FAT may verify:
BMS/PCS/EMS communications
charge/discharge operation
protection and alarms
thermal-management controls
emergency stop
remote monitoring
documentation and firmware versions
SAT should prove the installed system performs the purchased application.
If the project was bought for peak shaving, test peak-shaving control.
If it was bought for backup, test the backup sequence.
If the contract guarantees usable energy, define the measurement boundary and acceptance conditions.
DOE's BESS technical specification resource is explicitly intended as a customizable procurement template, which is a useful reminder that acceptance criteria should be project-specific rather than copied blindly from another installation.
Make Payment Follow Evidence
Commercial terms should reinforce the technical process.
I prefer milestones such as:
technical agreement approved
→ design freeze
→ FAT accepted
→ shipping documents approved
→ delivery
→ SAT/commissioning accepted
The percentages depend on the transaction, but the principle is important.
If nearly all payment is released before FAT, the buyer has very little leverage when FAT discovers a problem.
The RFQ should also state:
Incoterm
lead time
packing and dangerous-goods documentation
insurance responsibility
commissioning/travel costs
warranty start date
performance warranty
spare-parts obligations
service response
software/firmware support
and responsibility for freight and labor during warranty claims.
A ten-year BESS deserves more commercial definition than "10-year warranty included."
The RFQ Is Finished When Three Suppliers Can Quote the Same Job
That is my test.
If three suppliers can interpret the document as three different BESS projects, the RFQ is not finished.
A useful Ruibit/Dawnice inquiry should let engineering answer:
What must the BESS do?
Under what site conditions?
What equipment and services are included?
What evidence must accompany the product?
How will FAT and SAT determine acceptance?
Where does each party's responsibility end?
Once those questions have fixed answers, price becomes meaningful.
The purpose of a C&I BESS RFQ is not to tell the manufacturer how to design every busbar and control loop.
It is to make it difficult for two suppliers to quote different scopes and still pretend they are offering the same thing.
FAQs
1. What information should be included in a C&I BESS RFQ?
Include site and interval load data, required kW and kWh, operating objectives, grid and transformer information, environmental conditions, system architecture, communications, certification requirements, FAT/SAT criteria, warranty, and commercial terms .
2. Why should kW and kWh be specified separately in a BESS RFQ?
kW defines power capability , while kWh defines energy capacity and duration . Buyers should also clarify whether kWh refers to nameplate, usable DC, or guaranteed usable AC energy.
3. How should buyers compare the scope of different BESS quotations?
Create an Included / Excluded / Optional / By EPC / By Owner matrix covering batteries, PCS, EMS, cooling, fire protection, transformer, switchgear, communications, commissioning, training, spares, and support.
4. Should FAT and SAT requirements be included in the RFQ?
Yes. Define the required tests and measurable pass/fail criteria before purchase . FAT verifies the system before shipment, while SAT confirms that the installed BESS performs its required functions at site.
5. What commercial terms should a BESS RFQ define?
Specify payment milestones, Incoterm, lead time, shipping documentation, commissioning costs, warranty start date, performance obligations, spare parts, service response, software support, and responsibility for warranty freight and labor .