Freshworks Targets the 47% of IT Tickets Filed After Hours

AI 요약

• What happened: Freshworks announced Freddy AI Agent Studio for Freshservice, plus MCP Gateway, AI Insights, and xLA.
  • The announcement landed on May 14, 2026, at Freshworks' annual Refresh conference.
• Key number: Freshworks says 47% of IT tickets are submitted outside standard business hours.
  • That statistic frames agents as an asynchronous service-operations layer, not just another FAQ bot.
• Why it matters: ITSM is becoming the runtime where agents pass through identity, context, execution, and measurement.
• Watch: The success metric should include the human workload left behind by failed automation, not only the number of automated replies.

Freshworks expanded Freddy AI Agent Studio for Freshservice at its Refresh conference on May 14, 2026. At first glance, the announcement looks like another no-code AI agent builder attached to an IT service management product. That reading is too small. Freshworks is not only adding a chatbot interface to Freshservice. It is trying to make ServiceOps itself the execution layer for enterprise AI agents.

The official Freshworks announcement starts from a very practical employee-service problem. Based on its own analysis of service interactions, the company says 47% of IT tickets are submitted outside standard business hours. Work has become more distributed and asynchronous, while employees ask for help through Slack, Teams, portals, and email. Traditional ITSM operations still often depend on humans watching queues during office hours, classifying requests, checking permissions, opening another system, and recording the result. Freshworks calls that gap the "ghost shift."

That number is useful because it points to a real deployment pattern for agents. Many enterprise AI launches still stop at "an employee asks a question and the assistant answers." But an after-hours account-access request, onboarding checklist, payroll-change issue, laptop replacement, or incident notification rarely ends with an answer. The harder questions are which system the agent can access, which identity and permissions it can use, where the result should be written, and when a human should take over. Freshworks packages that problem as AI Agent Studio, MCP Gateway, AI Insights, and xLA.

More than a no-code builder

The first part of Freddy AI Agent Studio is familiar. Teams can create custom AI agents in a no-code studio or start from prebuilt domain agents. Freshworks says those agents can receive requests in Microsoft Teams, Slack, and employee portals, then connect to HRIS systems such as Workday or Rippling to handle secure workflows for onboarding, payroll, and similar service operations.

That direction is not very different from what ServiceNow, Atlassian, Microsoft Copilot Studio, and Salesforce Agentforce are all describing. "Business teams can build their own agents" has become standard market language. So the more important question is not whether Freshworks has an agent builder. It is where that builder sits.

Freshservice already contains tickets, assets, incidents, service catalogs, knowledge bases, and approval flows. Inside many companies, that makes it one of the most structured records of internal work. It knows who asked for which service, which asset or business unit is involved, which department needs to approve the request, and how similar issues were resolved in the past. An AI agent that wants to do real enterprise work needs exactly that kind of context.

Freshworks' real message is therefore closer to "Freshservice becomes the work state store for AI agents" than "Freshservice now has AI." An employee request enters as a ticket. The agent reads policies and data, calls outside systems, routes approvals, and writes the outcome back into service records and metrics. This is not AI that disappears inside a single chat window. It is AI whose work remains inside the operational system.

Why MCP Gateway matters

The most developer-facing piece of the announcement is MCP Gateway. Freshworks says Freddy AI can pull context from external tools such as Notion, ClickUp, and Linear. Freshservice support material also describes a Freshworks MCP server that connects Freshservice securely with AI tools such as Cursor, Claude, and Microsoft Copilot Studio.

MCP has quickly become a candidate standard for connecting agents to tools. In an enterprise setting, however, leaving MCP access open is risky. Someone has to manage which tools an agent can call, which account it uses, which data it reads, what gets logged, who approves risky actions, and how failures are audited. That is why "gateway" is showing up so often in enterprise AI product language. Better models do not remove the need for a control layer around tool use.

Freshworks' MCP Gateway fits that pattern. If company policy lives in Notion, engineering work sits in Linear, task planning happens in ClickUp, and employee requests are managed in Freshservice, an agent needs to read across those systems. For example, a new hire's access request could require checking employment status in an HRIS, matching assets in Freshservice, reading a security policy in Notion, considering project assignment in Linear, and then starting the right approval flow. The key is not just connection. It is controlled connection.

That puts Freshworks in the same broader conversation as UiPath and Red Hat, even though the product category is different. UiPath is putting coding agents inside an enterprise automation platform and emphasizing deployment and auditability. Red Hat is talking about local agent sandboxes and hybrid-cloud development tooling. Freshworks is choosing ITSM and ESM as the execution layer. These announcements all circle the same question: when agents touch real systems, where is execution authority governed?

From SLA to xLA

AI Insights and xLA are just as important as the builder. Traditional ITSM is comfortable with SLA metrics: response time, resolution time, breach rate, and similar operational measures. Freshworks is adding xLA, or Experience Level Agreement, to connect service performance with the employee experience.

