Featured
Brian King,Richard Mendis
8:00 am, PT, October 4, 2026
Our ITSM platform never lacked data, but it hasn’t always been easy to understand what the data was telling us and what actions we should take next, despite all the time spent building catalog items, interpreting data and usage licenses, and maintaining CMDB health.
This year, my company built a Digital Worker to help our IT team reclaim some of this time and get more value from ITSM investments. We didn’t want it to be a generalized agent, but a solution that can truly understand and execute ITSM tasks that are genuinely affecting productivity and spending because of their complexity and time-consuming nature.
How we built and deployed the digital ITSM worker
We initially developed the Digital Worker in early 2025 using the then-available “browser use” technology, which allowed AI to complete tasks through application interfaces in a web browser. Our goal was to automate implementation and maintenance tasks for ServiceNow and other enterprise applications, giving IT teams more time for higher-value work.
We later evolved the solution to use Model Context Protocol (MCP) to connect to APIs directly and complete tasks faster. We also built our own agentic harness, the software that coordinates how the AI carries out work. The Digital Worker harness supports multiple large language models (LLMs), and combines the model’s probabilistic reasoning with deterministic code for more consistent validation and execution. This combination is what turns a system that can answer ServiceNow questions into one that can perform ServiceNow tasks consistently and reliably.
To make the Digital Worker as useful as possible, we had to teach it how our organization works. Every organization has its own view of what makes a good knowledge base article, what belongs in a catalog item, or how scripts should be named. We think about this like onboarding a new human colleague: Introduce them to the environments, share the team’s best practices, and give them the context they need to do the job well. We used reusable instructions, including SKILL.md files, alongside company knowledge and memory for shared standards and individual preferences. We also taught the Digital Worker to interpret our requirements documents, so it can flag any missing information before it builds anything.
From a security and accountability standpoint, the Digital Worker had to ensure ServiceNow developers or administrators are in control during key operations. A human reviews and approves any write operation before it is executed. The Digital Worker connects securelybased access control and permissions. Update sets give our team a familiar way to move configuration changes through their deployment process or roll back changes
Observability mattered too, so our team can know what the agent did, whether it worked, and what it cost. We use that evidence, alongside testing and checks against real ServiceNow data, to improve the worker and assess its value.
Two things were harder than we expected: Teaching the Digital Worker to interpret the organization’s requirements format reliably, and understanding real implementation pain points, which turned out to be narrower and more repetitive than our roadmap assumed. Both lessons point in the same direction: Start with one workflow rather than a broad ITSM agent. Choose something repetitive, rules-based, high-volume, easy to measure, and easy to reverse.
Once we had our initial version tested, we approached our lean, four-person ITSM team to deploy the solution on a production instance in a pilot program to see how it could help them. Here’s what we achieved and how.
Use Case #1: Reduced catalog item development costs by 80%
It typically takes several hours or days to build a single catalog item, but it could stretch as long as 1 to 2 weeks, depending on complexity. Most teams capture catalog item requirements in some sort of standard format, whether that’s on Excel, Word, or a Jira ticket. Once the requirements are gathered, they have to be handed off to a developer who interprets them, creates the variables and form fields, builds out the workflow, and potentially develops additional scripts and SLAs. Doing these repetitive tasks that require a high level of attention to detail and understanding of the platform absorbs much of the IT team’s time and resources.
Our Digital Worker is modeled after the conversational capabilities of an LLM and also understands our organization’s specific requirement formats and best practices, making it easy to navigate, ask questions, and complete tasks. It also follows permissions, so users can only make changes they would already be authorized to make within the ITSM platform. By prompting the Digital Workerand being able to upload requirements in our standard format, it can create a catalog item in about 20 seconds, including the workflow and associated scripts. The team can then preview the result, such as a request form, before even leaving the Digital Worker and, once finalized, move it into the platform in just a few clicks.
Using the Digital Worker’s catalog-building capabilities has been a game-changer for our lean team. When we go into the requirements-gathering phase, we can fill out the same template just like we did before, but now we can just activate the catalog builder right on the spot and see results almost immediately. That saves us several days on a basic catalog item, or up to a week for more complex workflows. It also means we can review the result with the requester, make adjustments, and test ideas much faster instead of moving through a lengthy back-and-forth development cycle.
Use Case #2: Moved beyond dashboards to find and act on ITSM issues faster
Another area where we deployed the Digital Worker is request and incident trend analysis. There are always insights you’re trying to get from the data in your ITSM platform. Traditionally, that means building reports and dashboards, looking through lists, and sometimes reviewing individual tickets. You can build as many dashboards as you want in an ITSM tool, but getting to actual insights is much harder and more time-consuming.
Interpreting static dashboards and having to scrub through lines and lines of tickets in a report is now a thing of the past. The way of the future is being able to ask questions and receive answers and insights quickly from conversational AI.
For example, we can ask the Digital Worker to analyze the last 60 or 90 days of incidents and requests. It immediately compares current volumes against a baseline so we can see whether activity is trending up or down and where something unusual may be happening. It also uses machine learning to cluster tickets and identify keywords, topics, and recurring issues that may be spiking. So instead of seeing a chart of tickets by priority, we might immediately see clusters of tickets around backup failures, replication lag, performance, or connectivity.
We can then drill into any one of those areas conversationally and ask, “What’s driving this?” or “Where should we focus?” The Digital Worker interprets the underlying data and tells us what is actually going on. A dashboard can tell you that ticket volume increased, but aDigital Worker can tell you why it increased, identify multiple tickets that may stem from the same underlying issue, and recommend what to do next. This helps us address issues earlier and focus our resources where they have the greatest impact.
Related to this flow, getting subject matter experts to create knowledge articles that help defray tickets is a constant challenge due to limited bandwidth. When the Digital Worker analyzes ticket and incident trends, it can also determine if there is a knowledge article gap and actually help draft the article on the spot by synthesizing the related incidents and any other related data.
Analysis that could previously take several hours can now be compressed into a 10- to 15-minute conversation with the Digital Worker, and recurring analyses can be scheduled to run periodically. We’re spending less time building dashboards and manually interpreting data, and more time acting on the underlying issues that the data is surfacing.
Use Case #3: Optimized user roles and reallocating premium licenses that are unused
Historically, our team has spent a lot of time building dashboards, reviewing compliance reports, and trying to reconcile differences between what we were seeing internally and what the compliance reports showed. It was a very reactive process. When a report identified an overage, our team had to investigate to determine why their data was so far off from what we had built into our reports. Sometimes, ServiceNow changes role definitions, and keeping up with those is a real challenge. Many organizations only conduct a detailed audit once a year (if they’re lucky), because analyzing user roles and activity across the platform takes so much time.
Using the Digital Worker, we can look at an individual user’s roles and see not only when they last logged in, but how they’re actually using the capabilities of those premium roles. For example, if someone has an ITIL license but isn’t using change management, incident, knowledge, problem, request, or service catalog capabilities, we can determine whether that license is still necessary and potentially reclaim it for someone else. And we can do the same analysis across an entire team. Instead of reviewing users one by one, we can ask the Digital Worker to analyze a group and show us how licenses are distributed, which entitlements people have, and whether they’re actually using them.
It seems like there’s always a request for another license. Without this visibility, it’s easy to over-allocate licenses and drive up costs unnecessarily. Now, we can make smarter decisions about how licenses are allocated, which helps avoid unnecessary cost creep.
ITSM systems have traditionally been a system of record: Very good at capturing data, but requiring lots of time and expertise to interpret that data and turn it into action. With the Digital Worker, there is an opportunity for a layer of <a href="https://bitcomme.com/better-artificial-intelligence-stock-alphabet-vs-meta-platforms/” title=”Better Artificial Intelligence Stock: Alphabet vs. Meta Platforms”>intelligence that can help our IT teams do a lot more in less time and get more value out of our ITSM platform investment.
Experimenting with conversational AI has allowed our team to spend less time navigating dashboards, analyzing records, and performing repetitive administrative work, and more time acting on what the platform is telling us so we can ultimately improve operational efficiency and serve our internal customers better.
Richard Mendis is a Chief Marketing and Strategy Officer.
Brian King is a Senior AI Product Engineer atBytemethod.ai.
Welcome to the VentureBeat community!
Our guest posting program is where technical experts share insights and provide neutral, non-vested deep dives on AI, data infrastructure, cybersecurity and other cutting-edge technologies shaping the future of enterprise.
Read morefrom our guest post program — and check out ourguidelinesif you’re interested in contributing an article of your own!
