Agentic Service Management: Moving Beyond Tickets to Outcomes - Gurudutt RV

This talk by Gurudath explores the concept of agentic service management, which shifts the focus from traditional ticket-centric systems to a more proactive, outcome-driven approach. The speaker discusses how employees now demand instant assistance, necessitating a transformation in service management practices. Agentic service management incorporates AI technologies that enable help seekers to receive context-aware support more efficiently. The workflow includes multiple AI agents that analyze ticket information, generate action plans, and perform tasks autonomously with minimal human intervention while ensuring a supervisory mode to build trust. Looking ahead, Gurudath emphasizes the move towards completely autonomous execution of service tasks, aiming to enhance customer experience by reducing response times and improving overall service delivery metrics.

My name is Gurudath. I'm here to talk about how agentic service management looks like and uh the direction in which we are moving towards. Uh So, uh for several years, service management has revolved around creating tickets. So, someone runs into the issue, uh files a ticket, and then someone is looking at a queue, assigns it to themselves, resolves the ticket, and then we are done. But, the

world is changing. Employees expect uh instant help. Businesses want to move faster. Teams are under pressure. So, we want to be moving towards a different world. And that's where agentic service management comes into play. Now, um agentic service management is the traditional service management has always had ticket at the center of uh uh the universe, right? But, agentic service management is more around how do you influence

outcomes? So, typically, uh this is the anatomy of uh the agentic service management. You have a help seeker who is requesting for help. Uh then you have AI that is able to use the context in the ticket, reason, it creates plans, clarifies, and it basically is able to deflect or resolve a ticket, right? Um while it is doing this, it's also continuously learning and feeding it back

into uh the overall accuracy improvement. And then you have service leads, whose role now shifts from just monitoring the queues, making sure CSAT scores are swell. They're now moving on to build uh prompts, customize the outcomes of the agent itself, and how do you improve the overall efficiency of the platform? And then you have the orchestration layer that acts as a reasoning platform that fetches the enterprise

context, enables automation, and helps with decision-making, and also has long-term memory at the core of it. So, this is a typical workflow. Um you start with a ticket. That part of it hasn't changed yet. And I say yet because it will change in the future. Then you have what we call as our raw raw service agent, which is our AI agent. Underneath it is uh multiple different

agents working together, but that's the wrapper that we call it as, which looks at the knowledge base, gets all the context from the ticket, understands the user, their location, where they're coming from, which department, who's the manager, and then it looks up the relevant knowledge base. It searches the enterprise database to fetch the relevant knowledge, and it passes to the planning agent, which is now responsible for

creating an end-to-end plan. A plan is um nothing but a series of steps which a human would execute otherwise, and it sort of pauses for the humans to come and approve it. And that's the the initial phase we are in right now, where you want to be able to gain confidence and build trust with the humans. Now, once you have the plan and the human approves it,

it is able to go ahead and execute the plan. So, typically, it either delegates it to an end-to-end agent, or it ends up resolving the ticket itself. ServiceNow has multiple layers. Um it has an L1, L2, L3, uh each increasing in complexity and the type of tickets they handle. And if the plan at any point in time if the agent realizes that it is unable to execute,

it will hand it off to a human agent uh right now. So, let's take a real-world example. Meet uh Bella Adams, who's a UX designer at Atlassian. She has a marketing meeting to get to and she wants to prepare uh some Figma uh diagram, right? She wants to work with other designers and uh she needs Figma access as a first step. What she does is she's she'll

go to uh the request form, file a request. It's a simple form. Uh this passes This part of the puzzle hasn't changed yet. Uh so, she says, "Look, I need Figma access. I'll need uh to create a creator access, which is a very specific type of access. You might have a read access, a temporary read access, a permanent read access, or a creator access, which is the

highest level of access." Our second persona is Robbie, who's the service agent, who's responsible for resolving this ticket. In the traditional sense, Robbie would have looked at the ticket, went ahead and done a bunch of things, and helped Emma get the access to uh Figma. But, in this case, he continues the first step, uh goes into the ticket view uh or the queue view, uh I beg

your pardon, where he notices that there's been a request now which has been assigned to him. Now, the third and the most important persona is the lower service agent. This is not a chatbot. It is a complex orchestrated steps of agents which is able to talk to each other. And like I said before, it does a bunch of things. It's able to glean into the ticket context,

understand the user's persona. It's able to understand location, whatever context it's able to fetch. It can connect to assets databases across enterprises to fetch what sort of laptop a person is using. It gets all that information. It is able to perform an enterprise search. It It then goes ahead and creates a plan. It is able to wait for inputs from a user and it subsequently is able

to connect to multiple different first party and third party connectors to execute an action. while Robbie opens the ticket, you notice that on the right hand side, the raw service has already started thinking. In the background, it is performing all the steps that I just spoke about. it then goes ahead and you can see it is creating a plan now. So, this is what a resolution plan

looks like. It is a series of steps which Robbie otherwise would have performed manually. If you notice, it has um basically, it shows progress. It shows the sequence. It is able to tag people that it should be responding to. And then it has a review and assign button. So, right now, in in the initial stages of AgentX service management, we are working on what we call as

