Predictive vs. measured Wi-Fi surveys
July 5, 2026 · 3 min read · SiteOps Command
“Wi-Fi survey” is two jobs wearing one name. One designs coverage that does not exist yet; the other measures coverage that does. Conflating them is how a proposal ends up quoting a walk-test that was never needed, or a go-live slips because nobody validated the install. Here is the distinction, and why the best workflow uses both.
Predictive: designing before it exists
A predictive survey computes coverage from a model of the building. You anchor a floor plan to real scale, give the walls their real materials, place access points with their real antenna patterns, and let propagation physics produce the heatmap. Nothing is installed; nothing is measured. The output is a design and a prediction — where coverage will land, where it will not, and what to change before anyone mounts hardware.
Predictive is the right tool at the design stage: proposals, budgeting, AP counts, and finding the dead corner while it is still a line on a plan. Its honest limitation is that it is an estimate, grounded in standards and datasheets rather than in your specific building’s surprises — which is exactly why the platform labels it design-stage estimation and never publishes an accuracy-versus-measured number it has not measured. The coverage physics behind it names every standard on the figure.
Measured: validating what is installed
A measured survey reads the real radio environment with a real instrument — an adapter, a spectrum analyzer, an AP on a stick. It captures RSSI, signal-to-noise, interference, and roaming behavior as they actually are, on the building as it actually is, with the furniture, the people, and the neighboring networks all present.
Measured is the right tool at acceptance and troubleshooting: proving an install meets spec, chasing a complaint, or characterizing a site whose materials you cannot trust from a drawing. Its cost is that it requires the building to exist and someone to walk it — which is precisely the cost predictive design exists to defer.
Where each one belongs
| Question | Survey type |
|---|---|
| How many APs, and where? | Predictive |
| Will this proposal's coverage hold up? | Predictive |
| Did the install actually meet spec? | Measured |
| Why is this corner dropping? | Measured |
| What does this odd building really do to a signal? | Measured, then feed it back |
Most projects need both, in that order: design predictively, then measure where it matters.
The bridge: calibration
The two stop being separate tools the moment the measured readings flow back into the model. Field calibration feeds real readings from the building into the same engine that produced the prediction, and the model correlates the two — so the design and the field converge on one source of truth instead of drifting apart in two applications. You design once, measure where it counts, and keep a single model that gets more accurate as the building teaches it.
That is the whole argument for doing both on one platform: the predictive heatmap that wins the proposal and the measured readings that prove the install are describing the same building, not arguing about it.
There is a step-by-step guide to running a virtual site survey, a look at producing a predictive heatmap without a survey subscription, and the physics that makes a heatmap honest. For teams doing this across many sites, here is how MSPs use it.