Acceptance is the moment risk transfers. Before it, the supplier carries the problem. After it, you do. Everything about how the criteria are written determines whether that transfer happens on terms you would have chosen.
Most acceptance documents are written by people optimising for a signature rather than for a working network, and it shows in four recurring ways.
Failure one: component criteria instead of service criteria
A test plan that checks each element against its own specification will pass even when the network does not work, because every vendor’s box is behaving exactly as documented. The failure lives between them.
Acceptance criteria should be expressed as service outcomes: accessibility, retainability, throughput at defined percentiles, latency, call setup time, handover success, and service continuity at coverage boundaries. Component compliance is the integrator’s internal concern.
Failure two: testing under conditions that never occur
Empty networks pass everything. Criteria have to be met under representative load, at busy hour, with the device mix actually in the field, at cell edge, and during mobility — not on an unloaded cell with an engineering handset at the tower base.
Where load cannot be generated naturally, specify how it will be simulated and agree that method before testing starts, not while disputing a result.
Failure three: no defined remedy
A criterion without a consequence is a statement of hope. Each one needs to say what happens when it is missed: a defined rectification window, a retest at the supplier’s cost, a withheld payment milestone, or a liquidated amount. This is usually where acceptance documents get soft, and it is the only clause that gives them force.
Failure four: conditional acceptance with open items
The most common way an operator loses is to accept a network with a list of outstanding items attached, on the understanding that they will be closed shortly. Once acceptance is signed, the commercial urgency to close them disappears along with the leverage. Open items should either block acceptance or be re-priced into a separate, separately-enforced commitment.
What to include
- End-to-end KPIs with target values, measurement method, measurement period and the tool of record named.
- Load and device conditions defined in advance, including the handset or CPE mix.
- Coverage and mobility tests at boundaries and during handover, including inter-technology handover where relevant.
- Voice-specific criteria where voice is in scope — call setup time, codec negotiation, fallback behaviour, emergency calling.
- Synchronisation verification for TDD networks, including holdover behaviour.
- Management and counter harmonisation proven across vendors, not assumed.
- Documentation and as-built records delivered as a condition, not a follow-up.
- A defined remedy against every criterion.
- A stability period after acceptance during which the supplier remains on the hook for regressions.
The underlying point
An acceptance campaign is not an administrative closure task. It is the contractual expression of what you bought. If it is written against components, tested in conditions that do not occur, and signed with open items and no remedies, then what you bought is equipment — and the network is now your integration project, at your cost.