Skip to content

Blog

Practical Guides

Hidden Fees in an IT Quote

A lower number on a proposal isn't the same thing as a lower total cost. Here's how that gap usually shows up, and what to check for before signing anything.

Dawn SizerDawn Sizer · CEO and Co-Founder, 3rd Element Consulting

Composite scenario

This is a composite scenario built from a pattern seen across the industry, not an account of a specific real business or provider. Details have been combined and altered so no company is identifiable.

A business had been with the same IT provider for years. Support was fine, not exceptional, just fine. Then a competing provider came in with a pitch: a scan of the current environment, a long list of findings, and a number that undercut the existing contract.

The scan looked alarming. Pages of flagged items, color-coded, urgent-sounding. The business didn't have the technical background to know whether what they were looking at was a genuinely serious set of gaps or a report built to look that way. That distinction matters and it's a hard one to make from the outside. A real assessment can look concerning even when it's accurate. A report built mainly to win a deal can also look concerning, using default severity settings that flag anything unfamiliar as high risk regardless of actual exposure. Both versions exist in the industry, and from a single scorecard, they're nearly impossible to tell apart. This one did its job either way. Combined with the lower number, it was enough. They switched.

What the lower number didn't include

The new agreement was labeled unlimited support. Within the first year, that word started doing a lot of quiet work.

Part of it was how "included" was actually measured. A meaningful share of the ticket volume backing that unlimited number wasn't coming from employees at all, it was generated by the provider's own systems: automated patch jobs, monitoring alerts that opened and closed themselves, routine maintenance tasks logged as tickets. On paper, the account looked well within its allotment. In practice, when a real employee had a real problem, that ticket increasingly fell into a separate, less generously covered category: a new setup, a vendor integration issue, anything that took real judgment rather than a scripted response.

The other part was who was actually answering the phone. Day-to-day, first-contact support had been routed to an outsourced help desk, a third-party team handling tier-one tickets for multiple clients at once. Response times still looked fine on a report, SLAs technically met. But a language barrier and a shallower bench meant simple issues got resolved fast, and anything that required real context about the business, how their systems actually worked, what had already been tried, didn't. Those tickets got escalated, slowly, or bounced back into the queue to be reopened days later, the same problem, filed again, no closer to fixed.

None of this was hidden exactly. It was in the contract, and in the org chart, if you knew where to look. It just wasn't in the pitch, and it wasn't visible in a scan or a monthly number that looked, on its face, like a complete picture.

What a technician actually costs to employ

A qualified technician doesn't come free. Wages, benefits, tools, licensing, and training all set a real floor on what a provider can charge and still deliver real support. Below roughly $40 a month per user, the revenue can't cover the cost of that work, unless the provider is operating at a loss.

When a price sits below that floor, something still has to give. It usually shows up as the patterns above: tickets padded with the provider's own automated activity, real support work reclassified as billable, or first-contact tickets routed to a lower-cost outsourced desk. A price that looks unusually low next to everyone else quoting the same scope is worth asking about directly, not because low pricing is always wrong, but because the difference has to be coming from somewhere.

The fix that didn't fix it

Frustrated and no longer trusting what a monthly number from an outside provider actually represented, the business made a decision: hire someone internally. A full-time IT position, seventy to ninety thousand dollars loaded, to bring control back in-house.

It's an understandable decision. It's also usually the wrong one, for a specific reason. The original problem was never that the work was outsourced. The problem was that the business had no way to verify what it was actually paying for, what a scan actually meant, or who was actually doing the work behind a number that looked complete. Hiring one internal person doesn't solve that. It just moves the same unverifiable relationship in-house, with new risks attached: one person now holds all the institutional knowledge, one person is a single point of failure when they're out sick or leave, and one salary rarely covers the breadth of expertise a small IT department actually needs, security, backup, networking, compliance, all at once.

The business had traded a provider it couldn't verify for a hire it couldn't fully staff. The underlying issue, not knowing what was really behind the numbers it was shown, was still standing exactly where it started.

What actually would have fixed it

The real fix isn't a lower number, a scarier scan, or a headcount. It's specificity, in writing, before anything is signed. What counts toward "included" support, and how is that measured. Who actually answers the phone on a first call, and what happens when they can't solve it. What a scan is actually measuring, and what a plain-language walkthrough of the findings looks like, not just a color-coded score.

A provider who can answer those questions specifically, before a contract is signed, is giving you something to verify against later. A provider who answers in generalities, or leads entirely with a scary scorecard, is asking you to trust the color coding instead.

What this illustrates, not proves

This is one composite pattern, not a claim that every scan is misleading or every lower quote is a bad one. What it reflects accurately is a common shape in the industry: a price and a pitch built to win the deal, with the actual scope, and the actual people doing the work, decided later, after the business has less leverage to ask questions than it did during the pitch.

Three questions worth asking before you sign anything

Ask directly: of the ticket volume this price is based on, how much is generated by your own systems versus by our employees actually asking for help? Who specifically answers a first call, an in-house team or a subcontracted help desk, and what happens when they can't resolve something themselves? And if you're showing us a scan or an assessment, can you walk us through what's actually flagged and why, in plain language, rather than just the score?

If you can't get a straight answer to any of these before signing, that's the finding.

Schedule an IT Environment Review if you're evaluating a current provider, or a new one, and want a second opinion on what's actually being covered, and what's actually being shown to you.

Common questions

Questions leadership usually asks first.

Next step

Get a clearer view of your IT environment.

Find out what is working, where the risks are, and what needs attention next.