Single entry point
Portal, email and Teams all feed one queue. A request that bypasses it, say in a private message, is logged in the system before work begins.
Imagine a retailer with 120 employees, eight shops across Slovenia and a central warehouse. The shops contact IT by email, in a chat group or through their regional manager, the warehouse phones a colleague it knows, and head office has its own direct line. The two in-house IT staff always tackle whatever is loudest rather than whatever matters most. When a till in Koper freezes on a Saturday morning, nobody can tell whether the request reached anyone at all. A service desk fixes this with one entry point and clear rules. Each request type has a form, a target time and an owner in the catalogue, priority is set from impact and urgency, the tool records the clock, and users answer simple questions themselves using a knowledge base. Apply sets up and runs the service desk either as part of end-to-end support or as first line alongside your own team, which can then focus on projects. The outcome is support you can measure, compare between sites and improve on the strength of figures rather than impressions.
A service desk built on ITIL principles and scaled for organisations of 50 to 250 people, without paperwork nobody would ever use.
Portal, email and Teams all feed one queue. A request that bypasses it, say in a private message, is logged in the system before work begins.
For frequent services such as a new joiner, application access or a new device we build forms that collect every required detail. No more back-and-forth about which licence is needed.
Priority comes from two questions: how many people or processes are hit, and how fast damage builds up. A frozen till on Saturday morning outranks a new monitor for the boardroom.
Response and resolution times are tracked by the tool. While we await your reply or a supplier, the clock stops and the reason is noted on the request.
Short how-tos for the commonest questions: mail on a phone, connecting to the VPN, changing a toner. Written in Slovenian and kept current as things change.
Till system updates or network changes are planned, approved and announced in advance, with a fallback plan if anything misbehaves.
Request counts, targets met, repeat issues and satisfaction for each site separately, so you can see whether a problem lies in equipment or in working habits.
Implementation takes six to ten weeks depending on the number of sites. Most of that is alignment with managers rather than technology.
On video calls with department and site heads we identify critical processes, who approves what and what frustrates them most about current support.
Drawing on recent requests we assemble a catalogue of twenty to thirty services and their forms. You review and approve the draft.
The new approach is trialled at two locations first. After three to four weeks we refine categories, times and forms.
Remaining sites switch over gradually. Each month we go through the report together and decide what to improve next.
Nobody reads a three-hundred-item catalogue. A frequent mistake is building a perfect catalogue that covers every conceivable request. Users get lost in it and go back to email. In practice twenty to thirty services handle the great majority of requests, and an “other” form takes care of the rest. We only extend the catalogue when something starts recurring under “other”.
Once you have several sites or departments, more than roughly fifty staff, or an internal IT team that needs oversight of its workload. If requests are few and similar, a helpdesk is enough.
Yes, provided it supports timing with pauses, forms and reporting. If you have no tool, our portal is included. Request data belongs to you and can be exported at any time.
When a request is closed the user gets a single rating question and a comment box. We read and reply to every low score, and the average sits next to the times in the monthly report.
Typically we take first line, queue management and the knowledge base, while your team handles requests that need knowledge of particular processes or a physical presence. Both sides use the same tool and rules.
A service desk builds up records of incidents, changes and access of the kind NIS2 and ZInfV-1 expect from essential and important entities. Whether the rules apply to you and exactly what you must do is for your legal adviser to confirm. Larger organisations can reach us at b2b@apply.si.
Describe how many sites and staff you have and how requests get to IT today. We will suggest a catalogue, priorities and an implementation timeline.
Enquiry received
An engineer will write back no later than the following working day. Faults that leave your staff unable to work are always looked at first.
No town by that name here. Check the letters, or settle for the nearest larger place. Our engineers work only over the internet, so Kočevje and Koper get precisely the same treatment.