A new ControlUp study put hard numbers on something every help desk lead already feels in their gut: sign-in problems account for up to 53% of help desk tickets at individual enterprises. Half the queue isn't Exchange falling over or a firewall dying — it's people who can't get logged in. Expired passwords. Account lockouts. MFA re-enrollment after a phone upgrade. A machine loading a temporary profile, triggering a "where are my files" panic ticket.
There's a second finding in that study that matters even more for your staffing and your SLAs: network issues take significantly longer to resolve. So the work that generates ticket volume (sign-ins) is mostly low-effort, while the work that burns your best engineers for entire afternoons (network) barely registers in the numbers. Most IT teams are measuring one half of the problem and bleeding time on the other half — and the tooling is the reason why.
Two Numbers That Describe Your Week
The 53%: high volume, mostly repeatable.
Run down the usual suspects in a sign-in queue and a pattern emerges:
- Password resets and account lockouts dominate. Critically, a large share of repeat lockouts aren't user error — they're stale credentials. A scheduled task, a Windows service, or a mapped drive still authenticating with the old password after a reset. You unlock the user, they walk away, and they're locked out again in an hour. Second ticket. Third ticket. Same root cause, never touched.
- MFA is the growth segment: a new phone means re-enrolling the authenticator app, plus conditional access changes and token issues.
- Temporary profile corruption: the machine loads a TEMP profile and the user is convinced they lost everything.
Each of these takes 5–15 minutes to handle. Multiply by dozens per week per tech, and half your help desk capacity is going to a category that instrumentation and automation could largely absorb.
The long tail: low volume, brutal effort.
Users report symptoms, not causes: "it's slow," "the internet is down." The actual cause is packet errors on an uplink port, a flapping switch, a timing-out DNS forwarder, or a saturated WAN link — two or three hops away from anything the user can describe. Diagnosing it means correlating who is affected, when it started, and where the fault sits. If that data lives in the helpdesk, the monitoring tool, and the switch CLI respectively, resolution time explodes. That's why network issues take so much longer to close: your stack doesn't do the correlation for you.
Every MSP tech knows this scenario: a client's ISP link starts flapping at 9:15. By 9:40, twelve users have called and twelve tickets exist. The latency alert from your monitoring tool is sitting in a shared inbox nobody watches, because an alert is not a ticket — no assignee, no SLA clock, no closure loop. The tech who could have fixed this in five minutes spends twenty minutes just triaging duplicates, and every SLA clock started ticking at first human contact, not at first symptom.
Where the Current Tool Stack Breaks Down
- Standalone helpdesks (ConnectWise Manage, Freshservice, Zendesk, Jira Service Management) are reactive by design. They learn about problems when a human types them in. There's no device context on the ticket, so the tech asks "have you tried restarting it" while the machine's event log has been screaming all morning.
- RMM platforms (NinjaOne, N-able, Datto RMM) see the endpoint, but ticketing and device health live on different screens. Remote access means tab-hopping or a copy-paste session ID dance.
- Standalone monitoring (PRTG, Zabbix, Nagios, SolarWinds) emails alerts into a distribution list. Overnight alerts get read at 8:47 the next morning — after users have already reported the problem and the queue is on fire.
- The reporting tax: producing an SLA report means exporting CSVs from two systems and merging them in Excel. The numbers are stale the moment you build them, and nobody fully trusts them.
These gaps exist because the tools were built in silos — helpdesk as a process layer, monitoring as an infrastructure layer, RMM as an endpoint layer — with brittle, one-way integrations bolted on as afterthoughts. The alert-to-ticket pipeline either doesn't exist or dumps unfiltered noise into the queue, so teams turn it off and go back to email.
How AlertMonitor Changes the Equation
AlertMonitor ships the monitoring engine, RMM, and helpdesk as one product, and that changes the workflow for both of the study's findings:
Sign-in tickets get instrumented and pre-contextualized. An event log monitor on your domain controllers watches for account lockouts (Windows Event ID 4740). When one fires, AlertMonitor creates a ticket automatically — assigned to Tier 1, naming the locked-out account and the source machine that triggered it. The source machine is almost always where the stale credential lives. What used to be "unlock the user and wait for it to happen again" becomes "fix the scheduled task on the source machine in one touch." Repeat lockouts stop being a subscription.
Network incidents get detected before the twelfth phone call. A latency or interface-error threshold on a core switch uplink fires an alert, which becomes a ticket with a link to the network topology map — so the tech immediately sees scope (which users and devices hang off that switch) instead of discovering it ticket by ticket. Alert correlation collapses a site-wide outage into one incident with thirty linked users, not thirty duplicate tickets.
Every ticket arrives with context. Alert history for the device, current health (CPU, disk, patch status, last reboot), and one-click remote access from the ticket itself. No tab-hopping, no twenty questions with a frustrated user.
SLA clocks start at detection, not at first human report. Because the alert and the ticket are the same object in one system, first-response and resolution metrics are real numbers, not spreadsheet archaeology.
The before/after for a routine lockout:
- Old way: user calls → triage questions → remote in → open ADUC → unlock → user logs in → lockout recurs next week → another ticket. 15–20 minutes, and it comes back.
- AlertMonitor: 4740 event fires → ticket created with account plus source machine → one-click remote session to the source box → stale scheduled task fixed → user unlocked → ticket closed. 4–6 minutes, and it doesn't come back.
Practical Steps You Can Take Today
1. Baseline your sign-in volume. Filter your helpdesk for the last 90 days on keywords like password, reset, locked, lockout, MFA, sign in, can't log. Most shops land between 40% and 55%. You need the number before you can move it.
2. Pull the last 24 hours of lockouts from your domain controllers:
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4740; StartTime=(Get-Date).AddDays(-1)} -ComputerName DC01 |
Select-Object TimeCreated,
@{n='Account';e={$_.Properties[0].Value}},
@{n='SourceComputer';e={$_.Properties[1].Value}} |
Sort-Object TimeCreated -Descending
That SourceComputer column is where repeat lockouts get solved — it names the machine holding the stale credential.
3. See who's locked out right now and clear it:
Search-ADAccount -LockedOut | Select-Object Name, SamAccountName, LockedOut
Unlock-ADAccount -Identity 'jdoe'
4. Hunt the stale credentials causing the repeat lockouts. Services running as named accounts:
Get-CimInstance Win32_Service |
Where-Object { $_.StartName -and $_.StartName -notmatch 'LocalSystem|LocalService|NetworkService' } |
Select-Object Name, StartName, StartMode, State
And scheduled tasks:
Get-ScheduledTask |
Where-Object { $_.Principal.UserId -and $_.State -ne 'Disabled' } |
Select-Object TaskName, TaskPath, @{n='RunAs';e={$_.Principal.UserId}}, State
Anything running under a named user account is a lockout waiting to happen after the next password rotation. Fix those before they generate tickets.
5. Rule out time skew — the silent Kerberos killer. Clock drift over five minutes breaks Kerberos authentication, and users experience it as "I can't sign in":
w32tm /stripchart /computer:dc01.corp.local /samples:3 /dataonly
6. Split "account problem" from "network problem" in ten seconds. From the affected machine:
Test-Connection -ComputerName dc01.corp.local -Count 2
Resolve-DnsName -Name _ldap._tcp.dc._msdcs.corp.local -Type SRV
Ping fails or the SRV record doesn't resolve? It's connectivity, not the account — skip the password reset and start the network clock. Working from a Linux jump host? Same idea:
for host in dc01.corp.local core-sw01.corp.local; do
ping -c 3 -W 1 "$host" >/dev/null 2>&1 && echo "$host OK" || echo "$host UNREACHABLE"
done
7. Wire the loop into AlertMonitor:
- Add an event log monitor for ID 4740 on every domain controller → alert type "Account Lockout" → auto-ticket to Tier 1 with the source machine and 30-day lockout history attached.
- Put latency and interface error thresholds on core switch uplinks → auto-ticket with a topology link so scope is known the moment it opens.
- Enable safe auto-remediation for the noisy, low-risk failures so they never become tickets at all:
Get-Service -Name 'Spooler' | Where-Object { $_.Status -ne 'Running' } | Restart-Service -Force
What to Measure After 30 Days
- Sign-in ticket share of total volume. It should drop meaningfully as stale-credential sources get fixed at the root and every lockout ticket arrives pre-contextualized.
- MTTR on network incidents. Detection at first symptom instead of the twelfth phone call is where the study's "significantly longer to resolve" starts to shrink.
- Duplicates per incident. Target: one.
- SLA compliance, pulled straight from the system, not a spreadsheet.
The 53% figure isn't a law of nature. It's what a help desk looks like when it learns about problems from phone calls. Connect your monitoring to your ticketing, instrument the sign-in path, and the queue gets shorter, your techs spend time on real problems, and your SLA report writes itself.
Related Resources
AlertMonitor Helpdesk & End-User Support
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.