What to include
in a maintenance contract

Response time is how long it takes for a person to pick up the call: read it, classify it and tell you what is going on. Resolution time is how long it takes for the problem to be properly fixed, and it depends on factors the provider doesn't fully control: whether a part is needed, whether a manufacturer has to step in, whether the telecoms operator is slow. A serious contract commits to the first with a number and treats the second as an ongoing commitment, not a fixed promise. The warning sign isn't that the contract sets no resolution deadline: it is that it sets the same one for a jammed printer as for a server that has gone down, without distinguishing severity. Before signing, ask what happens if the response deadline is met but nobody is then assigned to the ticket: that gap in between is where more hours are lost than in the fault itself, and almost no contract mentions it.

Typically the fee excludes new hardware, software licences, cabling and building work, migration projects, and incidents caused by someone the client allowed to tamper with the systems without authorisation. None of this is unfair in itself: the problem arises when those exclusions aren't written down and are only discovered, billed separately, once they have already happened. Watch out too for vaguely defined extra work, a catch-all that can hold almost any job the provider doesn't find worth including in the fee. Ask for that extra work to have a specific definition, not a generic sentence, and for it to be clear whether it is quoted before it is done or billed afterwards without warning. A contract that lists what it doesn't cover as carefully as what it does is much harder to argue about on the day an unexpected invoice arrives.

It depends on how many real incidents you have a month and what it costs you when a system is down, not on what looks cheaper on paper. A fixed fee buys predictable spending and priority attention: you know what you pay each month, and the provider knows your setup because they check it even when you don't call. Paying for one-off hours can work out cheaper if you hardly ever have incidents, but it comes with no committed deadline and nobody who starts out already knowing where everything is, because each visit begins almost from scratch. A prepaid block of hours is the middle ground: you buy time in advance at a better rate than single hours, but check whether the hours expire at the end of the period or roll over, because that small print changes the whole calculation. No option is better in the abstract: the right one is the one that matches what downtime costs your business.

It depends on the contract, and it is the clause most worth reading slowly. Many include checking that the backup runs every night and alerting you if it fails, but not taking responsibility for that backup actually restoring something on the day you need it. Those are different commitments: one is monitoring, the other is a recovery guarantee, and they cost different amounts. Ask explicitly who runs the restore test, how often and what is documented about it, because a backup that has never been restored is an assumption, not a backup. Ask too where that backup lives: if there is only one destination and it sits on the same network as the original, a single incident can take out both at once. If the contract mentions neither the restore test nor the destination, don't assume they are covered: it is exactly the kind of thing that is taken for granted until it fails at the worst possible moment.

It is reasonable for the maintainer not to be responsible when a fault is caused by someone else: the operator that cuts the line, the bank that changes a certificate, the manufacturer that releases a faulty update. What is worth putting in writing is who handles that contact and within what timeframe. A good contract specifies whether the provider raises the issue with the third party on your behalf, whether they keep you informed of progress, and whether there is a time limit for that work within the fee or it is billed separately beyond a certain point. Without that clause, the work usually falls to whoever has most patience that day, normally someone on your staff who shouldn't be spending hours on the phone to an operator. Ask too whether the provider keeps a written record of those dealings, because that history is what saves you repeating the same explanation every time the person on the other end changes.

The ones listed in the inventory attached to the contract, which is why that annex has to be a specific list with make, model and function, not a rough number of workstations. When you buy a new device or retire one, the contract should normally set out how the list is updated and whether the fee changes proportionally or has to wait for the annual review. Without that mechanism, every addition becomes an awkward negotiation call, and every removal keeps generating an invoice for something that no longer exists. It is also worth setting out what happens to devices that aren't permanently in the office, such as laptops belonging to remote workers or personal devices that access company systems, because they are left out of the inventory far too often without anyone noticing until they fail and nobody knows whether they were covered.

Yes, whenever the provider has access to personal data, and in IT that happens in practically every case, because whoever maintains the systems can see customer files, payroll or company email. That agreement is separate from the service contract and must exist in writing, with documented instructions on what the provider may do with the data, a confidentiality commitment from the staff who access it, and a statement of whether they in turn subcontract to another provider, such as a data centre or a cloud backup service. If whoever maintains your systems doesn't offer it on their own initiative, ask: a provider that routinely handles personal data already has the template ready, and if they don't produce it, that only tells you nobody has asked before. It is a ten-minute signature that stops responsibility for that processing falling entirely on your business.

It has to be written into the contract from the start, not negotiated on the day you decide to leave, because by then you have no leverage at all. The minimum: administrator passwords for every system, up-to-date documentation of the setup, access to existing backups and ownership of the licences you paid for, even if they are managed from the provider's account. It is also worth adding a handover period, during which the outgoing provider remains available to answer the incoming one's questions, because knowledge of a setup never fits entirely into a document. Before signing any new contract, check who the domain, the email and the hosting control panel are registered to today: if they are already in the current provider's name, start recovering them now rather than waiting for the switch, because negotiating it in a hurry and with no room to manoeuvre turns out far worse for you.