

It could have added her in one click. It asked first.
A few months ago, I saw a rant on r/sysadmin titled “I now understand why other IT teams hate service desk.” He wasn’t an outsider taking shots; the redditor had started on a service desk himself, worked his way up to L2 and L3, and only understood the resentment after he’d left.
The complaint wasn’t that the service desk was slow but that it seemed like no work was getting done. When ticket responses are just vague “We did some troubleshooting” and the documentation is full of blurry screenshots (including one, in my experience, where it was clearly someone photographing their own monitor with a phone), it can be quite frustrating. And of course, the number one reason: the habit of handing the problem back to the user without fixing it. All of these ares ymptoms of the fundamental issue: service desk folks don’t have motivation and are largely not competent. Most decent support people leave the service desk as fast as they can because service desk folks get treated like dirt.
This is why this thread stuck in my head. People don’t leave service desks because they’re toxic. It’s because the work is repetitive enough to drive good people out, and thin enough that whoever’s left stops doing it properly.
This is the biggest AI opportunity in an enterprise: AI is remarkably good at doing the routine so that IT folks can focus on more strategic and complex initiatives.
That’s why I decided to take the most ordinary request I could think of and show you how an AI Coworker can handle it end-to-end.
Imagine a new support rep joining the team. She wants to be a part of the distribution list so she startsr eceiving the team’s email – nothing exotic but the kind of request a service desk gets about fifty times a week.
In a world with Atomicwork, she’d ask Atom, our Universal AI Coworker, in Microsoft Teams – the same app she uses to do most of her work and talk to her teammates.
When she submitted a request, the request gets routed to a Office 365 Access Manager which starts work immediately. (As you can see in the video, the Office 365 Access Manager immediately flags that this request is similar to one that I created before – the downside of recording demos).
The Office 365 Access Manager resolves the group name from the ticket live against Microsoft 365 and reported back what it actually found: a real, verified group. However, while the group was public and open for anyone to join, it didn’t have an owner.
This is where all the dumb automations would have just added her to the group and moved on. However, the Office 365 Access Manager realized that this is unusual as per org policy (always ask for approval from an owner while adding someone to a distribution list they own) so it just escalated instead of proceeding.
It checked the group a second time just to be sure there really were zero owners, then set the ticket to Pending, wrote a private note laying out exactly what it found, and reassigned it for an approval decision.
Here’s the part I didn’t expect: because its memory surfaced an earlier ticket, ITSER-12866, I thought it would treat that as precedent and just act. Instead, it named the precedent out loud in its own reasoning, then followed the procedure anyway — because “we did this last time” and “someone approved this” are not the same.
When the request went to an IT agent, they approved it in ten seconds – the only ten seconds of human time that this request required.
The DL Manager picked it straight back up: 21 steps, six tools. Ananya was added to the chennai-support-team distribution list, the membership went active, and email sent to that list now reaches her inbox. Then it verified the change against Microsoft 365 rather than reporting success from its own log.
What it wrote on the ticket afterward is the part I’d show a compliance team. Not a status change — an actual record:
• What was asked, in her own words
• Who it was for, with her email
• What was resolved — chennai-support-team, verified live
• Who approved it — me, by name, with a timestamp, and anote explaining the approval was specifically because the group had no owner onrecord
• What changed — she was added, and the membership is nowactive
• An end status: resolved, approved, executed, verified
Read the rant again with that in front of you. This AI Coworker was able to satisfactorily follow procedure, take notes, suggest the right steps and record the decision in a manner that can be audited even a year later by someone who wasn’t in the room.
There’s a second thing here, and it’s a problem that reaches farther than simple distribution lists.
That distribution list still has no owner. That’s not a small data problem — a group nobody owns is a group nobody’s accountable for, and every person added to it makes that worse. An earlier ticket had already routed around the same gap without anyone fixing it. Now it’s written down, with a name attached, and somebody has to decide who owns that list.
That’s the difference between just closing a ticket and doing the work of running a service desk well. A well-built Office 365 Access Manager, like a senior service desk manager, would be able to identify and escalate this gap as well.
Ananya got her access. It took one approval, ten seconds of somebody’s attention, and a ticket that a compliance team could read back in full a year later without asking anyone what happened. This is the kind of efficiency possible with AI Coworkers – a well-oiled service desk that won’t drown its service desk reps in routine and repetitive work and make them want to run away as far as possible. If your service desk doesn’t have this kind of automation, it might be worth rethinking.
The original rant is worth reading in full on r/sysadmin: https://www.reddit.com/r/sysadmin/comments/1pioxb2/i_now_understand_why_other_it_teams_hate_service/