Here at Netify we built our RFP Builder because the same problem kept coming up in SD-WAN procurement, organisations would end up comparing vendor marketing decks rather than structured responses to their actual requirements, making evaluation almost impossible. Our RFP builder changes that, enabling you to produce a complete RFP from our pre-built question library (or by adding in your own custom questions), publishing directly to the providers on your shortlist, and allowing you to receive structured responses you can score module-by-module, all in one place, rather than chasing vendors for comparable answers across separate documents.
What the RFP Builder does
The four things the builder handles that are hardest to replicate manually are: producing a complete, structured RFP without starting from a blank document; getting that brief in front of providers in a format they have to respond to consistently (rather than in whatever format they'd prefer); eliminating the inconsistent vendor responses that make side-by-side comparison difficult; and scoring those responses inside the platform so you're not doing it across a spreadsheet you've built yourself.
The question library runs to 115+ standardised professional questions across 13 modular sections, and you toggle sections on or off depending on your project's complexity. If the pre-built questions don't cover something specific to your legacy hardware or compliance situation, the AI assistant drafts bespoke questions, it's trained specifically on SD-WAN procurement rather than being a general-purpose tool, which makes a difference for technical questions that need to be phrased precisely to get useful vendor answers.
The Netify SD-WAN RFP standard
Broadly, we'd argue that an SD-WAN RFP needs to do two things well, define your environment and requirements clearly enough that vendors can respond specifically rather than generically, and structure those requirements into sections that produce comparable answers. The Netify Builder covers 13 modular sections with 115 pre-written questions to that end. The sections you're most likely to toggle on for a standard evaluation are covered below, though regulated sectors (healthcare, financial services, retail) typically need the sector-specific extensions on top of the core set.
Evaluation criteria: what to score vendors on
We often find that the criteria most organisations struggle to evaluate are the ones where vendors can claim capabilities without evidence, something that our structured questions prevent and our builder's weighted questions focus on the specifics rather than the headline claims.
On deployment, the question is zero-touch provisioning capability for rapid site rollout, not whether vendors support ZTP, but what their actual workflow and timeline looks like from hardware delivery to operational status.
For failover, we ask for LTE/5G failover with defined switchover times rather than a general statement of resilience capability, because the threshold is what actually matters when a primary circuit goes down.
Performance questions focus on latency and jitter targets based on real-time application health, which is more useful than bandwidth headline figures for most SD-WAN evaluations.
Security sits in its own module (see SASE & Cybersecurity below) and tends to be the most variable by sector, the standard questions cover robust encryption and TLS inspection capabilities without compromising performance, whilst regulated-sector briefs go further into segmentation, audit logging and inspection points.
Compliance questions focus on regulatory logging with appropriate retention periods that satisfy audit requirements, which is one of the questions vendors answer most differently from one another and where you see real differentiation in what they can actually deliver versus what they claim.
Core modules
Company & Service Model
The mandatory opening module. Covers the supplier's workforce composition, financial stability and accountability models, the things that matter for long-term partnership viability rather than just immediate technical fit. We'd note that this section is where you start to see how vendors approach transparency, which is often a reasonable proxy for how they'll behave once a contract is signed.
Network Footprint
Point of Presence locations, backbone architecture and last-mile strategies. The purpose is confirming whether the vendor's reach actually covers your sites, global footprint claims on a datasheet and verified PoP coverage in the specific regions where your sites sit are different things, and this module forces vendors to be specific.
SD-WAN Capabilities
Technical performance, scalability and traffic routing based on real-time application health. This is typically the most heavily weighted module for a standard SD-WAN evaluation and the one where vendor responses diverge most significantly, particularly on how they handle dynamic path selection and how they evidence it rather than just describing the architecture.
SASE & Cybersecurity
Requirements for converging networking and security, covering SSE, ZTNA, cloud-delivered firewalls and deep packet inspection. Whilst SASE and SD-WAN are increasingly sold together, it's worth using this module to establish whether the security stack is native to the platform or a bolt-on, because the answer significantly affects how the two function in practice. Vendors who can't answer the inspection point and logging questions in detail usually can't deliver the integration either.
SLAs & Change Management
Measurable uptime, latency and jitter targets, alongside clear procedures for MACDs. This module is where a lot of RFPs fall short, vendors are good at publishing headline SLA numbers but less forthcoming on what actually happens during Moves, Adds, Changes and Deletes in a live environment. The questions here are designed to surface that.
Custom Questions (AI Powered)
The AI Helper drafts bespoke technical or commercial questions for requirements that sit outside the standard library, legacy hardware constraints, unique compliance needs, or anything specific to your environment that the pre-built questions don't cover. It's the part of the builder we find most useful for organisations with non-standard infrastructure, where generic RFP templates tend to leave gaps.
Implementation & Governance
Detailed migration methodologies and project plans, plus regulatory compliance for your sector. Given this is where SD-WAN rollouts most commonly stall, not in the technical specification phase but in the implementation, it's worth weighting this module more heavily than most RFP templates do by default.
Sector-specific SD-WAN RFP questions
SD-WAN evaluation requirements vary substantially by industry and, given this, an un-tailored RFP will typically fall short of what your business actually needs. To help with this, we've built sector-specific question libraries for the four sectors where we see the most variation, healthcare, retail, manufacturing and financial services. These sit on top of the core question set rather than replacing it.
Retail: POS / Payment Resilience & Rapid Rollout
An SD-WAN RFP for retail should prioritise POS and payment resilience, rapid store rollout capability and cardholder data security controls, the questions that matter here are quite different from the questions that matter for a multi-site office environment. Specifically, the four things we'd recommend retail evaluations focus on are zero-touch provisioning for rapid store deployment (the volume of sites in retail makes manual provisioning impractical), LTE/5G failover with defined switchover times (because a failed payment terminal during peak trading is a direct revenue loss), central policy management that scales across hundreds of sites without proportional management overhead, and clear evidence of PCI DSS segmentation capabilities rather than a general claim of compliance.
Frequently asked questions
What should an SD-WAN RFP include to compare providers fairly?
The short answer is that it needs to request structured, comparable evidence rather than capabilities claims, unstructured means that vendors might answer questions in two incomparable ways, leaving you unable to determine who is the better fit for your needs. We would argue that the key difference between a good RFP and a weak one is almost always whether vendors are forced to answer specific technical questions about your environment and whether you've minimised the risk of them responding with marketing content rather than direct, evidence-based claims. To help avoid this, we'd strongly recommend that you define your environment first, then build questions that require evidence of how vendors would handle your specific sites, circuits and security requirements.
How do I handle pricing comparisons in an RFP?
SASE is the SSE security stack (typically FWaaS, CASB, SWG, ZTNA) with SD-WAN for access capabilities, therefore evaluations for these go hand-in-hand, and so by including security requirement modules that force vendors to provide technical evidence of their combined networking and security capabilities within a single framework, you can evaluate each in one go rather than separating SD-WAN and SASE evaluation. We'd also note that where a vendor's SASE offering is a bolt-on rather than a native integration, it often becomes apparent very quickly when you ask for specific evidence of policy enforcement, inspection points and logging, which can be useful if you're looking for a solution that's built with security in mind from the ground up.