SPREAD's deployment at the customer's bid desk is Requirements Manager, a knowledge graph that ingests historical RFQs (requests for quotation), structured BoMs (bills of materials), internal product knowledge, and current operator specifications. Five plants operate the bid desk across Europe, scoping roughly 25 RFQs per year at around 13,000 engineering hours per RFQ. The headline outcome from the joint evaluation against a real national-operator RFQ, 55 / 37 / 8, half the requirements cleanly covered by the customer's existing portfolio, a third partially covered, the residual genuinely new engineering work.
The most useful thing in this story is not the 55%. It is the moment the customer told us we'd built the wrong business case.
The bottleneck in European rail tendering
In regulated European rail tendering, the procurement cadence is exogenous. National operators publish multi-thousand-page RFQ specifications on calendars set by their own political and operational cycles. No vendor speeds them up.
What is elastic in this market is not bid throughput. It is the depth of analysis a bid manager can run on the volume that already arrives. The constraint is senior-engineer time, not procurement-process time.
The customer correction
Three months into the engagement, we had modeled the value around 100 RFQs per year, the rate we had seen at automotive Tier 1s of comparable scale. In a routine weekly review on 16 April 2026, the customer's bid desk lead pushed back on the record:
"You mentioned 100 RFQs in your business case description. This number is too high for us. Normally we have on each location about five new quotations per year. We have about five locations, so we have about 25 new RFQs per year. So we don't have hundreds."
"The big benefit for us is really these hours. He mentioned 13,000 hours of effort for each RFQ. There is the big leverage."Bid desk lead, European rail OEM · Joint evaluation, 16 April 2026
The correction reframed the engagement. We had been positioning Requirements Manager as a throughput tool, more bids per quarter. The bid desk does not run more bids; the procurement cadence is not elastic. What is elastic is the depth of analysis the bid desk can run on the volume it already has.
Not a throughput tool. A depth tool.
Once that landed, the rest of the POC made sense.
What changes for the bid analyst
Before Requirements Manager, the bid analyst walks the RFQ requirement by requirement, cross-references internal Excel sheets and prior program records, searches for validated solutions, and pings senior engineers for tribal knowledge. The work is competent. It is also bottlenecked.
- Open the RFQ PDF (thousands of pages)
- Walk requirement by requirement, manually
- Cross-reference Excel sheets and prior programs
- Hunt for validated solutions in tribal knowledge
- Re-derive effort estimates from scratch
- Document each requirement's status
- Ingest the RFQ into the graph
- Review the surfaced classifications (55 / 37 / 8)
- Confirm or adjust each classification
- Direct senior engineering at the 8% genuinely new
What the joint evaluation actually measured
The engagement ingested the customer's historical RFQs, structured BoMs, internal product knowledge, and current operator specifications into a single graph. SPREAD's lead and the customer's bid desk lead ran a joint evaluation against a real national-operator RFQ, the actual document, scored ticket by ticket against ground truth.
The number that matters is not the headline 55%. It is the structure underneath:
- 55% Covered. the customer's existing portfolio cleanly satisfies the requirement. The analyst's job compresses to confirm and quote.
- 37% Partially covered. A base solution exists but needs adjustment. The analyst's task changes shape, from search-and-synthesize to evaluate-and-adjust.
- 8% Not covered. Net-new engineering. The analyst engages the broader engineering organization from scratch.
Each band points at a different operational change. The 55% saves analyst time at the front of the funnel. The 37% changes the kind of work being done. The 8% is hard, and SPREAD's job is to make it known to be hard early.
What is redistributed, not removed
The 13,000-hours-per-RFQ figure is not reduced by Requirements Manager. It is redistributed. The hours that used to go into searching get redirected into evaluating, adjusting, and engineering the genuinely new. Senior judgment compresses to where it is needed; senior engineers no longer have to be in the room for the 55% Covered category. Their attention concentrates on the 45% that warrants their depth.
Same total volume of work. Different shape. Different value.
What's next on the deployment path
The model is honest. The classifications are auditable. The next step on the deployment path is integrating Requirements Manager into the bid workflow itself. From the bid desk lead in the same exchange:
"It's about really the integration of the tool in the workflow of the customer's bidding process. There is some point that was highlighted, and obviously it makes sense because this is not integrated, the value added is not real, basically. And on that one, I'm still not completely sure what is the way forward."Bid desk lead, European rail OEM
Workflow integration is the next step on the deployment path, not model quality. That is the right question for a depth tool: a graph that lives outside the bid analyst's hands recovers no hours.
What the customer taught us
The default assumption when scoping a new engineering tool is faster is better. Compress the cycle, increase throughput, win on speed.
The customer's correction inverts that. Their bid desk does not want more bids. They want deeper bids on the same volume. The hours that get recovered are not redeployed as additional throughput; they are redeployed as additional depth on the engagements they already have. Different value, different framing.
Program shape
| Deployment | Requirements Manager at a European rail OEM bid desk |
|---|---|
| Bid desk footprint | 5 plants across Europe |
| RFQs scoped per year | ~25 (5 plants × ~5 quotations) |
| Engineering hours per RFQ | ~13,000 |
| Annual hours behind the bid desk | ~325,000 |
| Joint evaluation, real national-operator RFQ | 55% covered · 37% partial · 8% net-new |
| What is changing | The shape of senior-engineer time, not the total |
| Next step | Integration into the bid analyst's workflow |