When this client first came to us, their pitch was ambitious: automate the entire internal IT help desk. Password resets, software requests, hardware issues, onboarding questions — all of it. We pushed back on the scope before we pushed forward on the build, and that decision turned out to matter more than anything we shipped.
Why we narrowed the scope first
A department-wide rollout sounds efficient on paper, but it means mapping dozens of loosely related workflows at once, each with its own exceptions, before anything ships. In our experience, that approach produces an agent that's shallow across everything and genuinely reliable at nothing — because there wasn't time to properly map any single workflow to the depth it needed.
Instead, we asked their IT lead a simple question: which single type of request eats the most time relative to how repetitive it actually is? The answer was password and access resets — not the most frequent ticket type, but the one most reliably interrupting someone's focused work for a two-minute task that followed the same steps almost every time.
What mapping that one workflow found
Even a "simple" reset workflow had branches nobody had written down: different processes for a forgotten password versus a locked account versus a departed employee's access needing revocation, different approval requirements depending on which system was involved, and an escalation path for anything touching finance or HR systems that needed a human sign-off regardless of how routine it looked.
Mapping that one workflow in detail — not the whole department's ticket queue, just this one process — took a few focused sessions with the two people who actually handled resets day to day. That depth is what a department-wide first pass would have skipped entirely.
What changed after launch
The agent now handles the large majority of routine reset and access requests directly, with clean escalation for anything touching a sensitive system. IT's reported interruption volume for this specific ticket type dropped substantially within the first month, freeing up meaningful focused time for the two staff members who used to context-switch into these requests dozens of times a week.
Just as importantly, nothing broke in an embarrassing way. Because the scope was narrow, the edge cases were genuinely covered before launch, not discovered live. The client's IT lead has since asked us to map a second workflow — software license requests — using the same narrow, deep approach, rather than trying to fold it into a broader rollout.
The lesson that generalizes beyond IT
The instinct to automate broadly is understandable — it feels like the ambitious, efficient choice. But a single workflow mapped properly and handled reliably builds more trust, and more actual time savings, than five workflows handled at 60% confidence each. We'd rather ship one thing that works completely than five things that mostly do.
How we measured the impact
Before launch, we asked the two staff members handling resets to log a week of tickets with rough time-to-resolution for each, giving us a real baseline instead of a guessed one. After the agent had been live for a month, we pulled the same measurement and compared it directly against that baseline, rather than relying on a general sense that things felt better.
That before-and-after comparison is something we build into every case study, not just this one, because "it feels faster" isn't a number a client can take to their own leadership to justify expanding the project. Having an honest baseline also protects against the opposite outcome — if a workflow doesn't move the needle, we'd rather know that clearly and adjust than quietly call it a win.