When an RFP lands in a CPE vendor’s inbox, the first thing most teams do is open the spec sheet.
That’s the first mistake.
The spec list is the least important part of an RFP. The real signal — the one that decides whether your proposal wins, loses, or never gets read past page two — is buried somewhere else entirely. It’s the answer to a question almost nobody on the vendor side asks out loud:
Why is this carrier running this RFP, right now, at all?
In eleven years on the vendor side of Tier-1 ISP business — across hundreds of proposals and millions of deployed devices — I’ve come to believe there are only two real answers to that question. Everything else is a variation, a footnote, or a procurement formality.
Two Reasons. Only Two.
Reason 1: Price compression on an existing product.
The carrier already has a CPE in the field. It works. Subscribers are happy enough. But the unit cost is eating into margin, or a competing vendor has signaled they’ll go lower, or procurement is under pressure to hit a number for the fiscal year. The RFP exists to re-price something that already exists.
You can read this RFP from the language alone. The volume forecasts are confident and specific. The timeline is tight but not urgent. The feature list looks suspiciously like the spec sheet of the device already deployed — because it is the spec sheet of the device already deployed, with two or three additions that procurement thinks sound modern.
Reason 2: Launching a new service.
The carrier is moving onto a new network — XGS-PON over an aging GPON footprint, DOCSIS 4.0 onto a hybrid plant, a new Wi-Fi tier they want to monetize. The RFP exists to find a CPE that can enable something that doesn’t exist yet.
This RFP reads completely differently. Volume forecasts are softer, often staged (“Year 1: 50K units; Year 2: TBD pending market response”). The feature list is forward-looking and sometimes vague. Timelines are anchored to a service launch date, not a procurement cycle. And there’s almost always a PoC phase tucked somewhere into the schedule.
Everything else — regulatory compliance refreshes, end-of-life replacements, second-source qualifications — exists, but they’re variations on these two themes. A regulatory RFP is a price compression RFP wearing a compliance hat. An EOL replacement is usually a price compression RFP where the carrier has slightly less leverage than they’d like to admit.
Two reasons. The rest is detail.
Why Vendors Misread the Signal
Here’s what happens when you misread which RFP you’re in.
I’ve watched proposal teams spend three weeks engineering brilliant new features into a bid that was going to be decided on cost-per-port before the RFP ever left the carrier’s procurement office. The team wins the technical review and loses the deal by 40 cents.
I’ve also watched the inverse — vendors who walked into a new service RFP with their sharpest pencil, cut their margin to the bone, and lost to a competitor priced fifteen percent higher. Why? Because the carrier wasn’t buying a price. They were buying a possibility. They needed a partner who could help them launch something, not a vendor who’d already pre-conceded the economics.
Both teams worked hard. Both teams did good engineering. Both teams misread the RFP.
The most expensive mistake in this business isn’t losing on price. It’s bringing the wrong proposal to the wrong RFP — and being convinced, all the way to the loss notification, that you brought the right one.
The Layer Above CPE
There’s one more thing that makes this harder, and it’s the piece most vendors never see.
By the time a CPE RFP is on your desk, the carrier has already made the bigger decisions. The head-end has been chosen — the OLT, the CMTS, the core network gear. The economic model for the new network has been built. Cost-per-subscriber has been calculated. ROI per node has been signed off by finance.
In other words: you are not bidding into an open question. You are bidding into a P&L that has already been written, in pencil, by someone you’ll never meet, six to twelve months before the RFP arrived.
This is the single most underrated piece of leverage in CPE business development — and the reason CPE almost always comes last in the RFP stack. I’ll come back to this in a future piece, because it deserves its own.
What This Means If You’re on the Vendor Side
Three things, if you take nothing else from this:
First, read the RFP for purpose before you read it for specs. The volume language, the timeline structure, the presence or absence of a PoC phase, the tone of the feature list — these tell you which of the two RFPs you’re holding. Spec response comes later. Sometimes much later.
Second, if it’s a price compression RFP, the entire game is your P&L. New features will rarely save you. A defensible, transparent, strategically structured cost model will. This is the part of the job that gets the least public attention and decides the most outcomes.
Third, if it’s a new service RFP, lead with enablement, not price. The carrier is buying a future. Show them you understand the future they’re trying to buy — and price will become the second conversation, not the first.
The spec sheet is real. It matters. But it’s the last filter, not the first one. By the time the carrier is comparing spec sheets, the proposals that misread the why have already been quietly moved to the second pile.
Next in this series: why CPE always comes last in the RFP stack — and why that’s the most underrated piece of leverage in CPE business development.
