Not the SLA-page kind of expectations, but the ones that actually show up under pressure.
Every managed IT contract has a page that reads almost the same no matter who wrote it: response time in minutes, uptime percentage, ticket resolution targets. If you’ve read proposals from three different providers, you’ve read that paragraph three times with the logo swapped out.
None of those numbers answer the question that actually matters: will this company see a problem before it reaches you, tell you the truth about what’s going on, and show up when it counts? Those are the things that separate a partner from a vendor, and none of them appear on the SLA page.
If you’re running a business with 50 to 100 people, this isn’t a hypothetical. You don’t have a CIO. You likely don’t have anyone whose full-time job is watching the IT environment the way a 500-person company can afford to. Whoever handles that for you (internal hire or outside firm) is your eyes on a part of the business you can’t watch yourself. If they’re only reactive, you find out about problems the same way your customers or your staff do: after they’ve already happened.
Why the standard scorecard misses the point
Most IT contracts are written to be easy to audit, not to describe what good actually looks like. Response time and uptime are simple to measure, so they became the default way providers prove value and the default way CEOs judge them. The result is a scorecard that rewards fast reactions to problems, and says nothing about whether those problems should have been caught earlier, whether they were explained to you honestly, or whether the fix addressed the cause or just the symptom.
This matters more at 50 to 100 employees than it does at 500. A larger company can absorb a provider who only shows up when summoned; they have layers of internal staff filling the gaps. A smaller one usually can’t. When your entire IT function sits with one contract, that contract is either doing the job of a strategic partner or it isn’t, and the SLA page won’t tell you which.
The frustration we hear most from owners in this range isn’t that their provider is incompetent. It’s that the relationship is opaque: technical explanations that don’t map to a business decision, costs that appear without warning, and a sense that the relationship only activates once something is already broken.
What actually separates a partner from a vendor
The difference rarely shows up in a sales pitch. It shows up in three specific moments, and each one is worth testing for directly.
Visibility: do they tell you what’s about to happen, or only what already did?
A reactive provider fixes what breaks. A partner tells you what’s likely to break before it does, because they’re actually watching, not just waiting for a ticket.
We saw this play out with a non-profit client delivering essential services across BC. Their servers were aging, but nothing had failed yet, the kind of problem that’s easy to defer indefinitely because there’s no fire to put out. Because we had ongoing visibility into their asset and performance data, we flagged the risk and upgraded the hardware before it caused an outage, not after. The organization never had a service interruption to explain to the people relying on them.
The test for your own provider is simple: what have they flagged for you in the last quarter that you didn’t ask about? If the honest answer is nothing, they’re maintaining your environment, not watching it.
Accountability: does the reporting connect to risk, or just to activity?
“218 tickets closed, 99.9% uptime” tells you a provider was busy. It doesn’t tell you whether the business is more or less exposed than it was last quarter, and it definitely doesn’t tell you who could reach your financial records if they wanted to.
We took on a private company with just over 50 users whose SharePoint environment had grown the way most of these environments do: organically, over years, with permissions granted one request at a time and never revisited. Nobody had done anything wrong. But by the time we looked at it, IT had no real visibility into who could access what, and the business was carrying compliance risk and paying for redundant storage without knowing it. We rebuilt the structure — critical folders got specific permissions, one-off access grants were replaced with security groups, and the data was migrated in a way that removed the redundancy instead of adding to it.
None of that shows up as a ticket. It shows up as a quarter where the business is measurably less exposed than it was — and that’s the report a CEO should actually be getting, not a tally of hours worked.
Reliability: what happens in the moment that actually counts?
Every provider says they’re responsive. Most of them mean it, right up until the moment it’s tested. Reliability isn’t the average response time written into the contract: it’s what happens on the one day a year when things genuinely go sideways.
We ran the technology behind a high-stakes public referendum: devices configured and deployed across multiple voting locations, secure connectivity at every site, and a team in place for real-time support on the day itself. There was no room for “we”ll look into it Monday.” The result was zero disruptions during the event, not because nothing went wrong anywhere, but because the team was positioned to handle it in real time.
Most businesses will never run an election. But everyone has their version of that day: the ransomware attempt at 6pm on a Friday, the server failure during month-end close, or the outage during your busiest week of the year. The SLA tells you what response time was promised. It won’t tell you whether the team actually shows up like it’s their problem too.
How to actually evaluate this
You can test for all three before you sign anything, or before you decide whether to keep what you already have.
Ask what your provider has proactively flagged for you recently, without being asked. Ask to see a report that isn’t a ticket count: something that shows risk trending in a direction, not just activity logged. And ask what actually happened the last time a client had a genuine after-hours emergency, in specific terms, not “we guarantee 15-minute response.”
A provider doing this well usually has a structure behind it: a centralized view of your environment instead of a spreadsheet nobody updates, and a regular cadence (a quarterly business review, not an annual check-in) where someone walks you through what changed and what’s coming next. That structure is what turns IT support into something closer to a virtual CIO for a business that can’t justify hiring one full-time.
None of this requires a bigger budget than you’re already spending. It requires a provider whose contract was built around those three questions instead of around whatever was easiest to measure.
Not sure whether your current setup can answer these questions?
Tecnet works with growing BC businesses to bring visibility, accountability, and real reliability to IT environments that have outgrown ad hoc support, without the overhead of a full internal team.