Pew Research Center just put a hard number on something every helpdesk lead already suspects: 51% of Americans refuse to use chatbots — and the top reason isn't confusion or lack of know-how. It's lack of interest. They know exactly what the bot does. They just don't want it.
For IT teams and MSPs, that single statistic dismantles one of the industry's favorite pitch decks: the idea that AI deflection will shrink ticket volume while your techs graduate to "strategic work." Half your users are opting out on contact. They will call. They will email. They will walk to your desk carrying a laptop like it's an injured pet. The human support channel is permanent infrastructure — and most IT organizations haven't built their helpdesk to survive that reality.
The Deflection Promise Nobody Is Buying
ITSM vendors — ServiceNow, Freshservice, Zendesk, ConnectWise — have spent two years selling "AI-powered tier-1 deflection." The pitch: a bot absorbs password resets and how-do-I questions, ticket volume drops 30–40%, and your technicians finally get to do meaningful work.
Pew's data says half your user base won't engage a bot at all. And critically, this is not a skills gap you can train away. "Lack of interest, not know-how" means it's a preference. Preferences don't respond to a lunch-and-learn or a screensaver campaign.
So here's what actually happens in production: the user starts a bot session, gets three irrelevant knowledge base articles, closes the tab in frustration, and calls the helpdesk. You've now paid for the bot interaction and the phone call, and the ticket still arrives with zero context.
The lesson isn't "users are stubborn." It's that for a huge share of your organization, human support is the only channel that will ever exist — and the winning move is to make that channel fast by ensuring fewer humans ever have a reason to use it.
The Problem in Depth: Your Ticket Arrives Blind
Walk through what happens when a refusenik user calls on a Monday morning:
8:42 AM. "Outlook is being really slow." Ticket #48213. Description: one line. No machine name, no error text, no timestamps.
8:45 AM. The tech starts the ritual: restart Outlook, restart the machine, check the network icon. Fifteen minutes of guesswork, because the ticket contains nothing useful.
9:10 AM. Tech connects via the RMM, pokes around, and finds it: the mailbox server's D: drive is at 96%. Log truncation failed over the weekend.
9:15 AM. Someone finally checks the monitoring tool. There it is: "Disk space low on MAIL01" — fired Saturday at 2:14 AM, sitting in a shared inbox nobody reads, because your monitoring tool (PRTG, SolarWinds, Nagios — pick one) and your helpdesk (ConnectWise Manage, Freshservice, Jira Service Management — pick another) are two separate products with two separate notification systems.
10:00 AM. Fourteen more users have called about slow Outlook. Fourteen duplicate tickets. Fourteen SLA clocks started and "beaten" with a two-minute first response.
Total damage: roughly six hours of degraded email, fourteen wasted phone calls, one blown incident window — and a monitoring system that technically knew the entire time.
This is the structural failure: your helpdesk only knows what users tell it, and your monitoring only knows what nobody reads. Gluing them together usually means custom API scripts one departed admin wrote and nobody dares touch. The costs compound from there:
- Every monitoring-detected incident becomes a user-detected incident. Your users are doing your alerting for you, one phone call at a time.
- Context gathering eats 30–40% of handle time. Techs spend the first third of every ticket figuring out what machine, what changed, what's related.
- Duplicate tickets inflate metrics and destroy morale. Every tech knows the soul-crushing feel of closing the 15th copy of the same incident.
- Your SLA reports are fiction. Response clocks start at first contact, so leadership sees an "8-minute average response" while users experienced six hours of a broken app. Building a truthful report means exporting two systems into Excel and squinting.
For MSPs, multiply everything by client count. The tech with 12 tabs open across 5 tools isn't a meme. It's Tuesday.
How AlertMonitor Handles the Calls the Bot Never Will
AlertMonitor was built on a simple bet: when monitoring, RMM, patching, and the helpdesk live in one product, most "user-reported" issues stop being user-reported — and the ones that still come in get resolved in minutes instead of hours.
1. Alerts become tickets before the phone rings. When a monitored alert fires — disk over threshold, service stopped, patch failed, backup missed — AlertMonitor creates a ticket automatically and routes it based on device, client, and alert type. That MAIL01 disk alert from Saturday 2 AM? It's a ticket in the infrastructure queue with full alert history attached, not an unread email. A tech resolves it Sunday morning, and Monday's "Outlook is slow" calls simply never happen. Your chatbot-hating users never need to call anyone.
2. Tickets arrive context-rich. When a user does call, the tech opening the ticket sees the device's health history, recent alerts, patch state, and a one-click remote access button — in the same window as the ticket. No tab-switching to the RMM. No "can you read me your computer name?" The 20-questions phase of the call disappears, and first-contact resolution goes up accordingly.
3. Duplicates collapse into one incident. User tickets and monitoring alerts referencing the same device get linked. Fourteen people calling about slow Outlook produces one incident record with fourteen linked reports — one SLA clock, one resolution, one clean postmortem instead of fourteen.
4. SLA data starts at detection, not first call. Because the ticket exists the moment the alert fires, AlertMonitor's SLA timers measure the truth: time from detection to resolution, per client, per device type, per technician. IT managers finally report real numbers without an Excel export ritual — and MSPs get per-client SLA evidence for QBRs that doesn't require a spreadsheet archaeology project.
5. One console for the entire workflow. The old way: user call → manual ticket → 20 questions → open the RMM → hunt for the monitoring alert nobody read → fix → close ticket → update the monitor. The AlertMonitor way: alert → auto-ticket with full context → one-click remote → fix → close, with the alert trail attached automatically.
Practical Steps You Can Take Today
Step 1: Audit your deflection reality honestly. Pull last month's numbers. How many bot sessions ended with a phone call about the same issue? If your organization mirrors Pew's 51/49 split, stop funding adoption campaigns and redirect that budget into the human path: better alerting, auto-ticketing, context at first touch.
Step 2: Time your alert-to-ticket path. Count the manual steps between a monitoring alert and a helpdesk ticket today. If the answer is "an email to a shared inbox and someone's memory," you're paying a human to act as a webhook. In AlertMonitor, this is a one-time rule: device/client → alert type → queue → priority.
Step 3: Give techs a 60-second pre-triage script. When the refusenik calls anyway, the first minute should produce data, not questions. Keep these in every tech's snippet library.
Disk pressure — the root cause behind a huge share of "my app is slow" tickets:
# Find any disk under 15% free across critical servers
$servers = @("APP01","SQL01","FS01","DC01","MAIL01")
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
Select-Object SystemName, DeviceID,
@{N='SizeGB';E={[math]::Round($_.Size/1GB,1)}},
@{N='FreeGB';E={[math]::Round($_.FreeSpace/1GB,1)}},
@{N='FreePct';E={[math]::Round($_.FreeSpace/$_.Size*100,1)}} |
Where-Object FreePct -lt 15 |
Sort-Object FreePct
Service state on the box the user is complaining about:
# Two-second check: are the services behind the user's app actually running?
Get-Service -ComputerName APP01 -Name W3SVC, Spooler |
Select-Object Name, DisplayName, Status
Recent patches on the caller's machine — a hung update explains a remarkable number of "my PC got slow" calls:
# Last 10 updates installed on the user's machine
Get-HotFix -ComputerName WS-4471 |
Sort-Object InstalledOn -Descending |
Select-Object -First 10 HotFixID, Description, InstalledOn
And for the Linux servers in the same environment:
# Flag any mounted filesystem above 85% utilization
df -h --output=source,pcent,target | awk 'NR>1 && $5+0 > 85 {print}'
Step 4: Move those checks into proactive alerts. Every script above represents a threshold AlertMonitor can watch continuously. Set the disk alert at 85%, map it to the right queue, and let alert-to-ticket automation do at 2 AM what your monitoring inbox does never. The PowerShell becomes a one-time validation tool instead of a Monday-morning fire drill.
Step 5: Re-baseline your SLA reporting. Once detection starts the clock, expect the numbers to look worse for a month. That's not degradation — that's honesty. Then watch MTTR fall as proactive tickets close before user impact, and take the real chart to leadership.
The Bottom Line
Pew's 51% isn't a rejection of technology — it's a vote for humans when something breaks. That vote is never getting overturned. The IT teams that win aren't the ones with the cleverest deflection bot; they're the ones whose users rarely need to vote at all, because the ticket already existed, the context was already there, and the fix already shipped.
Build the helpdesk for the humans who call. Automate everything that happens before they dial.
Related Resources
AlertMonitor Helpdesk & End-User Support AlertMonitor Platform Overview Book a Demo Helpdesk & End-User Support Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.