You get a support team that answers when something breaks, and monitoring that catches a good deal of it before anyone calls. One agreement covers the laptops, the servers, the network and the backups.
Most small IT teams run on interruption. A password reset lands in the middle of a project, a laptop dies an hour before a client meeting, and the work you actually hired for slips another week. The other version is nobody owning IT at all. Whoever is best with computers picks it up between their real job, and the backups go unchecked for months because that task has no name against it.
We start with an inventory. Every laptop, server, switch, firewall and cloud account gets written down, and anything we cannot monitor we tell you about in writing. Agents go on the machines that take one. The rest we poll. Tickets arrive by phone, email or the portal and get sorted by how much of the business has stopped, so a site outage never queues behind a password reset. You talk to the engineers who know your setup rather than whoever is next on a rota.
Each month you get a plain document. Tickets raised and closed, how long they took, which machines missed their patches, whether the backups ran and whether anyone has restored from one, and which hardware falls out of support this year. We read it with you and turn it into next year's budget. Five printer tickets a week is a printer to replace, and the report is where that case gets made with evidence behind it.
Two numbers get confused in every support contract. Response time is how long before a human replies. Resolution time is how long before you can work again. A supplier can hit a fifteen minute response every month while a broken finance server sits open for three days, and the report will still be green. So we agree both, per severity, and we count resolution from the moment the ticket was raised rather than from the moment somebody accepted it. The other honest admission is that some resolutions are not ours to give. A vendor's own support queue, a telecoms fault, a part that has to travel, all of those sit outside our control, and the agreement says so rather than implying a promise we cannot keep.
Joiners are easy, because somebody is waiting for a laptop and will chase you. Leavers are the risk, because nobody is inconvenienced when it goes badly. An account that still works six months after a resignation is the commonest finding on any audit, and it is almost never malice. It is that HR told a manager, the manager told nobody, and the checklist lives in a document last edited two years ago. So leavers run as a defined task with a written list: mail forwarded or converted, licences reclaimed, the laptop collected and wiped, shared credentials rotated rather than remembered, and finance system access removed on the day rather than at the next review. Ask for the last twelve months of leavers and we should be able to show you each one, dated.
Phone, email and portal, triaged by how much of the business has stopped. Answered by engineers who know your estate, so the second call about the same fault does not start from nothing.
Agents on the servers and laptops that take one, polling for the switches and firewalls that do not. Disk, memory, service state, backup jobs and certificate expiry, which is the one that catches everybody once.
A monthly window the business has agreed, a pilot group first, and a written list of what could not be patched and why. Some line of business software simply refuses the current version.
Jobs watched, and a real restore performed on a schedule with the time it took written down. A green job report proves a job ran, which is not the same as your data coming back.
Joiners, movers and leavers as defined tasks with a checklist, licences reclaimed on the way out, and shared credentials rotated instead of remembered by four people.
Every device, warranty, licence and renewal date in one list that is actually maintained, so a hardware refresh becomes a budget line agreed in advance rather than an emergency purchase.
A fortnight walking the estate: every laptop, server, switch, firewall, cloud tenancy and licence, including the machine in the corner nobody claims. Anything we cannot monitor is written down as exactly that.
The severity table, written with your managers rather than by us. A site down, a team down, one person down and a request are four different promises, and the fourth is not an emergency.
Before routine support starts: patch levels brought current, one restore proved, admin rights trimmed, and the leavers who still have accounts closed. Most estates need four to six weeks of this.
Tickets, the patch window, restores on a schedule, and the joiners and leavers work. You get the monthly report and a review meeting somebody from your side is expected to attend.
Once a quarter the report becomes money: what is out of warranty, what generates repeat tickets, and what should be replaced before it fails rather than during the week it does.
The purchase records are in one place, the machines are in another, and the gap is always larger than anybody expects, including the ones still assigned to people who left.
They were hired to do something else, and the interruption costs more than the reset. This is the most common reason a first conversation with us happens at all.
The job reports say success every night. Nobody has proved that a file, a mailbox or a whole server can come back, or how many hours it would take.
Which means offboarding is a message rather than a process, and the same is true of the licence you have been paying for every month since.
The daily running of the things your business depends on: support for staff who cannot work, monitoring so problems are seen before they are reported, patching, backups that are tested rather than assumed, and the accounts and access that change every time someone joins or leaves. The scope is written down, because a vague scope is what turns into an argument on the worst possible day.
Response targets are set by how much the problem costs you, agreed in writing, and vary by severity: a whole site unable to work is not the same as one person’s printer. What we will not do is publish a single number that flatters us and applies to nothing. The rail on this site carries our average answer time; the agreement carries the commitment.
Usually it supports them. The pattern that works is us taking the volume, the resets, the monitoring, the patch cycle, the out-of-hours cover, so your own person stops being the help desk and gets to do the work only someone inside the business can do. Replacing an internal person entirely is possible; it is a different conversation and a different scope.
By restoring from them on a schedule and writing down how long it took. A backup report that says success proves a job ran, not that your data can come back. The number worth knowing before an incident is how long a restore takes and what it does not cover, and that number should come from a rehearsal rather than from a crisis.
We do, and most companies of forty people do not need the full version. Genuine round the clock cover means somebody awake and paid to be awake, which is a rota of several people, and the price reflects that rather than reflecting how often you call. What most businesses actually want is out of hours cover for a short list of systems that would cost real money to have down overnight, with everything else waiting until morning. So we ask which systems those are and what an hour of downtime costs on each, then price the cover against that list. Treat a cheap round the clock line elsewhere with suspicion: it often means an answering service that raises a ticket for the morning, which is a different product wearing the same words.
Often it is a training problem wearing a support ticket. When one department produces a third of the queue and the tickets are variations on how do I, the answer is not a faster response, it is half an hour of teaching or a change to how that team was set up in the first place. Our monthly report groups tickets by type and by team for exactly this reason, and we will tell you when the cheapest available action is a short session rather than more support. The other version of this is a system that genuinely is confusing, in which case your ticket volume is evidence you can take to the supplier who sold it. Either way, a support contract that quietly profits from repeat questions is a badly designed one.
Hardware, licences and third party subscriptions are yours and are billed by whoever sells them. Projects are separate: a migration, an office move, a new firewall, a rollout across the whole company. Those get quoted against a scope rather than absorbed, because a fixed monthly fee that quietly includes projects is either padded from the start or resented by the end. On site visits are included up to an agreed number and charged beyond it, which matters if your sites are scattered. Anything we cannot see is excluded by definition, so a system we are not permitted to monitor is named in the agreement as outside the service. The scope document is short, and we would much rather argue about it in week one than during an outage.
When the work is mostly not support. If your days are dominated by a line of business application somebody has to understand deeply, by data that lives inside your own processes, or by supplier relationships nobody outside the company can hold, an internal person will beat any contract. The same applies when you need somebody physically present most days, or when people in your building will never raise a ticket and will only ask whoever sits nearest. The arrangement we see working most often is one internal person plus us for the volume, the monitoring, the patch cycle and the cover while they are on leave. Two internal people and no contract also works. One internal person and nothing else is what fails, usually quietly, during their holiday.
We are happy to answer any questions you have and help you work out which of our services fit your needs.
