Warning signs with your IT provider

An IT provider usually shows problems well before the first outage. Five warning signs are particularly telling: documentation isn't handed over, passwords and access stay exclusively with the provider, a quote is drawn up without a site visit, every small task is billed individually by the hour, and promised monitoring is never shown. None of these signs proves a problem on its own, but several together justify a closer look at your IT support.

Is documentation actually handed over?

A network diagram, configurations, a list of the systems in use – these are documents that should really exist during ongoing operations regardless of whether anyone's currently asking for them. A clear warning sign is when a concrete request for this documentation gets a vague answer, citing lack of time, "it's all in my head", or a promise that never gets kept over months. This is easy to check objectively: a simple request for the current network diagram and a system list isn't an unreasonable demand – any serious provider should be able to fulfil it without much effort, because they need that documentation for their own work anyway.

• Specifically request the current network diagram and system list, and see whether and how completely the documents arrive
• Check whether the documentation actually matches the current state or is noticeably out of date
• If you get a vague answer, ask specifically why the documentation isn't being handed over

Do passwords and access stay exclusively with the provider?

Anyone who holds administrative access to the firewall, servers, Wi-Fi controllers or camera systems exclusively for themselves and doesn't hand it over creates structural dependency for the client – regardless of whether that's deliberate or simply never came up. It rarely shows up day to day, but becomes a real problem the moment the provider is unreachable, the contract ends, or someone inside the company suddenly needs access. This is easy to check with a simple question: if the provider became unreachable tomorrow, would the company have access to its own infrastructure?

• Ask specifically who besides the provider has access to central credentials
• Manage credentials for company-owned accounts (domain, central cloud services) independently of the provider
• Agree at the start of the contract that the company itself, not only the provider, knows the administrative access details

Is the quote drawn up without a stocktake?

A quote produced without a site visit, or at least a detailed technical questionnaire, necessarily rests on assumptions instead of the actual situation. This often shows up later as change orders presented as unforeseeable, even though a proper stocktake beforehand would have caught them. This is easy to check directly in the quote: does the calculation visibly rest on concrete figures gathered on site – number of devices, cable run lengths, existing structure – or on generic assumptions that would sound the same for any business?

• Before accepting a quote, ask exactly what the calculation is based on
• Check whether a site visit or a detailed questionnaire actually took place
• For very generic quotes, ask specifically about the assumptions behind them

Does every task get billed individually as billable hours?

A support model where every small adjustment – an extra port forward, a new user on the Wi-Fi, a quick look at an error message – gets billed individually as billable hours shifts the incentive: frequent small requests get expensive for the client, even though they're often done in minutes. That alone doesn't make a model dishonest, but it's worth checking how transparent the billing is and whether there are alternatives to pure hourly billing. This is easy to check on the last invoice: is it clear what time was billed for what, or do the line items stay vague and generic?

• Check past invoices for clarity: can you tell what time was spent on what
• Ask whether there's a flat-rate model for recurring small requests instead of pure hourly billing
• Before signing a contract, clarify what's included in the agreed model and what gets billed separately

Does promised monitoring actually get shown?

Monitoring has become a standard promise in many quotes by now – the real question is whether it can actually be demonstrated. A provider selling monitoring as a service should be able to show, without much effort, what specifically gets monitored and what an alert actually looks like when it matters. A warning sign is when this question gets a vague answer, or it turns out that an outage was noticed inside the company first rather than by the provider, despite monitoring being contractually promised.

• Ask specifically what gets monitored and what a notification actually looks like when something happens
• Ask to be shown an example or a live view of the monitoring once
• Notice whether a past outage was picked up first by the provider or first internally

What to do if several of these signs apply

A single sign is rarely reason enough for an immediate switch – several at once are a different matter. The first step is always the same: request the missing documentation and access specifically, in writing, with a reasonable deadline. If the existing provider doesn't respond, or responds vaguely, that's a further sign in itself. Anyone who then decides to switch should first look at how a switch works without disrupting operations – that can be prepared in a structured way independently of the warning signs described here.

How NDVDL sets up IT support

Before we offer anything, we come on site and record the network, servers, firewall, backup and access. That results in a written proposal with a clear scope and clear exclusions. After implementation or takeover, we look after the infrastructure on an ongoing basis: maintenance, monitoring, documentation that belongs to you, and access your company can reach itself. You have one fixed contact person who knows your setup.

Behind several warning signs there is often a more fundamental question: should IT keep running on individual call-outs, or should a managed service with responsibility set out in writing take over day-to-day operation?