a supervisory mode because we want to build trust with enterprise customers. We want them to believe that AI is safe to use. And that's why you see a review and assign. So, Robbie clicks on it. And he ends up on this page which is a much more detailed plan of a version of the plan, right? So, you see that it has a complete tree of the decision

that it has made and you are able to look at each and every step verify if the AI has figured it out. Now, Robbie notices that there is a particular step that is missing. What they do is they go to the chat interface. They realize that first before granting an access, they would like to check if Bella has ever had access to Figma in the past. Because

depending on that decision, you could end up taking a different action. You could probably renew an existing license or you could provision a new license. So, Robbie says, "Look, hey, why don't you add this step? Because this is something that maybe you were not able to identify or it that was a step which was missing from the knowledge base." it So, if you notice Rover Services trying

to understand the request now, and then it ends up adding that And it also knows where exactly to add. You can tell Rover Service that I want to modify the third step. I want to add a seventh step in this particular branch. It's able to identify all of that. Now, Robbie is happy with the plan. He goes ahead and assigns the ticket to Rover Service. So, Rover

Service starts the execution. You could notice that with the the green tick mark against the step that is already executed. You also notice a red color stop button over there. That's primarily a a user interface to let the human agent pause the plan, stop the execution at any point if they want. They don't want AIs to be executed executing unintended steps, and we want to make sure

humans have complete control over it. what Rover Service does is while it is executing a plan, I would like to draw your attention to the fact that it is a complex series of steps. Now, it has realized that if I were to give Bella access to Figma, I first have to get an approval from her manager. And you'll notice that it is commented on the ticket. It

has tagged Bella's manager, Bradley. And it is requesting him to approve. While this is happening, Rover Service actually waits, puts the execution on hold. It's able to wait, pause execution, and do these complex operations. Bradley has come here and approved. He obviously got a notification from the Jira ticket that he has been tagged. And he's come here and approved the Or approved the access request. once he

approves it, we keep waiting for the event. And uh the Rover Service is able to now validate the approval. And it also obviously checks whether Bradley is indeed Bella's manager or someone has accidentally approved a ticket. It's able to validate all of that. And it goes ahead and provisions the Figma the Figma access itself is a series of API calls. What's happening under the hood is there

is a supervisory agent, which is responsible for uh your search, rather architecture, plan generation. And it is able to basically now delegate the access request provisioning to a task agent. So, you will end up having a Figma task agent, which obviously corresponds in a natural language. And when the supervisory agent passes on the natural language instructions, the task agent is able to decipher that. And it fires

a series of API calls to provision the access. Now, once the access is provisioned, Bella is notified. Uh she comes and confirms that she has access. And Rover Service goes ahead and uh closes the Now, what's next for us? Basically, we are in the early stages. This is just the early peak into how enterprise agentic service management is evolving. The most important step as the next step

for us is autonomous execution. So, if you noticed so far we have been in a supervisory mode where human was in the loop at throughout the execution. They don't have to sit and monitor, but they obviously in the initial phases they want to build confidence. They keep watching over what the AI is doing. But once we build enough confidence, we already have this capability, but we are

trying to build trust with our customers where we should be able to execute steps end-to-end without any human intervention. So, it picks a ticket, it's able to uh get all the context, it's able to generate a plan. It will then go ahead and resolve this ticket autonomously. The way to do it successfully is to have a very high degree of thresholds for uh you know, for any

errors that can happen and high degree of confidence on the AI. So, it will hand off to a human if it is doesn't have confidence on the plan. So, that's the way autonomous execution evolve. And then we want to obviously simplify onboarding, make sure that it's easy for customers to use over service agent. We want to have ROI dashboards where value of this proposition is clearly called

out. They would want to look at cost savings, they would want to look at velocity, they kind of CSAT scores because the faster obviously agents are faster, they're able to uh you know, resolve tickets faster, so it will improve the CSAT scores. And we want to move away from a ticket ticket-first approach to a ticketless agent service management. Last but not the least, there are two important

We want to make sure that the knowledge base is self-healing, it continues to progress and improve itself with some help from the customers. So, human's role will evolve from resolving a ticket to making sure that you are upgrading your knowledge base so that the repeated tasks are automated in a high highly accurate fashion. the future of enterprise service management. So, like I said, um service management has

been reactive so far. So, there is a ticket always and then everything keeps starts from there. We want to move away from that. We want to have a proactive service management which means eventually if there is a VPN issue on your laptop, we should be able to detect even before it happens. We will be monitoring the signals. We'll make sure that we have an agent which will

resolve or tell you to do a series of steps before the issue uh crops up. work begins only after ticket is created. Like I said, um we want to make sure that it is preventive and not reactive. And the the whole measurement of KR's and success metrics will move away from the number of tickets that is being resolved to what are the outcomes we were able to

achieve and how fast are we able to deliver that. So, right now AI for the last 2 years has been acting as an assistant and that is going to evolve where AI will be at the front and center of the end-to-end resolution itself. Humans today like I said in the in the workflow that I just walked through has to do proactive actions. But, the future of AI

agentic service management in the in the next 6 months to 1 year will be will evolve around AI requesting for human review only when required. Otherwise, it is able to do a lot of things by itself. obviously, the business focus will move away from workforce management, queue management to delivering business outcomes. And that's all I had for today. Thank you. >> [music]