01
Problems are detected only when users report them
Define which events and metrics are available, who receives them, and when a support request is registered.
Agreed procedures for WLAN operation
Technical support and maintenance of Wi‑Fi networks
Before support begins, we document the network inventory, versions, access permissions, critical services, and areas of responsibility. We then agree on request channels, priorities, service windows, work types, exclusions, and reporting. The contract alone defines the service arrangements and SLA targets.
Network baseline → request → classification → response → restoration → resolution → report
What does Wi‑Fi network support include?
Wi‑Fi network support is an agreed process for receiving and classifying support requests, diagnostics, communication, and changes. Depending on the contract, it may also include preventive work, monitoring, site visits, and reporting. Before support starts, the parties document the supported sites, equipment and versions, access permissions, dependencies, and responsibilities. The contract defines service windows and response targets.
When a support model is needed
02
Incidents recur
A history of actions, root-cause findings to the extent supported by available data, and tracking of agreed preventive measures are needed.
03
Configurations change without records
You need an up-to-date source version, a changelog, backups, and an agreed rollback.
04
The internal team needs WLAN expertise
First define first- and second-line roles, access permissions, supported platforms, and responsibility for the RF, LAN, client device, and application layers.
What is required to take a network into support
| Required | Useful to have | We will clarify this together |
|---|---|---|
| List of sites, equipment and versions | Current diagrams, configurations, and change history | Supported platforms and version limitations are checked before the contract |
| Critical services and contacts responsible for dependencies | Data on typical requests and known problems | Service windows, priorities and communication channels |
| Access permissions or the procedure for granting them | Licenses, vendor contracts and equipment stock | Conditions of remote and field work are agreed separately |
| Information security requirements and change procedures | Current reporting and operating regulations | Available metrics and ability to connect monitoring are checked before the contract |
How work is classified
| Type | What is this | What we document |
|---|---|---|
| Incident | Unplanned deterioration or failure of the agreed service | Impact, priority, communication, recovery and further action |
| Service request | A standard action from an agreed service catalog | Scope, timeline, approval, and result |
| Change | Controlled configuration or infrastructure modification | Risk, window, test, backup and rollback |
| Project work | Expansion, migration or new architecture | Separate scope, design, cost, and acceptance criteria |
How the network is accepted for maintenance
- 01
Check the composition and status of the network
Check sites, equipment, versions, documentation, accesses, licenses and known restrictions.
- 02
Document the network baseline
Create agreed network baseline documentation, a configuration register, and a list of open risks.
- 03
We agree on SLA and areas of responsibility
Define responsibilities for the WLAN, LAN, server services, client devices, applications, and external contractors.
- 04
We set up service channels
Define request handling, escalation, communication, changes, and available monitoring tools where included in the service model.
- 05
We implement agreed operating procedures
Where reporting is included, agree on its contents and frequency. Identify action owners and the procedure for updating network baseline documentation.
What the customer receives
- 01Network baseline documentation and a list of exclusions;
- 02A matrix of priorities, channels, escalation and areas of responsibility;
- 03Catalog of included requests and changes;
- 04Agreed backup and rollback procedure;
- 05History of requests and changes, if the service model provides an appropriate tool;
- 06Regular report, if its periodicity and composition are included in the service model;
- 07List of risks and recommended individual projects.
What is included and what requires a separate agreement
| Included only when specified in the service model | Agree separately | This is not an ordinary incident. |
|---|---|---|
| Receiving and classifying requests, diagnostics, communication, and reporting | Monitoring, site visits, spare equipment, and special service windows, only where included in the contract | Expansion of coverage and new architecture |
| Standard requests and changes from the approved service catalog | In-depth analysis of causes, field measurements and vendor participation – by separate agreement | Platform migration and implementation of a new project |
| Maintaining the agreed operational documentation | Work with unsupported versions and equipment outside the life cycle | Repairing systems outside agreed access permissions or contractual responsibilities |
What the SLA should define
| Field of SLA | What needs to be determined |
|---|---|
| Service window | Days, hours, time zone, channels and exceptions |
| Priority | Impact on agreed service, scale and acceptable confirmation methods |
| Registration | The moment when the request is accepted in the agreed channel |
| Response | When work and communication begin; this is not a promise of resolution |
| Service restoration | Restoring the agreed service, using a temporary workaround where permitted |
| Resolution | Eliminating the cause or closing the request on another agreed basis |
| Escalation | Responsible contacts at Connectum, the customer, the vendor, and other contractors |
| Site visits and spare equipment | Geography, conditions, availability and exclusions, if these options are included in the contract |
| External dependencies | LAN, power supply, connectivity, licenses, applications, and access permissions outside our control |
How the quality of support is assessed
| Criterion | How to check | Where we document |
|---|---|---|
| Registration and priority | Check the channel, time and basis of classification | Support ticket |
| Response and communication | Compare events with an approved SLA matrix | Request handling timeline |
| Service restoration and resolution | We distinguish temporary recovery from final resolution | Support ticket and report |
| Change | Check approval, backup, result and rollback | Change log |
| Preventive action | Check the owner, the term and the observed effect | Action Plan and next report |
What determines onboarding time and cost
The estimate depends on sites and devices, platforms and versions, service windows, priorities, access permissions, location, integrations, monitoring scope, site visits, spare equipment, the change catalog, and reporting. Monitoring, visits, and spare equipment are included in the estimate only where specified in the agreed service model. Cost and response targets are determined after reviewing the network inventory and agreeing on that model.
01
Service model
One team supports the agreed Wi‑Fi environment through monitoring, request handling, changes, and service restoration under documented procedures and the SLA.
Questions and answers
Frequently Asked Questions About Wi‑Fi Support
01Is round-the-clock support available?
Round-the-clock service is not a standard commitment. Its availability is confirmed for a specific service model, taking account of geography, access arrangements, communication channels and operational resources, and is then stated separately in the approved proposal and contract. The SLA must define the service window, priorities, response, recovery, exclusions and external dependencies, without applying universal values to every network.
02Do you support networks from any manufacturer?
Support is not available universally for every platform and version. Before onboarding, we review equipment, software versions, licenses, lifecycle status, documentation, diagnostic data, and the expertise required. The contract records the supported inventory and limitations. Some systems may require vendor involvement, software updates, restored documentation, or a separate modernization project.
03Is there constant monitoring?
Continuous monitoring is included only when expressly stated in the service model and after confirming platform capabilities, licenses, access permissions, metrics, notification rules, and responsibility for responding. Having a controller does not itself provide visibility into the client experience or early detection of every fault. Without agreed monitoring, work begins with registered support requests and available diagnostic data.
04Is it possible to visit the site?
Site visits are not automatically included in support. Their availability and terms are determined for each site, considering geography, service windows, the reason for the request, access, safety requirements, costs and specialist availability. If remote data is insufficient, the purpose of the visit, required participants, work plan and expected on-site outcome are defined first.
05Does support include network expansion?
Standard changes are included only through a preapproved service catalog with clear limits and verification procedures. A new area, additional access points, architecture changes, platform migration, or a new integration usually require separate design and acceptance. The boundary between support and project work depends on risk, scope, required documentation, and impact on the live service.
06How does response time differ from service restoration and resolution?
Response means starting work and communication after a support request is registered. Recovery means restoring the agreed service, including an acceptable temporary workaround. Resolution means eliminating the cause or reaching another agreed basis for closing the request. These measures must remain distinct: each has its own starting point, recording method, exclusions, external dependencies and data source for SLA verification.
The next step
We will select a support model
Send a list of sites, equipment and versions, a diagram, critical services, current request channels, and the desired service window. We will review the inputs and prepare questions to define the service model.
Material prepared by Connectum technical team · updated: August 2026