Ticket deflection: the six request types to automate first

The first thing I ever automated was a chat command that returned the guest Wi-Fi password. I was proud of it for a week. It deflected maybe four requests a month.

That same month, printing generated somewhere north of forty.

I had picked that project the way most of us do, by choosing whatever looked most interesting to build. It took me an embarrassingly long time to accept that with ticket deflection, build order matters more than build quality. A mediocre automation pointed at your highest-volume category beats an elegant one pointed at your third-lowest.

Now I use three questions. How often does this arrive. How much judgment does answering it require. And the one I added after getting burned: can the person confirm for themselves that it worked, without asking us? If they cannot, nothing has been deflected, and you have split one ticket into two.

The four that are mostly solved problems

These first four are well-trodden ground. You are not inventing anything, only deciding to finally do it.

1. Password and credential resets

Highest volume, lowest judgment, and a large share of the demand is manufactured by us. Force a rotation every 90 days and you get the append pattern: a 1, then a 2, then a 3, until someone runs out of digits and genuinely cannot remember which one they landed on. A policy produced that behavior, and the people following it did nothing unreasonable.

The flow. Verified self-service reset in whatever tool people already have open. Then the variant almost nobody has turned on: System Settings surfaces a per-account registration health indicator for platform SSO, green or red. Someone back from six months of medical leave, with no fresh tokens and therefore broken sign-in, can click re-register and be working about a minute later instead of calling. A whole ticket category, with a button already sitting in front of it that nobody has been shown.

The hard part. Verifying who is asking, which is a much harder problem than the reset itself. Also worth knowing before you scope this: on encrypted machines, most password resets actually get resolved through a recovery-key request, so what you are really automating is letting the right person retrieve a recovery key with an audit record attached.

How you know it worked. Share of resets completed with zero human touch, and the ratio of resets to recovery-key retrievals.

2. Access and permission requests

Recurring, and the answer is usually yes with conditions. Conditions are automatable.

The flow. Request from chat, pick a reason from a short dropdown, get a time-boxed grant that auto-reverts. One team defaults to a 1-hour elevation that expires on its own with no cleanup task for anyone. Keep the reason list short: a team that began with free-typed justifications found people needed only a handful of options, and free text mostly produced the word "work."

The hard part. A justification field is worthless unless a human reads it sometimes. Vague ones need following up on, out loud, occasionally, or the field becomes a click-through within a month. The payoff is the audit record: who granted what, to whom, for how long, and why. Build the expiry with redundancy while you are in there: a local timer, an identity-provider timer, and a periodic check for "you still have admin and your window closed two days ago."

How you know it worked. Standing privileged accounts trending toward zero, and elevation events that carry a readable reason.

3. Software installation and app requests

A self-service catalog is the obvious answer, so I will spend the space instead on a distinction that took a real incident to teach me.

Silent forced auto-updates are correct for background agents, security tools, and monitoring software nobody ever interacts with. They are the wrong choice for always-open applications holding unsaved state: Slack, Zoom, Chrome, Teams. The platform does not check whether the app is currently open before firing the install, and what happens next depends entirely on the installer. Some fail cleanly. Some force-quit the app out from under the person. Some write updated files that do not take effect until the next manual relaunch, so you believe you patched a machine you did not.

I used to push everything silently and privately thought people were being precious about it. Then I terminated a colleague's video call, mid-sentence, with a customer on the other end.

The hard part. Building the taxonomy honestly: which apps are invisible background software, and which ones somebody lives inside all day. Stage every new policy against a small canary group first, and for the always-open ones let the person pick the moment via the catalog.

How you know it worked. Catalog installs rising as install requests fall, and zero reports of an app quitting mid-meeting.

4. Device and asset status lookups

Pure lookup, no judgment, and today it costs a human two systems and four minutes of clicking.

The flow. A self-service view where anyone can see their own assigned hardware. One district built exactly this so students can check what is theirs without asking. The proactive half matters more: automatic notification when a device has not checked in for some number of days, with a link showing live status so the person can confirm it is fixed without contacting anyone. That last clause is the whole trick.

The hard part. Your inventory has to be true. Self-service exposes bad asset data to your entire company at once, which is unpleasant and probably good for you.

How you know it worked. Volume of "what is my serial number" and "is this loaner still on my account."

Printing, which is where the real money is

Every environment I have worked in has one category that dwarfs the others and gets treated as weather. Usually printing.

A campus IT group inherited 150-plus printers across four vendors and multiple legacy print servers, from a merger of five or six smaller IT groups. Naming was inconsistent, so users could not identify which printer was theirs, and the help desk often could not either.

New machine deployments required a technician to manually discover and replicate whatever printer setup existed on the old machine, one user at a time. Jobs printed to the wrong building whenever somebody picked an unfamiliar queue, generating emergency calls to physically retrieve output before the wrong person read it. And during remote work, office administrators were found to be VPNing in and manually relaying print jobs on behalf of professors who wanted output waiting at a specific printer.

