Blog / vendors
The support fine print nobody reads
Response time is not resolution time. What support contracts actually promise, what voids coverage, and who owns your configurations.
Most people read a support contract the way they read software terms: scroll, sign, forget. Then something breaks on a Friday afternoon and they discover what they actually bought.
I have sat on both sides of these agreements, writing them at hosting companies and reviewing them for clients. The problems are almost always in the same four places.
Response time is not resolution time
"Four hour response" sounds like your problem gets fixed in four hours. It does not. It means a human acknowledges your ticket within four hours. The contract may promise nothing at all about when the problem is resolved.
This is not vendors being sneaky, exactly. No honest vendor can promise a fix time for a problem they have not diagnosed yet. But plenty of sales conversations let you believe response and resolution are the same thing, and the gap between them is where your business sits idle.
What to look for: a response commitment and some form of resolution target or escalation path. Even soft language helps ("escalated to senior engineering after four hours") because it gives you something to point at. If the contract only mentions response time, price it accordingly. You are buying an answering service with expertise attached, not a guaranteed fix.
Business hours are wherever the vendor says they are
"Support available during business hours" is doing a lot of quiet work. Whose business hours? Which time zone? Do they include the Friday before a long weekend? Statutory holidays, and in which province or country?
I have seen "24/7 support" that turned out to mean a 24/7 ticket queue, monitored by one overnight person who could only escalate to a team that started at 9 a.m. somewhere in Europe. Technically true. Practically useless at 2 a.m. Toronto time.
Ask the vendor to write down: hours in your time zone, holiday schedule, and specifically what happens outside those hours. "Emergency line" is worth nothing unless the contract defines what qualifies as an emergency and who decides.
The quiet list of things that void coverage
Somewhere in the agreement there is a list of exclusions, and it is worth reading twice, because it usually includes things you were planning to do.
The common ones: any modification by a third party, use of non-approved parts or software, missed maintenance visits, and "environmental factors" broad enough to cover a warm closet. On the IT side, installing your own software on a supported server, or letting another contractor touch the firewall, can flip the whole system to unsupported status.
None of these are automatically unreasonable. A vendor cannot stand behind gear someone else has been inside. But you need to know the tripwires before you trip them, especially if you use more than one vendor. This is a big part of vendor management for people who do not want to think about vendors: making sure vendor A's work does not void vendor B's coverage.
Who owns the configuration?
This is the one almost nobody checks, and it is the one that hurts most when you leave.
Your firewall rules, phone system setup, camera configurations, backup schedules and admin passwords are the accumulated knowledge of your environment. If the contract is silent on ownership, some vendors treat that configuration as theirs: their intellectual property, their documentation, their leverage when you try to switch.
Leaving a vendor and discovering you do not have admin credentials to your own equipment is a miserable experience, and a surprisingly common one. It turns a routine transition into a hostage negotiation.
Before you sign, get it in writing: configurations and documentation belong to you, admin credentials are held by you or escrowed, and on termination the vendor hands over everything within a defined number of days. A vendor who resists this is telling you how the relationship ends.
Ten minutes that changes the deal
You do not need a lawyer for most support contracts. You need ten minutes and four questions. What exactly happens in the first four hours of an outage? Whose clock defines your coverage hours? What actions on my side void the agreement? And when we part ways, what do I walk away with?
Vendors answer these questions every day for careful customers. The fine print mostly stays bad because so few people ask.
If you have a support or warranty agreement in front of you and something about it feels vague, that instinct is usually right. I review contracts like these as a fixed-fee second opinion, and it is a lot cheaper than finding the gaps during an outage.