Everyone asks what’s included in a business IT support service. Few ask about what really decides whether it will serve you: how it works on an ordinary Tuesday at half past nine, when half the staff can’t open their email and the ERP takes forever to load. In that moment the service catalogue doesn’t matter, the workflow does: where your request comes in, who picks it up, how fast they reply and who fixes it.
This is the real day-to-day of business IT support, from the inside: the channels you use to ask for help, the journey of a ticket from the moment you open it until it’s closed, what an SLA is and why it separates a serious provider from the classic “I’ll call you back”, and when things get solved remotely and when someone has to come to your office.
How your team asks for help: and why the channel matters
The first detail that reveals the quality of a support service is how you ask for help. A good service gives you several ways in, each for a type of urgency, and they all end up in the same place: a system that logs the request. If the way you ask for help is “the IT guy’s WhatsApp”, you don’t have support, you have luck.
- Phone. For whatever has you stopped right now. They pick up, identify you and open the ticket while you talk. It’s the channel for real urgency, not for “I’ve lost a desktop icon”.
- Email. For whatever can wait a few hours. You write, the system generates the ticket on its own and sends you back a number. Convenient, but with no guarantee of speed if the problem is serious.
- Client portal. The grown-up version of email: you open the incident, attach a screenshot, see its status and check the history of everything that’s happened to you. It’s where traceability lives.
- Chat. For quick questions and short queries without tying up a phone line. Used well, it takes a huge amount of minor volume off your plate.
The channel matters because it sets the outgoing priority: a downed server gets reported by phone, not by an email that maybe no one reads until the afternoon. And there’s a less obvious reason: if everyone asks for help on their own, no one has the full picture of what breaks and how often. Centralising the intake turns scattered incidents into data that helps stop them from recurring.
The journey of a ticket, step by step
This is where you can tell whether a support service is properly built or improvised. A ticket isn’t “someone looks at your problem”: it’s an object with a status, an owner and a clock. Let’s follow one from start to finish with a case from any office.
1. Logging. You call because three people in accounting can’t load the shared folder. The technician opens the ticket, notes what’s failing, who it affects and since when. That record isn’t paperwork: it’s what ensures that, if the problem bounces between technicians, none of them starts from scratch.
2. Prioritisation. Not every request is worth the same. You cross impact (how many people it affects) with urgency (how much it hurts to leave it as is): accounting with no invoicing in the middle of month-end is high priority; a slow mouse isn’t. That classification decides what gets touched first, which is why it has to be a rule, not the mood of whichever technician is on duty.
3. Remote resolution. The technician connects to a machine, reviews the group’s permissions on the server and sees that a recent change locked out half the staff. Most incidents —passwords, email, permissions, configurations, software— are fixed right here, without anyone moving and in minutes. This is the bulk of the day-to-day.
4. Escalation. If the first-line technician can’t get there —the problem is systems, networks or architecture— the ticket moves up a level with the diagnosis already done, not with a bare “it doesn’t work”. An escalation with context is the difference between solving it in ten minutes and losing the whole afternoon. This is where well-structured IT maintenance pays for itself.
5. On-site visit. Only when the problem is physical and there’s no other way: a machine that won’t turn on, a switch to replace, cabling, a printer that has to be opened up. A technician travels to your office. It’s the last resort, not the first, precisely because it’s the slowest and most expensive.
And there’s a sixth step almost everyone skips: closing with root cause. Good support doesn’t close the ticket when accounting is working again, but when it has stopped the issue from happening again. Closing the symptom is easy; closing the cause is what reduces your incidents month after month.
What an SLA is and why it changes everything
An SLA (Service Level Agreement) is the part of the contract where your provider commits in writing to attend to you within specific times depending on severity. It’s what separates serious support from “I’ll get back to you”: without an SLA, “we respond fast” means nothing, because fast to them could be tomorrow.
An SLA worth having makes this clear:
- Response time. How long they take to pick up your incident, not to resolve it. Different depending on severity: a critical outage can’t have the same commitment as a query.
- Target resolution time. The window in which they aim to have it working again, with a realistic margin according to the type of failure.
- Defined priority levels. What counts as critical, high, medium or low, written down in advance and not negotiated in the heat of the moment every time.
- Coverage hours. 9 to 6, or 24/7, and who covers the on-call shifts outside business hours. An SLA with no clear hours is half an SLA.
- What happens if it’s breached. An agreement with no consequences is a promise. Good SLAs spell out what happens when the commitment isn’t met.
“As soon as possible” is not a commitment: it’s a polite way of committing to nothing. The SLA exists precisely for that.
Note that the firm commitment is the response time, not the exact resolution: no one can promise an unknown problem will be fixed in X minutes, but they can promise that someone picks it up within that window and it doesn’t sit in an invisible queue. That guarantee is what lets you plan the business knowing that, when something breaks, there’s a clock running on the side of whoever provides your service.
Remote or on-site: when each one
The question isn’t “remote or on-site?”, but “which one fits here?”. A good service uses both and knows when to switch from one to the other, without charging you for a call-out on something that gets fixed from a keyboard.
Remote resolves the vast majority of the day-to-day: it’s immediate, doesn’t depend on schedules and fixes everything that’s software and configuration —passwords, email, permissions, installations, servers, backups, network. If your provider has to get in a car to reset a password, something is badly set up.
On-site comes into play when the problem is physical or the project calls for it: a machine that won’t boot, hardware to replace, cabling to work on by hand or the rollout of new workstations at a site. A provider that covers all of Spain with call-out costs priced in advance —and not improvised— is what keeps you from being stranded the day the fault can’t be fixed over a cable. Ideally the same point of contact covers both worlds, so you don’t explain your problem twice.
Support with an SLA and a single point of contact: how MagicBoxDesk works
At MagicBoxDesk we outsource your company’s IT department with all of this in place from day one: clear intake channels, tickets with status and traceability, a written SLA with times based on severity, and remote resolution for the day-to-day with on-site visits across the whole of Spain when the problem demands it. And always with a single point of contact who knows your infrastructure, so you don’t repeat your problem to a different technician every time. You can see the detail of our services and of how our managed maintenance works.
We don’t sell loose technician hours: we build the workflow that keeps your operation from grinding to a halt and stops incidents from cropping up. Tell us how many workstations you have and what breaks each week, and we’ll tell you which SLA we cover it with. Request a no-obligation quote and we’ll make it clear from the start.