Avery.Software — Native Execution Runtime
RuntimeUse casesPricingHelpBlog
← All postsBlog

Internal IT helpdesk: where every password reset is on the AI meter

2026-05-28 · Avery NXR

Enterprise IT functions handle a remarkable volume of inbound tickets. A representative midmarket company with two thousand employees generates somewhere between two and five thousand IT tickets per month — password resets, VPN issues, software access requests, hardware problems, account provisioning, mobile device questions, security investigations.

Most of these tickets have, in the past three years, started flowing through AI-augmented workflows. The model triages the ticket, identifies the issue category, suggests resolution steps, drafts a response, and often executes the resolution directly (resetting a password, provisioning access, scheduling a hardware swap). The IT team focuses on the tickets that require judgment; the AI handles the routine work.

This is, on balance, a productivity win. And the cloud LLM bill is real and growing alongside the company.

The math

A representative midmarket company: two thousand employees, four thousand IT tickets per month.

Each ticket goes through several AI operations: classification, customer lookup against the IT asset database, knowledge base search, response drafting, and (for the resolved cases) action execution. A reasonable aggregate token budget per ticket is six thousand input tokens and five hundred output tokens, at frontier pricing about $0.026 per ticket.

Four thousand tickets per month at $0.026 each is $104 per month, or about $1,250 per year, for this company. Small.

But it scales. At a large enterprise — twenty thousand employees, forty thousand tickets per month — the bill is $12,500 per year. At very large enterprises with rich AI integration into the IT workflow, the bill climbs into the low six figures per year.

These numbers are modest compared to other workloads in this series. The case for moving IT helpdesk AI to local inference is less about runaway cost and more about a combination of three factors: operational data sensitivity, fine-tuning quality improvements, and the strategic posture of where corporate IT knowledge lives.

Why this is a strong local-SLM workload

The properties are all present.

The work is narrow. Each company has its own IT stack — its specific applications, its specific authentication systems, its specific hardware inventory, its specific support policies. A model trained on the company's own ticket history and IT documentation outperforms a general model on the company's own work.

The work is highly repetitive. IT tickets cluster heavily into a small number of categories — password resets alone are often 20-30 percent of ticket volume. Specialization on this kind of repeating work compounds aggressively.

The privacy story is real. IT tickets contain a lot of incidentally sensitive information — what software employees use, what systems they have access to, what their hardware looks like, sometimes what they're working on (revealed in the context of why they need a specific access or tool). Aggregated across the company, this is competitive intelligence about how the business operates. Sending all of it to a third-party cloud LLM exposes the kind of operational map a security team would prefer to keep internal.

The brand-voice and tone story matters. IT teams often have a specific tone they use with employees — professional, helpful, sometimes humorous. A general model produces generic IT-helpdesk responses that don't match the team's voice.

The latency story matters when the employee is waiting for a real-time chat response from the helpdesk system.

What the fine-tuned model knows

A model fine-tuned on the company's IT corpus knows things a general model doesn't.

It knows the company's specific applications and the failure modes specific to those applications. "I can't access X" produces different recommended next steps depending on what X is and how the company's specific implementation of X behaves.

It knows the company's specific access patterns. Which teams typically have access to which systems. Which roles get which licenses. Which exceptions are common and which are concerning.

It knows the company's specific security posture and policies. Which kinds of requests require approval. Which require additional verification. Which patterns indicate possible social engineering.

It knows the company's specific knowledge base — the runbooks, the troubleshooting guides, the standard procedures. A fine-tuned model produces responses that reference the company's actual documentation, not generic Microsoft KB articles.

The fine-tuned model is genuinely better at IT helpdesk for this specific company than a general model with retrieval can be.

What changes with local inference

An IT helpdesk workflow on a local SLM looks like this.

A model is fine-tuned on the company's IT ticket history and documentation. The fine-tune is done in a controlled environment that respects the security boundary the IT team is paid to maintain.

The model runs on infrastructure the company controls — typically a server in the IT team's environment. For ticketing tools that support local model integration, the model is wired into the existing workflow. For self-service chat experiences the employees use, the model serves responses through the company's internal channels.

The cost flips from per-ticket to fixed. Employee count and ticket volume can grow without the bill scaling.

The operational intelligence stays inside the company. The accumulated knowledge of how the company's IT operates remains the company's asset.

The audit trail improves. Every AI-handled ticket gets a structured log of what was considered, what was done, and why. For security audits and operational reviews, this is useful evidence.

Where the cloud LLM is still acceptable

A few cases.

For very small companies — say, under a hundred employees — where the IT volume doesn't justify the infrastructure investment. The cloud LLM works fine at this scale, and the integration is simpler.

For brand-new companies without enough historical ticket data to fine-tune on. The cloud LLM bridges the gap.

For specialized one-off troubleshooting that falls outside the patterns of typical IT work. The breadth of a general model helps.

For most enterprise IT operations of meaningful scale, the local-SLM case is strong on quality, on privacy, and increasingly on cost.

The pattern, in IT operations

Avery NXR scaffolds Next.js applications. It is not an IT helpdesk tool. The architectural pattern repeats.

IT helpdesk is a narrow, repetitive, volume-meaningful, operationally-sensitive, brand-voice-relevant workload. The economics that favor a specialized local model for code scaffolding favor a specialized local model for IT helpdesk. The quality improvement story is unusually strong — fine-tuned models produce responses that match the company's specific stack and tone in ways general models cannot.

The IT service management vendors that build excellent local-inference tools — with appropriate fine-tuning on each customer's environment, integration with the major ITSM platforms (ServiceNow, Jira Service Management, Freshservice), and sensible business models — will find willing buyers across enterprise IT functions. The cloud-LLM-default products will hold a portion of the market, particularly at the long tail, but the institutional segment will pivot as the tooling matures.

The pattern continues. IT helpdesk is one of the workflows where the architectural shift is straightforward — the cost case is modest but real, the privacy case is meaningful, and the quality improvement makes the case credible even when the cost alone wouldn't.