IT issues interrupt work, often at the times a business can least afford it. Oblytech’s help desk support is built for that gap, with technical requests handled by our team. We act as an extension of your team, working through technical problems so you can keep your focus on running the business.
We take a collaborative approach to help desk work, with our team handling technical requests:
We diagnose and resolve a wide range of IT problems, from software glitches and hardware malfunctions to network connectivity issues.
We offer fast and efficient remote assistance, often resolving issues without the need for an on-site visit.
We provide support for your essential software applications and hardware devices.
We help your employees build the knowledge and skills they need to use your IT systems well.
We offer customized service desk solutions tailored to your specific requirements, ensuring efficient incident management and request fulfillment.
Oblytech’s help desk support covers the IT problems that stop people from working. Our team handles technical requests across your environment, so your staff can stay focused on the core business operations they are there to deliver.
A help desk that is open only during office hours is perfectly adequate for many businesses. The question is whether the business can tolerate a problem sitting until the next working day. A payroll run that fails at the end of the month, a point-of-sale system that stops on a Saturday, or a sales team that cannot reach a shared drive before a client call each has a different cost of waiting. Out-of-hours cover should be bought for the problems whose cost of waiting is high, not for every ticket by default. The first piece of work is therefore a short list of systems and the time each one can be unavailable before the business is affected.
| Type of problem | Cost of waiting until morning | Coverage that usually fits |
|---|---|---|
| A user cannot log in on a non-critical application | Low, with a workaround available | Standard hours with a documented workaround |
| A shared service used by many staff is down | High during business operations | Out-of-hours response for that service |
| A system that processes time-sensitive transactions fails | Very high and often immediate | Out-of-hours response with a named escalation path |
| A hardware fault at a site with no on-site staff | Varies with the site’s function | Remote triage first, then a decision on any on-site visit |
A help desk can only route an incident well if the people deciding its priority have already agreed what each category means.
A sound help desk runs on a small number of rules that everyone understands. Each incident is logged with the user, the system, the time, the symptom and the business impact. Priority is set from impact and urgency rather than from how loudly the caller speaks. Simple incidents are resolved at the first point of contact using a known procedure. Incidents that need specialist skill are routed to a named group with a stated expectation for the next update. Closure requires the user to confirm the fix, and the record notes the cause so that repeated problems can be found later.
Response and resolution expectations should be written into the service agreement as targets the provider commits to measure and report. A target without a measurement method is only a hope, so the buyer should ask how each target is calculated and how breaches are shown in the monthly report.
Remote support can resolve many user problems without a visit. It depends on the device being reachable, on the support tools being permitted by the buyer’s security policy and on the user being able to describe the symptom. Some problems cannot be solved remotely, such as a failed disk or a cable that has been disconnected, and a good help desk recognizes those early and sends a technician rather than extending the call. The buyer should agree in advance which devices can be accessed remotely, what the user must approve at the time of access, and how every remote session is recorded.
A common mistake is treating the help desk as the only place where support happens. Problems that recur across many users usually have a cause in configuration, licensing or a service that has changed. Those patterns should be reported to the people who own the system, not fixed one ticket at a time.
Out-of-hours cover tends to cost more when it is designed for every possibility and less when it is designed for a short list of critical services. The working arrangement should name the systems covered, the people who can be called, the steps they follow and the conditions under which a call is allowed. It should also say what the business owes in return, such as a contact who can confirm priorities and make a decision about a workaround at night. Without that, the on-call person spends the night waiting for an answer that never comes.
Rotas need a fair spread of duty so that the same person is not on call every week. The rota should be published in advance, with a named backup, because a single point of failure in the on-call list is a service risk in its own right.
Monitoring is what turns out-of-hours cover from a promise into a practice. Alerts from servers, network devices and key applications should reach the on-call person without a user needing to notice a problem first. Without monitoring, the first sign of a fault is a call from a frustrated employee, and the desk has lost the chance to act before the impact spreads. The buyer should ask which systems are monitored, which alerts are routed to the desk, and which alerts are deliberately suppressed, because suppressed alerts are where many silent failures begin.
Handover between shifts is a second area that needs attention. A ticket that was open at five in the afternoon should carry a note explaining what has already been tried, what the user was told and when the next check is due. Without that note, the evening team repeats the first steps, the user repeats their description of the problem and the time to resolution grows. A simple shift handover template, kept in the ticketing system, removes most of that waste.
Finally, the desk should be told which changes are coming. A planned update, a new application or a change to a password policy can generate a wave of calls that look like faults. A short calendar of planned changes, shared with the desk, lets the team recognize those calls quickly and route them to the right owner.
No. Start with the systems whose failure stops revenue, safety or statutory work, and cover the rest on standard hours with a documented workaround.
The agreement should say when the incident is passed to a specialist group, what the user is told and how the business is kept informed. Silence overnight is a failure worth guarding against in any agreement.
Ask for the monthly report, the number of incidents that were reopened, the incidents with a recurring cause and the time spent waiting for the user to respond. Those figures show whether the desk is resolving problems or only closing tickets.
It can, provided the buyer supplies documentation, access and a named owner for each application. Without those, the desk can only log the incident and pass it on.
Begin with a list of systems, the hours each one must be available and the cost of an outage in each case. That list is the starting input for any coverage decision, whichever provider is chosen.
The managed IT services overview lists the managed IT services on offer, and the remote IT support page covers support delivered from a distance. Support for business applications is described on the application management page. ServiceNow users can compare this approach with the incident management page, and the operational level agreement concept explains what an operational level agreement is.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.