A network support contract works well when it is clear before signing what will be done, how fast and how far. Most disputes start right here: the organisation thought something was included and the contractor did not. This checklist comes from network support and maintenance work for organisations such as Energy Gostaran Mottahed, whose network I supported for three years after building it.
1. Record the current setup together
Before giving a price, the contractor should see the network. One site visit and a simple list are enough:
- Network equipment: router, firewall, switches and access points
- Servers, virtual machines and critical services
- Phone system, branches and how they are connected
- Documentation: where are the network map, the addressing plan and the passwords?
If the network is not documented, it is normal for the first period of the contract to go into tidying and documenting it. Write this down separately and clearly in the contract.
2. Write the scope precisely
Keep three lists:
- In the contract: for example, handling faults in network equipment and servers, configuration changes, checking backups and monitoring critical devices.
- Outside the contract: for example, buying equipment, new cabling or a new building project.
- By separate agreement: work that comes up now and then, with the rate or process agreed in advance.
A vague line such as “full network support” causes the most disputes later.
3. Response time and how problems are reported
- How is a problem reported: phone, messaging app or a ticket system?
- What is the response time during and outside working hours?
- “Response” means starting work on the problem, not solving it; make this difference clear in the contract.
A promise that cannot be kept in practice, such as immediate on-site presence at any hour from a one-person contractor, only destroys trust.
4. On-site or remote?
- How many on-site visits a month, and for which branches and cities?
- How is remote access set up? Only through a VPN with a separate account for the contractor, never an open port on the internet.
- Are the contractor’s sign-ins logged?
5. Monitoring and reporting
Ask how the contractor finds out about a problem: from your call, or from a monitoring system that alerts them first. Ask for a short periodic report too: what happened, what was changed and which risks are coming.
6. Who is responsible for backups?
State who backs up the servers and device configurations, where the copies are kept and how often a restore is tested. The article How to make sure a server backup can really be restored covers exactly this.
7. Passwords and documentation belong to the organisation
The contract should say that admin passwords, configurations and the network map belong to the organisation, and that the manager always has an up-to-date copy. A network whose passwords only one person knows is held hostage by that person.
8. Cost and what is charged separately
The cost depends on the size of the infrastructure, the number of branches, on-site visits and the response time. To compare offers, put the scopes side by side, not just the final figures. Ask what is charged separately and how.
9. Ending the contract
Write down from the start how the contract ends: handing over passwords, up-to-date documentation and configurations, and a handover meeting with the next contractor or in-house expert. This clause protects both sides.
10. Track record
Look at similar projects in size and industry, and if possible talk to one of the contractor’s current clients.
Summary
Before signing, settle these ten points: current setup, scope, response time, on-site and remote access, monitoring, backups, password ownership, cost, ending the contract and track record. If you would like your support contract reviewed with this framework, see network support and IT maintenance contracts or send a request.
Photo: Kim Scarborough, licensed under CC BY-SA 2.0, via Wikimedia Commons; cropped.
