“The Wi-Fi works” is an excellent sentence until somebody has to sign beneath it. Works where? For which device? Doing what? Under which conditions? A handover without those answers leaves the buyer and installer negotiating the meaning of success after the ladders have gone home.
An acceptance plan turns that conversation into a testable agreement. It is not a demand for a flawless radio environment or a promise that every application problem belongs to the WLAN. It defines the evidence needed to accept the delivered wireless scope, and the process for handling what remains unresolved.
Start with the work, not a borrowed threshold
Write down the business workflows first: a stationary workstation transferring files, a handheld completing a transaction, or a mobile voice device moving along an agreed route. Identify the representative device model, operating system and relevant application. “Any laptop we find on Tuesday” is convenient procurement language, but poor test control.
Cisco’s survey guidance distinguishes passive RF observation from active testing with an associated client. A passive survey can characterize received coverage; it does not itself establish uplink or application performance. Its guidance also ties requirements to the actual clients and applications. That is why a borrowed signal target should not become a universal acceptance contract. Read Cisco’s survey guidance.
Agree the numeric criteria with the responsible technical and application owners before testing. State where they apply, how they will be measured and which requirements are advisory rather than acceptance gates. A target with no method attached is an argument waiting for a spreadsheet.
Use a small acceptance matrix
For each requirement, capture these fields in one controlled document:
- Scope: named area, floor-plan revision, workflow and explicit exclusions.
- Test subject: representative client, software version and network identity, recorded without exposing credentials.
- Method: passive RF observation, active client test, application transaction or movement test.
- Conditions: route or locations, timing, occupancy/load assumptions and relevant configuration revision.
- Criterion: the agreed measurable result and treatment of intermittent failures.
- Evidence: report section, test output or protected raw-data reference.
- Disposition: pass, fail, not tested or approved exception; responsible owner and retest trigger.
Do not turn “not tested” into “passed” because the summary needs a pleasing color palette. If a room was inaccessible or a device unavailable, preserve the gap and agree its resolution.
Keep three questions separate
Was the installation delivered as agreed? Reconcile AP locations, mounting orientation and recorded configuration against the approved design and authorized changes. Capture material deviations so later measurements can be interpreted against the installation that actually exists.
Does the RF evidence meet the agreed criteria? Document the measurement method, survey coverage and exceptions. Preserve the underlying files where the scope and data-handling agreement permit, rather than delivering only a screenshot that nobody can interrogate later.
Can representative clients complete the agreed work? That is a different test. An association indicator does not demonstrate a completed business transaction. Define whether authentication, address assignment, application access and movement continuity belong in this engagement; assign anything outside it to an identified owner.
Make performance tests reproducible
Cisco’s throughput guide explains why the displayed PHY rate is not application throughput and why concurrent use changes the conditions. A quiet-building speed test is therefore a baseline under recorded conditions, not proof of busy-hour experience. Record the test endpoint and whether the path includes the internet, so an external bottleneck is not silently labeled a radio defect. Read Cisco’s throughput guidance.
For your acceptance plan, specify test duration, repetitions and the result to report before collecting results. Keep the unflattering samples. If changing the endpoint or client changes the outcome, document that comparison instead of averaging incompatible tests into one reassuring number.
Movement testing needs equally specific language. Meraki notes that roaming decisions are made by the client and may depend on proprietary driver thresholds. Testing one client does not establish identical behavior for the entire device estate. Read Meraki’s roaming explanation. Agree representative devices, routes, applications and the observable interruption criterion rather than promising that an AP setting will make every client behave alike.
Close exceptions without erasing them
Separate an observed failure from its suspected cause. Give each exception an owner, next action and retest condition. Record whether the buyer accepts a defined limitation, requires correction or defers a specific test. Acceptance should not quietly expand into an unlimited troubleshooting engagement, and a scope exclusion should not masquerade as a successful test.
Retest affected requirements after corrective changes. Keep the previous result and configuration reference so the handover shows what changed. Where testing could disrupt production, agree the maintenance window, test permissions and rollback ownership beforehand. Do not run aggressive load tests merely because a tool has an impressive button.
Buy the evidence with the installation
Ask for the acceptance plan while the statement of work is still editable. Define who witnesses results, who accepts exceptions and which deliverables the operating team receives. The best time to discover that active application testing was excluded is before the purchase order, not during the final walkthrough.
Leet Solutions can help review wireless design assumptions and an agreed validation scope. Discuss an independent review or validation engagement; active application and roaming tests require separately agreed scope. See wireless consulting services and the independent design QA/QC guide for the upstream review. A tidy handover is useful. A defensible one is better.
Primary sources and review date
- Cisco: Site Survey Guidelines for WLAN Deployment
- Cisco: Wi-Fi Throughput Testing and Monitoring Guide
- Cisco Meraki: Client roaming and connectivity decisions explained
Technical sources checked November 3, 2026. This is a buyer planning framework, not a universal performance specification. Recheck source guidance and project requirements before using it in a new acceptance plan.