In over 20 years in managed IT, I've seen the same pattern play out dozens of times. A business owner signs an IT services agreement. The relationship is fine for a while, or maybe it's never really fine — the response times are soft, the bills have surprise line items, the tech turnover is constant. At some point they decide to leave. And that's when they read the contract for the first time.

That's not cynicism. It's what actually happens. Most business owners evaluate IT providers the way they evaluate any vendor: they look at price, they ask for references, they listen to the pitch. What they don't do — almost ever — is sit down with the agreement before signing and read it like it's going to be used against them. Because someday it will be.

I'm not writing this to steer anyone toward a specific provider. I'm writing it because the IT contract red flags that bite people are consistently the same ones, and they're easy to spot if you know where to look.

The Clauses That Always Bite People

Auto-renewal windows. Most IT agreements are annual contracts with a 30- to 90-day auto-renewal window. That sounds simple enough. What it means in practice: if you decide you want to leave in November and your renewal window closed in September, you're locked in for another year. The window is almost never written in plain English. It's buried in a definitions section or attached as an exhibit. Read it, put the date in your calendar, and set a reminder 30 days before the window opens.

Termination fees. Some contracts have them, some don't. The ones that do often tie the fee to "remaining contract value" — meaning if you leave eight months into a 12-month deal, you owe four months of fees. That's not always unreasonable; providers do invest in onboarding. But the number matters. A termination fee of one month's cost is manageable. A fee equal to the full remaining contract value is a trap. Know the number before you sign.

Scope creep charges. This one is more subtle. I've written about out-of-scope billing before because it's one of the most common ways IT contracts are used against clients. The agreement lists what's covered — workstations, servers, network devices, Microsoft 365 — and everything else becomes a billable project. New employee onboarding: project. Moving an office: project. Adding a printer that requires driver configuration: sometimes a project. These aren't always bad-faith charges. But the scope should be written specifically enough that you know, in advance, what will and won't generate a separate invoice.

"Reasonable efforts" and "best efforts" language. This one is pure legal fog. When a contract says the provider will use "reasonable efforts" to resolve a critical issue within four hours, that phrase does almost no work. "Reasonable efforts" has no binding definition. In a dispute, the provider's lawyer will argue that they made reasonable efforts even if the issue sat open for 12 hours. If you want a service level commitment to mean anything, it needs a specific number — resolution time, response time, or both — and it needs a consequence for missing it.

Questions to Ask Before You Sign

I tell every business owner the same three questions. If you can't get clear, specific answers to all three, that's a sign.

What is your response time SLA, and what happens if you miss it? The response time question is common. The second half — what happens if you miss it — is where most providers stumble. A provider with real service level commitments can answer this immediately: we credit you X hours of service, or we waive that month's management fee, or we escalate to a senior engineer automatically after Y minutes. If the answer is "we take it seriously and work hard to meet our commitments," that's not an SLA. That's a feeling.

What's included versus billed separately? Ask for a written list. Not a verbal summary during the sales call — a written exhibit that lives inside the contract. Vendors are often willing to clarify scope verbally; getting it in writing is where you learn whether the clarification is real. Response time problems and billing surprises often come from the same source: a provider who hasn't clearly defined what they're actually responsible for.

What does offboarding look like if we leave? This question makes some providers visibly uncomfortable. That's information. A good provider has a documented offboarding process: they'll export your documentation, transfer your licenses, hand off your credentials, and give you 30 days of transition support. A provider who hedges on this question — "we'd work with you on that," "it depends on the situation" — is telling you that offboarding will be whatever they decide it will be when you get there. I've written about the vendor lock-in playbook in detail, and the offboarding conversation is one of the clearest tells.

Red Flags That Show Up in Sales Conversations

The IT contract red flags don't always wait for the contract. Some of them show up in the sales process, before any paperwork exists.

Vague pricing. "It depends on your environment" is sometimes a legitimate answer — truly complex environments do require scoping. But if the salesperson can't give you a per-user range within 15 minutes of asking, that's a pricing model designed to be flexible in their direction, not yours. You should be able to get a ballpark number in the first conversation.

"We can customize that later." This phrase is a way of deferring every hard question to after you've signed. If your specific requirements — particular software, unusual hours, industry compliance needs — can be addressed, a competent provider can address them now. "We'll work that out once we're engaged" usually means the details won't favor you, and you'll have less leverage to negotiate them after the contract is signed.

Resistance to putting SLAs in writing. I've heard every version of this. "Our team is committed to fast response." "We pride ourselves on being accessible." "Our clients never wait long." All fine things to say. None of them are service level agreements. A provider who won't commit to specific numbers in writing either doesn't have confidence in their own performance or is selling you something they know they can't consistently deliver. Either way, you're the one absorbing the risk.

The pattern to watch for: Vague pricing + deferred specifics + resistance to written commitments = a contract that works against you. Any one of these can be explained away. All three together is a model designed around provider flexibility at client expense.

The One Thing Almost Nobody Does

Read the termination clause before you sign. Not when you want to leave — before you sign.

I can't overstate how often this doesn't happen. Business owners negotiate price, ask about response times, call a reference or two. They read the summary. They do not go directly to the termination section and read every word of it before signing anything.

The termination clause is where a contract's true power dynamic lives. It tells you how much notice you have to give, what fees apply, what the provider's obligations are to you during the transition, and whether there are any conditions under which you can exit without penalty. In a fair agreement, termination is straightforward: give 30 or 60 days notice, pay through that period, get your documentation and credentials. In an unfair agreement, the termination clause is how a provider keeps you paying for a relationship that isn't working.

I've talked to business owners who were stuck in IT agreements they hated for 14 months because they didn't understand the auto-renewal window. I've talked to owners who paid out three months of fees to exit a six-month-old contract because the termination clause had no carve-outs for poor performance. These aren't obscure situations. They're what happens when you treat the contract as a formality.

The termination clause isn't pessimistic. It's the most honest part of the agreement. It tells you what the relationship looks like when it isn't working — which is exactly what you need to know before you decide whether to begin it.

What a Good Contract Looks Like

For contrast: a well-written IT services agreement is not complicated. The scope of services is specific enough that you can tell at a glance whether a new request is covered or not. SLAs have real numbers — response time in minutes or hours, resolution time by priority level — and there's a defined remedy when they're missed. Termination requires reasonable notice, has a clear transition obligation from the provider, and doesn't impose penalties beyond the notice period. Pricing is fixed for the contract term, with a written process for mid-term changes.

That's not a high bar. But plenty of contracts don't clear it.

If the contract you're looking at doesn't have specific SLA numbers, ask for them in a written addendum before you sign. If the scope is defined at a category level rather than a service level, ask for a scope exhibit. If the termination clause is longer than two paragraphs and full of conditions, have a lawyer read it. These aren't unreasonable requests. A provider who pushes back hard on any of them is telling you something important about how they plan to use the contract once you're in it.

The IT industry runs on information asymmetry — providers know more about what the contract means than clients do, and that asymmetry is often deliberate. The best way to close the gap is to read the document with the same skepticism you'd bring to any agreement where the other party wrote all the terms. Because that's exactly what an IT contract is.