Transcript
First of all, thank you so much for joining this session. I'm very, very happy to have you all here. And I'm very excited to be able to host all of you folks for the session on basically boosting your process efficiency with our all new Unified Runbooks. So I'm also very excited to basically talk about how you can leverage these Unified Runbooks to basically design, take all of these processes that you have and design like very clear, very actionable processes that can help your team close tickets very quickly with speed and clarity. So before we get started, I just want to start off with a very quick intro to SuperOps, just to give a little bit of context to all of the new folks who've joined in on the session, just to give them a bit of insight in terms of who we are, what we do and what we want to achieve in this IT management landscape. So just to start with, we just want to take a short look at the MSP and IT landscape as a whole. The bottom line, essentially, is that a majority of it is still stuck in the past. A lot of innovation over the years meant that there are a lot of things that MSPs and IT teams have to deal with, especially when you look at the tools that are out there, they're slow, they're clunky, the interfaces are really dated. And all of these individual everyday operations that you're used to just require a lot of manual effort and they're not exactly reliable and they just keep breaking frequently. These are all of these issues that basically build a lot of frustration over the time, but they don't really have a reliable alternative on the other side. So that's basically what we set out to change, to basically help MSPs and IT teams break away from the current landscape of legacy tools and replace them with a more powerful, more modern, and a more unified platform. So that's basically where SuperOps comes in. In a nutshell, SuperOps is a truly unified PSA RMM platform that's thoughtfully designed to make the modern MSP and the IT pros there. So when you look at it from a unified perspective, it essentially has all of the major tools that you need from, say, ticketing to your project management, all the way down to your invoicing, your contracts, and your IT documentation. And the best part about it is that it all comes in a single pane of glass so that when you have to look at driving your everyday operations, you're able to basically execute and excel at all of those in one place. So that is the kind of unique value proposition that SuperOps offers. And today, our focus is on a very specific segment that's focused on your service operations, which is your ticketing playbooks and your processes. So currently, when you're looking at how you're handling your process documentation and all of that, your SOPs are, how do we put it? You do have to live with them, but you also can't really live with them that easily, primarily because they're cumbersome, they don't really give you any actionable guidance in terms of they tell you what to do. But beyond that, it's completely up to you to figure out the nuances of how that process is run. So even when you look at the industry, predominantly 70% of MSPs and IT pros still use IT documentation tools to basically rely on all of their process guidance and orchestration. But eventually, when you're digging a little deeper, you're able to see that there's no exact structured guidance to this process where they are tasks, they are process documents in isolation, but there's no actionable or automated angle to it. So what happens is it really does leave you in a silo of having to figure out things for yourself. And when you're looking at the market as a whole, the market isn't really paying attention to all of these things either. So what happens is when we also looked at what sort of offerings other players in the market could empower your technician to do. So when you're looking at Synchro, they have basic checklists, but that's about it. Attera, as far as we could see, they offered no solution to basically streamline this sort of SOP efficiency or optimization. And Halo again has tools, but they lack any sort of deeper focus on any sort of automation or flexible orchestration. So what we also realized was that all of these tools really did just scratch the surface of what was possible in that space. They just help you document all of this information, but never really help you put them to action. So that is kind of where we figured that there was a bit of an area of opportunity in all of this. So when we saw the whole space, we realized that there were three areas of opportunity where we could really step in and transform the overall SOP landscape. That meant that we could basically make all of these SOPs actionable at the very first step where these SOPs weren't just telling you exactly what to do, but they helped you actually do it as well. They were right with you every step of the way. They were telling you exactly, hey, you should probably take this first and follow up. And if you need context, this is what you have. Making it actionable and bringing it very close to your workflow felt like a very critical step that was already missed. And on top of that, when you're taking it a step further, you're able to see that once you put it to action, the system can also take a deeper look and say, all of these things are now orchestrated. Within these orchestrated steps, what can I automate? What can I take off your plate? That is the second step that we wanted to look at in terms of being able to reduce the amount of manual effort that technicians had to go through, even with any sort of well-documented everyday operations that they were going through. And on the third step, how do we basically bring the power of the entire platform into this and how do we integrate it so that all of it comes and plays a small integral role into helping you close tickets faster? And that was a sort of advantage that we realized that Super Ops was in poor position to give and that other players in the industry weren't really pleased to do. So we realized that we had a unique advantage in this space. Essentially being a unified platform, we realized that we could double down on this advantage. So that's kind of where we wanted to head. And that's what led us to basically unveil our brand new runbooks. So essentially, this is what we had in mind, especially when we built unified runbooks. We wanted to help you bring your processes to life, speed up all of your ticket resolutions, unlock a whole lot of productive technician hours for your team, increase efficiency and essentially just impress your users and customers. So that's kind of what we set out to do. And that's what we feel that it will empower for you as well. So when you look at, especially with unified runbooks, what you realize is that you have a very powerful framework that lets you build out all of these complex workflows in a very, very short amount of time. You're able to see go through pages and pages of SOP documentation. But what this allows you to do is basically lets you visualize that entire process and it lets you put all of that down so that it also helps you optimize it while you're building that workflow. And on top of that, what it brings to the table after that, it basically brings it right within the ticket so that you don't really have to keep context switching or keep juggling between tabs every single time so that when you're right within the ticket, when you have to figure out what you have to do, you're completely focused on resolving that ticket and you're just moving on. And on top of that, you're basically able to start automating things and basically you're saving chunks of time here and there. And down the time, it just nobles and it adds up into a remarkable chunk of time that basically translates to a whole lot of productive and revenue making opportunities down the line. So this is basically all of the great things that we basically set out to do when we built the Unified Runbooks segment. So for the next step, what I'm going to do is basically I'll be passing the mic on to Akhilesh, our product manager for the PSA side of things. He's the brains behind this entire feature. So he's going to be walking you through the entire product deep dive of the feature, what he envisions for the future down the line, and a whole lot of use cases where he thinks that it could really shine. Right. Over to you, Akhilesh. Perfect. Thanks, Manish. And hey, all. So like Manish mentioned, I'm Akhilesh, product manager for everything PSA here at SuperOps. And I'm really excited about talking about the Runbooks that we have launched today. And for the customers who are on this webinar, who has been with us for a while, you would have seen a different version of Runbooks, which we had previously. But this is a complete revamp of what we had in place. And Manish pretty much set the scene and why we did what we did. But however, one of the fundamental reasons, maybe from my point of view, I also wanted to share, is what is making you choose SuperOps as a platform? The fact that it's a unified platform, and maybe you're getting it for, let's say, operational efficiency so that you can improve your bottom line, improve your client satisfaction. And all of this actually requires making sure that you're able to get more things done faster. And that's exactly why you're coming to a unified tool in itself. But however, when we analyze the market on, are the unified tools delivering this value at all? We still realized inside a unified tool, even still agents or, let's say, technicians are getting lost. They are doing multiple, let's say, steps to get one thing done, or let's say, still end up using separate IT doc and multiple systems to refer what they have to do in the unified platform as a separate documentation in itself. And we wanted to save all these to and fro. And the thought process was, how can we ensure every MSP who's looking to invest in a unified solution to make sure that they drive operational efficiency and profitability? And they are able to feel that impact from day one. That's SuperOps' answer by launching the unified runbooks, where from day one, you will find the value of why you should be on a unified platform that's going to drive operational efficiency and client satisfaction. And the screen that I have here is kind of a nice layout of one of the most used use cases for runbooks is a user onboarding. And this is how it will look like. Of course, I will definitely get into the details of it. How do you build a runbook? How do you use a runbook, et cetera? And I will step into the shoes of multiple people in your own business. For example, let's say I am a service desk manager or an owner, and I wanted to ensure that my technicians do not, let's say, most of the time in the world of IT, things are very predictable and what happens. And you can also constantly keep building this runbook as a repository so that when you know that, hey, if this kind of a ticket comes in, this is what my technician is supposed to do. Now, this is how you would go ahead and build a runbook. So a quick view into how a plain canvas would look like. Now, let's say I'm just going to build a runbook for, let's say, server troubleshooting. Just a sample that here. And I go ahead and say, create and give it a description. Now it's just saying, select an action. That's how you start creating a runbook. And the reason why we call it an action is all of these are actions that ideally a technician would perform to get a job done in a unified platform. And how can they get to it? Right from the ticket screen itself. So that's why we call it an action. So as you can clearly see now, I can go ahead and say, select an action. And you have a few set of actions here. And we literally have everything from a simple checklist item where you just have to go through if everything is fine from a ticket form perspective. Do you have all the information to do server troubleshooting or user onboarding? It's more like a to-do list that they have to go mark. Then you can go ahead and say, add a checklist item. And I can just say, check the values in the ticket fields. Ideally, it should have been filled before you start this particular, let's say, standard operating procedure itself. And then what you do is you also look into, let's say, what else a technician would do. Ideally, will they send a quick acknowledgement reply saying, yes, everything looks good. I'm going to start working on this. And should they send a reply? And you want to ensure every technician has the same way of replying, the same way of communication, etc. Then you can preempt saying that now it's time for you to send a reply. This is where maybe you go ahead and send an acknowledgement and you just hit save. And you are also adding it as a template so that they really don't worry about what they're saying. They just have to click and it's going to fire. And similarly, you can go ahead and now think about, should they even request an approval? It can be internal approval where it can be for technicians or let's say external approvals that is with clients. So are there different stakeholders? How do you run an approval? Should they run a script to an associated asset, see its output and take actions based on that? Do they need to refer to an IT documentation so that they can make sure that after the troubleshooting is done, they have to make sure this configuration and what the IT documentation says is perfect. And you might sometimes have, let's say automation sometimes running, saying whenever a ticket field is updated, something should happen. But how many times have you had the case where your technician didn't update the ticket field? So you can actually add a step saying this is the time you have to set this particular property into, let's say, one of these categories. I can either leave it blank so that the technician can set it at that moment, or I can even give the value for the field so that the technician can hit run and it's going to automatically update the field. So that's one of the actions that we have. And the other part is, let's say I have to quickly initiate a vendor conversation or a site conversation with the vendor or a subject matter expert, etc. Then I can have that. And many times you might want to also ensure that the technicians add notes. Why do we need that? Because as a service desk manager, sometimes things escalate. You need to understand what was the diagnosis till now? What did we do in troubleshooting? How many times have we had the case that the technician didn't document that at all? that at all? And maybe they are on leave today, right? So how do you get those processes built And maybe they are on leave today. So how do you get... in so that it drives the right behavior? So I can even say, add your, let's say, a diagnosis note. At this point, you should have had a diagnosis, add that so that even something escalates, I will know what it is. So I can even ask for a note, etc. And when all this work is done, they have to quickly add a work log, then I can choose to add a work log. And you can see pretty much all the actions that connects the complete unified platform, be it within ticketing or RMM, like running a script with an associated agent, seeing its output and then taking the next steps, etc. Or an IT documentation. Everything is in one single space while building the runbook. So no more tab ops for a technician, no more going and searching for an asset, searching for which script to run, because they just already know if it's a Windows, which script they have to run, and it's already there ready to be fired. So they are not really searching for anything at all. And this is how we started building runbooks. And then we realized, yes, this is a free canvas. What if you have to ensure that one step is done and only then the next step can be done? For example, now the way I have built the runbook, I can even skip the step and I can say that, yeah, check the values for later, but I'll send an acknowledgement first. I could do that, right? But now you don't want them to, let's say you want them to ensure that before checking the values, they should not send an acknowledgement. And you want to lock these steps. That's when you can make it, let's say, let's say series. So you can clearly see the moment I push it into a series, what happens is it adds a tag saying on completion. So now what it'll do is it will restrict the technician from ensuring that only after they complete the step, they have verified the output or after they added a diagnosis note or after they run the script. And based on the script output, then only they have to, let's say, do something. Then you can go ahead and ensure that you build a runbook this way as well. So the way we built it is if there are a few fields that are flexible, that's fine. Whenever you have a diagnosis, you can add a note, you can go to the next step. If you don't have one at the moment, then you can build it in a, let's say, vertical manner. But if the steps are dependent on each other, you want to ensure one thing is completed before something goes to next. Then what the moment you start building it horizontally, what happens is automatically we will tag saying that this will happen only on completion. So we will restrict the technician to refer this it doc until they run the script and validate the output. Right? So this is one additional thing that we did. And very interestingly, what we thought is what if, let's say you want to do all of this, but now there are two types of things that happens on a ticket. Let's say I'm a technician. I can decide, okay, I have a diagnosis note. Now I'll add it. Sometimes once I know the ticket field, I can go ahead and add it. I can decide, okay, now it's the right time to acknowledge. I'll go ahead and initiate that acknowledgement. But sometimes you want to, you don't want your technicians to do all this one by one, because these steps are not really independent from a time perspective. And there is no decision by a technician that needs to be made when these steps are run or verification that a technician has to do, et cetera. We will see the technician side of things, but you want to ensure that they are super productive. For example, let's say closing this ticket, I want to have a set of closing actions, right? In closing actions. Now I have created something called an auto action. I named it closing action. And within this block, you can add multiple actions. So I can say you have to go ahead and send, let's say a closing note or a thank you note. This is like a server troubleshooting note that you will send. Then after that note is sent, you would have to update the ticket field. For example, what is the department? What is the type of the issue? All of that will be automatically set up. And then you would have to go ahead and add a note saying, let's say, what was the troubleshooting step or whatever it is, and it is done, et cetera, resolved, or any resolution notes, it should be already there. Or you should automatically log because you did this so fast, but ideally this kind of a job would have taken an hour or so, and you want to ensure that they log, let's say labor for one hour or something, you can just go whatever actions that you saw. I showed a separate actions. Now you can club them under auto actions. Now the difference is when let's say a technician ideally can go one step at a time, but when they trigger an auto action, all of this will be fired in one single action and everything is done in one single go for a technician. So that's how it can get powerful. So you can even have, let's say, nodes of multiple auto actions. So I can say first step is I have to do three things, fire it, three things are done. Second step, you have to do our next five things, add the five things here, five things are done. So this is how you build a runbook, and these are all the basic building blocks of a runbook. And with this, what we ensured is one, we ensured that from day one, you will feel the power of using a unified platform. I'll show you how a technician would use it because you're able to link everything as a workflow here. And second is you are able to drive operational efficiency, which directly shows on your bottom line. And three is because you're super fast and getting things done faster, your client satisfaction also goes up. So these were all the top three outcomes that we wanted to ensure we keep driving when we built the runbook. And that's a sample that I built overall. Let's say if I have to quickly show you how a big sample would look like, for example, let's say I built one for user onboarding, where it literally me to check if I have the first name, last name, all the details that came in the ticket field, I have to then request an approval so that I can provision their licenses in Microsoft or something like that. Then once I get the approval, I have to create a task for user creation. Maybe I don't have access to it, but somebody else has to have to do it and then create email address for them, et cetera. I can even reject saying that, okay, this step should be a first and this should be next. And you can see that how easy it is to move around the canvas as well. Then you have to send a response and then you have to do a task and then IT documentation, request a note and a side conversation. So literally I have ensured that based on how a technician should ideally go about handling this particular ticket, I have used all these elements to build a user onboarding a runbook. And finally, I have a closing action saying that this is the setup that you did. This is the update you have to do, send a thank you note, and you just add a note saying onboarding is done or something like that. So this is how you can build, let's say runbooks to start with. And ideally, if you are an MSP owner on the webinar today or an MSP manager on the webinar today, the way you have to think about runbooks is what is the biggest thing that is actually causing your efficiency drain? Because I have spoken to so many MSP owners and managers out there. Yes, runbooks are great, but you should really know what are all the real high impact runbooks that you need to build that will actually hit your bottom line, that will actually hit your operational efficiency, etc. So one quick way to do that is you can use our efficiency reports. We already give that. So for example, let's say I can go ahead and analyze resource utilization and client efficiency report is something that I have. So I can quickly analyze what's going on. And also what I can do is maybe lose like the last six months timeframe. And I'll be able to see for a particular client, like a Dun & Mifflin or something, quickly seeing what is like pulling me down, what is really doing well. If let's say that is maybe I'll take some other client where I can see, yes, I can clearly see for this particular client, whenever an AD or a password request comes, my efficiency is 17% below average. Why is that? Maybe do they have, let's say, separate environment my technicians are not really familiar with, or are we really slow here? And this is really bad. We are, our efficiency for database questions from this client is super slow, like literally a hundred percent slower than ideally how we would handle it. So what you could do is there are more than sometimes 32 tickets that are not categorized or seven tickets that is pulling your efficiency down, etc. We can use even AI that's there in the platform to quickly summarize saying, okay, I know my efficiency is being pulled down in this type of ticket from this client. Now, can I go ahead and see what's going on? And you don't need to actually go through every ticket because realistically, you're going to have a lot of tickets if you do one year or something like that. Rather than that, just hit summarize and the AI is going to clearly give you what are all the categories that is coming in. Maybe there are multiple printer requests or let's say a particular type of request that is coming in where you are not having an expertise on. So you would want to quickly add an IT doc and set up procedures, a script and etc. Build it as a runbook and then fire it. And then you would be able to see if your efficiency is actually going up in terms of that particular category. Now you can see, okay, I built a runbook. Am I able to go ahead and keep increasing their efficiency based on total time spent and resolution time as such? So this is how we can track, are you actually improving the efficiency? And also what you need to improve efficiency on that will actually hit your business's bottom So this report will help you with this. And once you get an idea saying, okay, this is what is required. So ideally I would suggest owners and managers to use this report and maybe have like, let's say a monthly recall on how many runbooks should we build this month and deploy it. And the best part is once you build a runbook, we will also show you how many tickets has it been associated. You can even associate a runbook automatically. So I can clearly see how many times was it associated and how many times was it actually completed. Are technicians completing the runbooks? Is it really useful for them? Because association can happen in two ways. One is I can even use my event triggers where I can go ahead and say, whenever a particular ticket comes in, for example, I can go ahead and quickly build an event trigger saying on ticket creation. If let's say the type or let's say category of the issue that is coming in is let's say AD or password or something like that, then automatically assign a particular runbook, right? So I can automate saying what runbook has to be associated to the ticket. But however, what the setting also shows is are they, yes, you are assigning the runbooks, but they have to use it for your efficiency to improve and your profitability improve. So you'd be able to see, are they using it? Are they completing it? If not, you can have a conversation with your technician saying, Hey, how can we improve this so that you can get faster? Right? So these are all the things that we built for an MSP owner and a manager. And one classic use case that I would give is recently I met an MSP and the owner, when I asked saying that, what is keeping you up at night? And the owner clearly told me, he's saying that what's keeping me up at night at the moment is my L2 and L3 technicians are too much tied up in, let's say, escalations from my L1 teams. And because that is happening, their bandwidth for doing projects is going down because projects are getting slowed down. What happens is all the onboarding projects is taking longer. So the time to profitability with clients is also increasing. So I'm burning more money. That's great. Now that is how an MSP owner is thinking, saying that's what's keeping him up at night. Now, how can we ensure that we free up time for the L2 and L3 technician is by empowering the L1 technicians to get the job done. So we went ahead and showed how you can understand where is these escalations happening? Where is the efficiency dropping down using our And the business ended up making sure that by tracking this, creating at least two runbooks a week and ensure people started using it. And then they started seeing an uptick in L1 technicians, even interns handling a lot of questions and the L2 and L3 are actually freed up to do projects and their project time cut down by at least 20%. So this is how we kind of drive these outcomes as well. So as an MSP owner, think what is really keeping you up at night and how you can actually drive that outcome. And for driving that outcome, what runbook should I build? Our reports are already there, which is giving you the answer. So that is from a manager and owner perspective. And the reason why I spent a lot of time here is pretty much most of you on the call, I believe, are managers or owners. And that is why what you are worried about is your profitability and what's going on, et cetera. So this is how we can ensure that you identify the right problem and try to go with outcomes. So that's one way. The other part I'm going to show it is what it is like for your technicians who are working on a particular, let's say, ticket. Now, this is how it looks like. For example, let's say a new employee onboarding ticket comes in. There is a reason why I'm showing this ticket that is already filled because it's been used with the runbook, but I just want to give you an experience saying how the end result could look like rather than me doing all the steps one by one. So I can clearly see that, let's say, if it's a new ticket, new employee onboarding has come in, automatically the automations as associated the user onboarding runbook for me. Now I have to confirm my details with maybe a reporting manager, or let's say, confirm the details on the ticketing field. Yeah, it looks good. I have to initiate an approval, and I can say, initiate the approval, and I'll be good to go, or something like that. I can add some custom message. And it's automatically showing, if it's a technician, who I can send it to. And if it's a requester, who are all the requesters? Who can give those approvals? You can set this up in the runbook. So I can then go ahead and say, set an approval. Perfect. That step is done. Now, OK, once I got the approval, because you'll be able to see the status of those approvals as well. So the moment you push an approval, you'll be able to see, OK, it's still waiting for an approval. And if you get an approval, you will get a notification. So let's assume that the approval was done. So now you know you are going to the next step where I have to create a task. So I can just say, yeah, go ahead and create the task. Everything is automatically pre-populated. And I know only Gaurav can create the task. So I hit Save, and the task is actually delegated. So this is how I'll go one by one. But now, let's say I have to do some other step, like associating this doc. I'll be able to actually do it. But if I have to refer to this IT doc or send this particular reply, I won't be able to do it, because it's restricted. Why? Because these are all the way you added dependencies in runbook saying, before you do this, you cannot do this, et cetera. So now I can go ahead and say, yes, this is done. If you want to quickly send a reply, then I can just hit Send Reply. The reply is automatically populated. Hit Send. That's about it. And you're done with that. And if I have to refer to an IT doc, I'm not even leaving this particular screen. I just say, OK, I have to check for system configuration. I hit Play. Immediately, it will show me the IT doc right on the same screen at it will show me the IT doc right on the same screen itself. Once I have everything here, then I can go ahead and say, that's good. And maybe if I have to associate a task, then maybe send out another reply. I can choose to do that. And one thing that's very interesting is even scripting. So if I have to quickly run a script, I can quickly choose the asset that is automatically associated. And then immediately, if a script is associated in the Runbook for that particular OS, it will show up and I can quickly hit run. And the moment you run a script, what happens is you will also be able to see the output of the script right here itself. If it failed, it passed, all of this, you don't need to go to your asset screen, RMM, nothing. You can just hit run and see the output right here itself. And once you are done with it, you get the drift of how Runbook works. And once you're done with it, let's say I have to go ahead and complete. I'm done with this job, so I can go ahead and hit auto complete. Now, what Runbooks is telling the technician is, hey, you are about to perform something where everything is going to fire automatically. Are you sure? The reason behind that is, let's say all of these steps, for example, let's say I have to send this particular reply, it will go ahead and create the reply for me and keep it as a draft. I can still add more details, even if it's a task or anything that I did. So I still have some control over this and then I can go ahead and send it. So it can kind of give some direction for me to do the job. But auto actions are completely automatic. It's like an automation. So if I go ahead and say, hit run and confirm, it's going to automatically add the work log, update the ticket field, send a reply, a thank you note, and also add a note called onboarding done. So that's exactly what you will be able to see that what the auto action does as well. And you will be able to done with that. You will be able to see all of that happened and you can see that there are updates on the ticket and you can see a thank you note has been sent, onboarding, the note has been added, the work log has been added as well. So everything just happened in one single click. Now, if you see, I did so many things on this particular ticket, across RMM, across IT documentation, et cetera. But we built it like a chef's table that your technician didn't have to go beyond this particular ticket screen at all. Everything they had to do was just one click away. And they also knew how to go about it. So this will also reduce a lot of your learning curve. Let's say if you are having interns sometimes joining, apprentices coming, UK we have a lot of apprentices joining. So we have noticed all this. So rather than having a huge onboarding for them, learning curve for them, et cetera, they can get started as soon as within a week, because you can see if these are all the simple ticket categories, you just have to go and fire this runbook one by one. And this is what you have to do. It's pretty much straightforward. That's exactly what you have to train your technician on. And that's about it. So this is how you would be able to drive efficiency. And this is how your technicians would work with respect to runbooks. I'm pretty sure there are a lot of questions and my team would be answering them. But I wanted to show you, let's say, the view of how you think as an MSP owner and a manager on what runbooks to build. And for your technician, this is what it is. For example, coming back to the story of that MSP that I told about, MSP owner wanted to free up L2 and L3 for projects. We identified using reports saying what are all these tickets that's driving efficiency down and coming to L3 technicians. We built runbooks for them. And after that, also what we did is with power of runbooks and recommended solutions, that's part of the AI, where I can go out and say, if you're an L1 technician, this is your runbook. If you want to just quickly see what solution that you have to do, you can even ask Monica for that. Monica will go ahead and give you a recommended solution saying that this is the approach that you are going to take. And this is very specific to MSPs in itself, because this is not a generic recommendation or a chat GPT prompt. It actually sees your own, let's say, tickets, previous resolutions. And then Monica is going to suggest saying that this is the kind of troubleshooting that you would do for this particular case. Great. I got a hang of it. Which tickets did get this understanding from? If I want, I can even look into that. This is how I'm exploring as an L1 technician. Let's say I'm an intern. I use Monica to understand, this is how I have to solve about this particular issue. And what are all other similar tickets and how did they go about it? That's very interesting. So I got all this information from Monica and itself. Now there is already a runbook that's automatically associated. And I already know which direction I'm headed. Just go ahead and start. So that's how we have improved the learning curve for any that is coming to that business. And also all the L1 technicians are so much self-sufficient because even if there were any previous resolutions by their L2 and L3 technicians before, while going through a runbook, they always have Monica to ask and it'll bring up and show. So the number of escalations for L2 and L3 drastically came down. L1 technicians were able to handle a lot more. And that's how you are able to cut down their project time by 20%. And that's how using, let's say your reports, AI on reports, AI on ticketing and runbooks, SuperOps becomes the only unified platform that actually drives, let's say, your bottom line and also outcomes for your customers. And that's what we believe in. And that's what we are actually seeing with our customers also day in and day out. And that is why we invested in all these new opportunities that were out there in the MSP space for using an unified solution. So that is what I wanted to share with you. And the next part, like Manish pointed out saying that what else is in store that looks great. I haven't gone through the questions yet. Maybe I'll definitely go through one of it. But if there are already questions on, let's say, what's next? What am I going to do with runbooks? Where are we headed? So the way in SuperOps that we are looking into runbooks is we want to make sure that it's completely autonomous with the level of now AI agents and all of that is coming through. So based on our analysis, we saw two different sites to, let's say, automation that needs to take place. One is a technician's decision or a discernment is required before something is fired. For example, a runbook. Can I ask for an order? Can I send this reply? It's a technician's discernment saying, yes, I can go ahead and do it. Then I can use the runbook to do it within a click, rather than taking some time to go ahead and type that reply out, et cetera. That's using technician's discernment, but we are kind of automating it to an extent. But a few things, what will happen is, let's say, I have to provision, let's say, a user creation in AD. Now, all I can do is create a task inside SuperOps. But however, what if I could actually trigger an action in AD right from here? So this also requires technician's discernment, where a technician knows this is the right time to actually create, let's say, the user. How can I go ahead and click this? And it'll still go ahead, just like how I'm running a script and showing me an output. It'll get the job done in a third party system and then show me it's done or not. So how can I do that? We want to go there next as an immediate step. And also, as a complete step, we want to build, let's say, a complete workflows where, let's say, you can automate our steps in such a way, saying that, let's say, if a ticket comes in, we are even thinking of an agentic approach where a ticket comes in, it's automatically understanding saying, what kind of a ticket this is, what needs to happen, what are all the initial actions that needs to happen, what reply needs to be sent, all of that will be automatically done. And then whenever a technician has to intervene, a human should be in the loop. It will keep the ticket already in that particular space. And then when a technician says, yes, go ahead and now create the user creation in AD, based on the output, it can, again, trigger a series of workflows and keep it in the next state where a technician's input is required. So this is how we are thinking about it. And few tickets, if the technician's input is not even required, how you can go ahead and just completely automate the whole, let's say, resolution in itself. So these are all the initial, let's say, thoughts that we have on how we will scale this. But this is our first V1 of the vision that we wanted to go with in bringing the value of unified platform from day one for operational efficiency and customer satisfaction. And in phases, now you will see Runbooks talking to external systems and making sure that you are able to even completely automate all of the tasks as well. So that's like a quick wrap up that I wanted to give you. And I just want to check with Manish saying that, is there a good time for a poll, Manish? Yes, for sure. I was just about to go for it because, firstly, a great session. And followed with that, we just have a couple of questions before we jump into the Q&A, right? Because we just wanted to start off with just understanding exactly what sort of use cases all of you folks, right? So we just have a very short, very simple one question, where we just want to understand all of the situations in where you would build a Runbook for, just to basically optimize your current IT operations. I'm excited for this one as well, because I've heard a lot of use cases and creativity thrown by MSPs on how they want to use Runbooks. So I'm really excited to see this as well. But this will also help us understand how we can make Runbooks better in series of iterations as well. So this should be super useful, Manish. Yeah, I agree. So I think even in the short term, I feel like this sort of insight is going to be very useful for us, because we've seen a lot of comments on communities and forums, where folks have asked us, hey, like a community library or any sort of templates would be very helpful. I think this sort of insights from all of you individuals would be very helpful for us to be able to take the first step for that, right? Because we have been discussing a whole lot of solutions internally, but this sort of insight or more deeper understanding of all of the individual use cases that you might have, can basically help us figure out a solution that can basically help you sort of eventually down the line, just figure out, get all of these use cases onto the platform, where you'll just be able to plug and play, and you're just able to get these operations running in minutes, right? So that's eventually where we want to go. And this insight would be super helpful for us. Yeah, that absolutely makes sense. And while that is also going on, I wanted to pick a few questions from the chat as well, just to add my viewpoints. One is, is Runbooks going to replace tasks? Not really. That's not how we are seeing it. So the way we look at, let's say tasks is, one is, there's the two parts to Runbooks. One is checklist and a task. So if you are looking like a to-do list, you can just use it a checklist. And checklist is more for the assigned technician. Let's say I am the technician and I need to do this, this, this. That's how Runbooks is going to work like. And also the checklist item also goes ahead and helps me do that as well. So that I am ensuring that I'm covering all aspects while doing the As a technician, I will not be able to do this, but I have to delegate the work to somebody else. Then you can use a task. And that's the only time you would need to now use a task with Runbooks in place. So that's like one clarification that I wanted to make. So we are not seeing Runbooks replace tasks, but we still think tasks can be used to delegate work to other people while are working in a collaborative manner. Yeah. That's one thing. And are we done with the poll Manish? Yeah. I just want to make sure that we just give them like another minute just to, just to make sure that anybody who's already typing just gets a minute to just complete their answers. But in the meantime, we also have another message on chat, I think, which you might want to reply to. Yeah. I'll go with it. So another question on the Q&A that's already there is will this eventually expand beyond tickets, such as billing where an email remain can be sent to the client? Yes, of course, Chris. So one of the things is this is where we have started and the value of Runbooks itself is how we are planning to make it really unified. And that's our goal as well. And we are envisioning all of this. So we will invest in a you would be able to see that. And especially for the email reminders on billing, the one thing that you mentioned, we are already working on it as part of our invoicing announcements that we already started working on. So we are constantly working on how to improve your service desk experience to drive operational efficiency, and also how to ensure you generate accurate revenue without leaving money on the table and have the most accurate profitability insights that you have. And to improve your cash flow, definitely email reminders already part of the roadmap, Chris. So thank you so much for that question. And also, I'm just seeing that there are any there are questions on when projects get some love. Of course, that's a very valid question. And we've been wanting to go there as well. And definitely we have some plans towards, let's say, the second half of this year to improve our project management. So currently, the way what we did with SuperOps, if I have to give you a quick insight into why we are, let's say, taking the items the way we are doing is one is first, we wanted to build for any MSP that who's getting started, or let's say start starting their MSPs. Let's say one tech, two technicians, etc. How can or even let's say up to five technicians, how can they not, let's say, invest in multiple tools and have one single tool to drive a cost efficiency to start with. And that's where we built the breadth of the platform. Now, we have a lot of bigger MSPs showing some love to SuperOps. And we have like MSPs ranging from, let's say, one tech to even like 30, 40 techs, etc. So we have like, and more. And now we are actually attracting a lot more bigger techs. And this is where we are investing in the depth aspect of it. And one of the aspects that last year that we took in terms we took in terms of, let's say, the depth is we wanted to ensure SuperOps is the most accurate profitability calculator and also insights that you would be able to drive compared to any other PSA in the market. And SuperOps is the productivity tool of choice for anybody. That's why we invested in AI, we invested in runbooks, and we wanted to ensure that we drive productivity in your service desk, which is ticketing, because that is directly a part of, let's say, your COGS, your cost of goods sold as a managed service provider. And if you have to really improve your bottom line, we wanted to ensure we do everything for that. Now with our new contracts, AI, runbooks, all of which is unique only to SuperOps, we have ensured that this is one of the most compelling productivity tool of choice and also the most accurate profitability engine with our new contracts. So that one, you would be able to clearly know, are you taking the right decisions for your business and also drive efficiency that directly impacts your, let's say, COGS. Now, that's like the immediate thing that we wanted to work on. Now, having done that, we have already moved on to the next step, which is one on the revenue front. It's just not about contracts and service delivery. We want to ensure that you're able to complete the loop in terms of cash flows, like invoicing, your invoicing workflows, quoting workflows, and all of that, so that there are no drops on the table in terms of any revenue related workflow. That is one of the things that we will be doubling down on in terms of depth. And the second thing is managing work in general. That is where we will start doubling down on project management. How do you manage work across projects, tickets, and tasks, and your schedules and onsite events, et cetera, and all of that. So these are all the things that we are going to double down on towards, let's say, the second half of this year. And that's our thought process on how we are building a complete tool that actually drives outcomes for your business. Awesome. So I'm just seeing if there are any other questions that I can pick up. And there are questions like, can I have a yes or no step in, like, have you disabled the virus? Yes. Go to checklist one. That's a very good question, Jerry. So to start with, we wanted the V1 to be a little experimental. So that's why we kept, like, if you want to go free flow, just go ahead vertically. And you can even have a checklist item saying, or a note or a task item saying that, with the name task saying, have you disabled antivirus, et cetera, right? And if yes, then what they have to do, et cetera. Maybe you can use it as a checklist or a task or something like that. And then the next step can be tied as a dependent, let's say, for that particular answer that they will have. But however, what we have not done is decision trees as such, because now we have only two flows. One is you can do steps in any order you want, or you can still step one thing before the other. So it's one linear thing that we have introduced. But as I said, the future of Runbooks is to completely automate a lot of these processes, et cetera. And one of the things that we will do before doing that is a free flowing canvas, where you can have decision trees. And based on an output of a previous step, how you can go ahead and manage the next steps is something that we will definitely explore down the line. And that's definitely on the cards. Perfect. So there are some more inputs on, can we build Runbooks on the fly? Every ticket is unique. Of course, you will be able to build Runbooks on the fly. Let's say as long as you have access to it under the settings, you can go ahead and build Runbooks. And it's very easy as well, like I showed in the demo. But if you are looking for something in particular, feel free to reach out to us and we can see how we can help you with that. And also there is another point on Runbooks can be very powerful, but you would love to see a spot on the discussion board website where people can fill out the Runbooks they have created. Absolutely. Manish, would you want to take Marco's comment on how they would love to discuss more on how Runbooks can be used? Absolutely. So I think again, just as we mentioned earlier, that was a big part of why we asked for that poll in the first place, primarily because we really wanted to see exactly how imaginative all of our users were. So we're very much in alignment on that, Marcos. We'd love to see if we can get in touch and gather ideas later. Perfect. Manish, I think there are some, let's say, other questions as well on any idea when AI will perform better so it can do more than just summarize. I'm not sure if you have checked our recent features already. AI does not just summarize at the moment. It can have custom prompts. You can create, let's say, you can use custom prompts that is, let's say, defined by you as MSP owners. You can create them so that your technicians can use it. Like, let's say, how your technician should sound. You can train your own prompts with our AI and ask technicians to use it. We have launched similar tickets. Whenever you have to find are there any similar incidents, similar to this that's happening, you can just use that. We have launched recommended solutions, which is one of our most recent and powerful solution as well. Based on your previous resolution, you would be able to actually see is there a recommended solution based on how I solved or how an expert solved it before in my own MSP. Or you can even use, let's say, the AI to go score through the web and bring you recommended solutions as well. So these are all the things that we have already launched and we are going to do a lot more with AI. So we have already gone beyond just summarize. So feel free to test all of those out. If that's not there, you just have to go to settings and enable all of these. And once you have this, you will be able to do that as well. So that's something that I wanted to answer. And also when you get a ticket regarding offboarding, that should be done on a certain date, you want to snooze it. That's a nice feature request on snoozing. We'll definitely look into that, Thomas. And there's other question on, are there any plans to integrate Runbooks into an API? Yes, that's like I said, where Runbooks is headed next is first, we are looking to automate everything within Super Ops. And then we want to talk externally into third party systems as well so that you can do all your job right from Super Ops being one central platform. And that's exactly how we are headed down the line in our vision. So perfect. I think those are some great questions and thank you so much for your time. And mostly all other questions I see are answered. Manish, is there anything else from your end? Yeah, I think Marco just had like one follow up question, which I think is whether there was a way to run other Runbooks from a Runbook. I completely understand the use case that you're trying to put out there, Marco. But right now, we're at the first stage of basically being able to flesh out a single process from end to end. But like you said, and your question is also very similar to one of the previous questions that we had, which is basically adding more conditions to it, adding more branches to an existing process, which is something that we are looking at down the line. Yeah, absolutely. Awesome. And folks, I think we'll hold this stage for another minute to see if you folks have any other questions before we just want to wrap up. So if you folks have any other questions, this is probably your last time to ask them. And if you folks did find this session useful, please let us know. Or if you folks think we could improve on something also, please let us know in the chat. We'd love to hear what you think. And just so that we can make these sort of sessions even better and more contextual for you folks later in the future. So please do let us know. There is a question on possibly get the ability to prioritize task order by group of tasks. I don't get a clarity on what the question would be, but feel free to reach out to the details on the question. Maybe we would love to know more on what you're exactly trying to do, Benjamin. So feel free to reach out to our support chat and one of us will be able to help you on that. And also, are you intending to group runbooks rather than having a huge list of them? Yes, Richard, that's actually a great question. And we want our customers to create so many runbooks that this becomes a problem. We want to immediately go ahead and solve for it. So we will think ahead of time and make sure that we also start introducing some kind of grouping as well. That's actually a great suggestion. Thank you so much for that. I think Ben also has another question in terms of being able to prioritize task order by groups of tasks. I think that also kind of like falls into something that you just answered, right? Yeah. And I guess I think Ben's also trying to clarify because I would like to know what exactly he's looking to do as well and then we will be able to guide. So yeah, we can even take this offline and we can drop you an email and I would be happy to have a detailed chat on that or even reach out to our support team and we'll have a chat on that. Absolutely. I think I also responded to one of your community posts a couple of days earlier, Ben. So yeah, please let me know if you'd like for me to just start an email set with you and both Akhilesh and I would be happy to just have that back and forth with you. Thank you so much, Brian. It doesn't matter. No problem if you join. We're just going to be sending the session recording to everybody who registered. So they're completely covered on that front. Whatever you might have missed, you absolutely have the resources. Just learn that again. So not a problem at all. And Charles, if you can, you can basically join our community right from within the product, right? You have a section at the bottom left corner of the screen where you can just join the community. Akhilesh, thank you so much for just popping that up. If you're able to see it right there. So right from within the product, just by clicking the product feedback section, you'll be able to join the community. Got it, folks. I think, yeah, I think we're pretty much done with the questions. I hope we don't have any more questions that we've left on. Have we left anything unanswered, Akhilesh? No. I think we're good. Right. Got it, folks. All right. Thank you so much for joining this session on Unified Runbooks. We're very happy that so many of you just stayed till the very end to understand this feature in detail and for all of your contributions in terms of just letting us know of all of the use cases that you had. This has been a very gratifying session for both of us just to see all of the interests that you've shown for the future. And we're looking forward to seeing all of the unique and different runbooks that you're going to create. We're very, very excited for the future. So thank you so much, folks, and have a great evening. Thank you, folks.
