Warning signs with your IT provider

An IT provider usually shows problems well before the first outage – you just need to know what to look for. Five 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 gets billed individually as billable hours, and promised monitoring never actually gets shown. None of these signs alone proves a problem – but together, they're worth a closer look. And the same five questions apply just as much to NDVDL.

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 watch how long it takes to get a response
• 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.