Case study: helpdesk implementation
at a logistics company

State before the rollout - diagnosis

How IT problems were reported

Email. Phone. A Teams message. A sticky note on the technician's monitor when someone passed by in the warehouse. I am not joking - the sticky note on the monitor was a genuine reporting channel. The result: no central register. The technician had to scan 4 mailboxes and the sticky notes at the start of each day just to know what was waiting.

Metrics before the rollout

Main problems flagged by users

We ran 20-minute interviews with 12 employees before the rollout:

1. "I do not know if my ticket was received" - 9 out of 12 people
2. "I have to call to check what is happening" - 11 out of 12
3. "I often report the same problem because nobody remembers it is chronic" - 6 out of 12
4. "If there is a scanner outage in Gdansk, the technician in Poznan finds out late" - 4 out of 12

Why logistics is a special ITSM case

Scanners and terminals as critical infrastructure. In a warehouse a barcode scanner is a work tool. Without it the worker stands still. A scanner outage stops the person and generates real cost. That is a different priority than a broken keyboard in the office.

Multi-site without local IT. Most logistics companies of this size have central IT, not IT in every warehouse. The technician is in Poznan, the problem is in Gdansk. Remote coordination requires a system managing workflow, not email. How to pick a system for that kind of structure is covered in our guide to helpdesk for a 50+ employee company.

Shift work. A 6:00 AM failure on the morning shift should not wait until 8:00 AM. ITSM with SMS alerts and automatic escalation solves that problem without adding a headcount.

SLAs with external customers. A logistics operator is on the hook to its own customers under SLAs. An IT failure that affects those commitments must go into a different queue than a standard ticket.

Rollout - 8 weeks step by step

Weeks 1-2 - Discovery and design

Workshops with the IT manager and 2 technicians: mapping current processes, identifying ticket types, setting priorities. Key decision: split into 3 queues (Poznan, Gdansk, Wroclaw warehouses) with the option to escalate to a shared queue when the local technician is unavailable.

Weeks 3-4 - Base configuration

ServiceDesk Plus Cloud installation. Items configured:

• 3 locations as separate Sites in SDP
• 12 ticket categories (hardware/software/network/WMS/scanner/printer/access per warehouse)
• 3 SLA tiers: Critical (scanner/WMS, 1h), High (1 person idle, 4h), Normal (1 business day)
• Automatic SMS notifications to the technician on Critical tickets - including outside working hours
• Self-service portal: 2 forms (report a problem / order hardware)

Weeks 5-6 - Migration and training

Import of 90 historical emails as tickets. Import of 180 devices from Excel into the CMDB (Excel had 220, but 40 no longer existed). Training: 3 sessions x 45 minutes (one per warehouse, remote via Teams). Most important moment: showing that the portal sends status notifications - the "wow moment" for many users.

Weeks 7-8 - Go-live and hypercare

Week 7: go-live. The helpdesk email kept running for 2 weeks with an auto-reply pointing to the portal. Issue: 30% of tickets still came in by email. Solution: after 2 weeks the helpdesk email was closed and auto-forward was set up to convert emails into tickets. Every email lands in SDP as a new ticket.

Results after 3 months

The values below are illustrative - they show the typical direction and scale of change after cleaning up the helpdesk process, not verified data for a specific client. Real results depend on the starting point, team discipline and company context.

Additional effects

Visibility for management. For the first time the IT manager had a weekly report for the CEO: number of tickets, types, which warehouse generates the most issues. The CEO saw that one warehouse had 3x more scanner tickets. That became a signal for a data-driven purchase decision, not a gut-feel one.

Chronic problems become visible. SDP aggregates tickets per device. The IT manager noticed that one printer generated 12 tickets in 2 months, and replacement was faster and cheaper than another repair. The same logic applies to manufacturing environments: how to manage CMDB and equipment failure history is covered in our article on helpdesk for a manufacturing company.

What did not go to plan

Self-service portal - adoption slower than planned

I assumed 80% portal adoption within 4 weeks. Reality: 62% after 4 weeks, 81% after 8 weeks. The problem was in the Gdansk warehouse - shift staff did not have the habit of opening a browser before reporting an issue. Solution: QR-code stickers to the portal on workstations. A simple idea that worked.

SLA configuration needed correction

The first version of the Critical SLA (1 hour) turned out to be unrealistic when the technician was in Poznan and the issue was in Gdansk. After 3 weeks we changed it to: 30 minutes for the first user contact, 4 hours to resolve or escalate.

CMDB is still incomplete

After 3 months 80% of devices are in the CMDB. The missing 20% - mainly portable technician hardware and some mobile phones. That is not a failure - it is the realistic level you can reach without dedicated CMDB time. We are filling it in this quarter.

What the solution cost

At the client's request I do not give exact figures. Indicatively for a company of this size (180 employees, 10 technicians as SDP agents):

• ServiceDesk Plus Professional Cloud license: ~8,300 PLN/year (Professional Cloud, 10 technicians)
• Implementation (8 weeks, Rotech Group): 22,000-28,000 PLN one-off
• Training: included in implementation

Total Year 1: approx. 30,000-36,000 PLN.

Questions and answers