That third one is the detail I would put on a whiteboard. Nobody on the IT side had anticipated it. If you do not build the deflection, your colleagues will, and theirs will involve a VPN and a favor.

The flow, in the order they actually did it.

1. Inventory and consolidate every printer, vendor, and queue into a single list.
2. Move printers onto their own VLAN with ACLs so only print servers can reach them. Done before anything user-facing, deliberately.
3. Collapse the user's decision down to essentially two shared queues, color and black-and-white, plus one vendor-specific option.
4. Tap-to-release on every printer, including the single-person locked-office ones. Near-zero exceptions on purpose, because exceptions are what rebuild the old confusion.
5. Zero-touch printer provisioning baked into the standard build, so even a remotely shipped laptop arrives with printing already working.

Result, in their words: this meets 95%, "probably more like 99.5%," of day-to-day printing needs. People who need stapling or collating walk over and use the copier's own touchscreen afterward, an entirely acceptable trade. Hardware came to roughly 150 tap readers at $100 to $120 each.

The line that actually explains the value: the help desk no longer needs to know which printer belongs to which person. This was a five-person team supporting an entire campus, handling 1,200-plus tickets in about a year.

The hard part. Politics, and the exception list. Every locked-office printer has an owner with an argument. Also budget a driver decision: a job that lights up like it is going to print and then produces nothing reliably means driver incompatibility rather than a network or queue fault, and standardizing on the print platform's own universal driver is what stopped those recurring.

6. The one nobody puts on the list: default app associations

A long tail of individually trivial tickets, one shared root cause, all of it preventable in a single sweep. My favorite item here, precisely because it never makes anyone's roadmap.

After an application migration, Office to iWork being the canonical example, every file someone double-clicks keeps launching the old application until something explicitly rewrites the association. Installing the new app changes nothing about existing per-user default handlers. So the tickets arrive for weeks, one at a time, each one phrased as a small personal complaint.

The flow. Read the fleet's current default-handler state before the migration to size the blast radius, then rewrite it fleet-wide instead of waiting for the tickets.

There is a security variant I like a great deal. An organization worried about phishing attachments containing shell scripts that execute on open had .sh and .zsh files default to a text editor instead, turning a potential one-click compromise into a harmless text window. Deflection and hardening in the same three lines.

The hard part, and be honest with people about this. Changing one application's file-type defaults can surface five separate confirmation prompts in a row, one per affected file type. Because the button labels are short, the OS lays two choice buttons side by side on some of those prompts instead of stacked. Someone who has built up muscle memory clicking the "top" button through the first four ends up clicking the wrong one on the fifth. Wrap the sequence in a friendly dialog that says how many prompts are coming.

What I will not automate

• Anything where the person is already upset. Route it to a human immediately, tagged.
• Anything where the correct answer is frequently no. Automated denial is a fight scheduled for later, with worse tone.
• Anything under roughly five requests a month, unless doing it wrong is dangerous.
• The day-one conversation with a new hire. Provision everything automatically, then have a person say hello anyway.
• First-time security reports. Anybody who flags a suspicious email deserves a human thank-you, because the alternative culture is silence.

Measuring this without lying to yourself

Deflection rate is the easiest metric in IT automation to fake, and I have faked it accidentally at least twice. Two failure modes do most of the damage: counting a self-service action the person then filed a ticket about anyway, and counting a drop in tickets that is really a drop in reporting.

Better instruments:

• Volume in the specific category, before and after. Total volume tells you almost nothing, because seasonality eats the result.
• Recontact rate within seven days on anything you deflected. This is the number that catches the split-in-two failure.
• Cycle time on the underlying work, rather than a count of tickets avoided. One district's annual inventory audit went from close to three weeks down to about one week, attributed mainly to input validation catching errors at the point of entry rather than after the fact. Nothing there is a deflection statistic, and it is the strongest evidence in their whole program.
• Direct message volume. If tickets fell and DMs rose, you moved the work somewhere you cannot see it, which is worse than where it started.

The part that is not really about efficiency

Every one of these six is a place where we built a process that requires a person to translate for a machine, and then staffed that translation forever without ever putting it on a budget line. Printing is the clearest case. Nobody chose to operate 150 differently named queues across four vendors. It accumulated across five or six mergers, and a help desk absorbed the difference year after year because absorbing it was possible.

Automation gets sold on efficiency, which undersells it badly. What it buys back is the removal of questions your team should never have had to carry around at all. A five-person team, a whole campus, and not one of them has to remember whose printer is whose anymore.

A better outcome than a faster response time, and much harder to put on a slide.

---

Foqal handles the repeatable half of IT support inside Slack and Microsoft Teams, so the requests that need a human actually reach one.