IT analyst onboarding: how long until they're productive (and why that's a symptom, not a cause)

When a new analyst takes months to become productive on a Service-Desk, the most common explanation a company gives itself is "training needs to improve." In practice, in most cases, training isn't the cause, it's just where the symptom shows up first. The cause usually sits somewhere else: the operational knowledge needed to handle everyday tickets was never centralized in any system, it's scattered across the memory of whoever has been on the team for years.

This becomes visible when you look at what a new analyst actually needs to know to handle a common ticket: it's not just the official procedure documented in the manual, it's the set of exceptions, recurring root causes and workarounds the team has accumulated over time, and that's rarely written down anywhere. A veteran analyst resolves fast because they've already seen that pattern before. A new analyst doesn't have that history available, so every unusual ticket turns into an investigation from scratch.

Gartner has already documented the general size of this problem outside the specific context of onboarding: 47% of digital workers report difficulty finding the information they need to do their own jobs. For a newly hired analyst, who hasn't yet built the internal network a veteran uses to "just ask someone" when the documentation falls short, that problem is even sharper: they don't know what they don't know, and don't know who to ask.

The Consortium for Service Innovation, the organization behind the KCS knowledge management methodology for support, lists reduced training time for new employees as one of the mid-term benefits (9 to 18 months into mature adoption) of centralizing operational knowledge inside the support workflow itself, alongside the 25% to 50% improvement in resolution time the methodology already demonstrates in the first few months. The reason is direct: if the knowledge that today lives inside a senior analyst's head is recorded in a searchable base, the new analyst gets access to that same history of fixes from day one.

That changes what "training" a new analyst even means. Instead of months trying to verbally transfer tacit experience, training turns into teaching the person how to consult and contribute to a knowledge base that already holds most of the answers. Time to productivity stops depending on how many times the new analyst can interrupt a senior colleague, and starts depending on how well-structured the base is that they consult on their own.

That same mechanism is what allows AI agents to take on part of first-line support with real quality: a new agent, just like a new analyst, only performs well if it has access to a history of already-validated fixes. The difference is that, once the base exists, the same knowledge speeds up both at once, the newly hired human analyst and the AI agent working alongside them.

That's why, at Fiscalizei, we treat slow onboarding as a symptom to be investigated, not a problem to be solved with more hours of training. When the Company Brain's knowledge base already exists before a new analyst's first day, what they need to learn isn't "how this system works from scratch," it's just "how to look up what the team already knows," a completely different learning curve.