That shift matters more in the agent era. Automation can make surface metrics look better. First response time can drop to nearly zero. Ticket classification can happen immediately. But those metrics do not necessarily show whether the employee's problem was actually solved, whether a bot repeated the wrong questions, whether the handoff left a longer transcript for a human to decode, or whether a specialist had to redo the same diagnostic work after an automation failed.

Freshservice community discussions already show this risk. One user reported that after adding Freddy AI, tier-1 MTTR did not fall and instead appeared to rise. If a bot tries, fails, and then hands the issue to a human, the support agent has to reread the entire conversation before doing the real work. Automation happened, but the human workload may not have gone down.

That is why xLA should not be dismissed as marketing language. The success of AI agents in service operations depends less on "how many replies were automated" and more on whether people waited less, rework decreased, handoffs became more accurate, and failed automation improved the next attempt. Freshworks is emphasizing AI Insights because once agents start doing work, agent work itself becomes something operations teams must measure.

Freshworks is aiming at legacy ITSM

Freshworks repeatedly contrasts its approach with legacy platforms and long data-cleanup cycles. The argument is simple: in a complex ITSM estate stitched together from multiple tools, an AI agent may not have enough reliable context to act. Freshservice, Freshworks argues, can give agents a unified layer across services, assets, knowledge, and incidents.

That message points directly at ServiceNow and Atlassian. ServiceNow remains the heavyweight in enterprise ITSM and is moving in the same direction through Now Assist and AI Agent Studio. Atlassian is connecting developer, service, and knowledge data through Jira Service Management and Rovo. Microsoft is using Copilot Studio and Teams to capture business automation. Glean is talking about an Agent Development Lifecycle from the enterprise-search side.

Freshworks' differentiation is simplicity, price, and deployment speed for teams that do not want a multi-quarter transformation project. The official launch material uses the phrase "weeks, not quarters." The promise is that teams can build domain agents on top of existing Freshservice data instead of spending several quarters redesigning processes before AI becomes useful.

That promise cuts both ways. Fast deployment only works when the underlying data quality and permission model are good enough. If ticket categories are inconsistent, asset inventory is stale, or the boundary between HRIS and ITSM responsibilities is unclear, an agent can make the wrong move faster. MCP Gateway increases the stakes. More connections bring richer context, but they also bring more ways for stale context and excessive permissions to enter the loop.

What builders should take from this

This announcement is not only an IT operations story. It sends three signals to teams building AI products.

First, agent products are becoming less differentiated by model choice and more differentiated by how deeply they sit inside work systems. Freshworks is not leading with a proprietary frontier model. It is talking about Freshservice data, MCP Gateway, Slack and Teams surfaces, HRIS integrations, incident workflows, and measurement. For many enterprise customers, that is the more direct value.

Second, MCP is moving from developer convenience to enterprise governance. Connecting an MCP server to a local coding tool is one thing. Letting an employee-service agent read company data and trigger actions through an MCP Gateway is another. AI platform teams will need to design permissions per tool, call logs, approval policy, data classification, and rollback paths. A list of available MCP servers will not be enough.

Third, agent adoption metrics will merge with operational metrics. Coding agents are judged by test pass rate, pull request merge rate, review cycles, and deployment outcomes. Service agents will be judged by MTTR, reopen rate, employee satisfaction, SLA or xLA, and human intervention rate. "The AI answered" is a weak metric. The stronger question is whether the AI closed the work loop.

Open questions

Several important details remain open. How granular is the MCP Gateway permission model? How does Freshservice record data that an agent reads from an external tool? What level of audit logging and replay exists for failed actions? Can customers choose or restrict the LLMs behind these workflows? Those are implementation details, but they will decide whether the product is safe enough for real service operations.

Human approval is another unresolved point. Payroll, access control, equipment provisioning, and incident response are all sensitive workflows. It matters whether the agent only prepares a draft for human approval, whether low-risk actions can execute automatically, and whether policies can change by risk level. Freshworks uses language such as secure enterprise workflows and controlled orchestration, but buyers will need to inspect the product documentation and actual deployments to understand the control surface.

The 47% after-hours ticket number is a strong problem definition, but it is not proof that agents can solve the problem by themselves. A high volume of nighttime requests shows automation demand. It does not mean every nighttime ticket should be automated. Some requests only need policy lookup. Some are security exceptions. Some require human judgment. A good agent platform has to separate those categories instead of treating the queue as a single automation target.

Freshworks' launch is another sign of where enterprise agents are landing. Models keep improving, but business work finishes outside the model. Tickets, assets, incidents, HRIS records, collaboration channels, approvals, and metrics all have to connect before an agent becomes an operator rather than an answer bot.

That is the significance of Freshworks AI Agent Studio. It is not only a new feature inside Freshservice. It is Freshworks positioning ITSM as the place where agents work the night shift. The competition is shifting from who has the smartest bot to who can provide the safest, most measurable loop for real work execution.