Transcript
I'm talking today about some service delivery best practices inside of connect wise probably give it a minute or two before we get started just to let a few more people in the room here. For those of you, this is your first session. My name is Kyle and part of the part of the success team here. Connect wise and really what we're trying to do with this webinar series, which is a nine part series is to show partners really where the best practices are inside of connect wise looking at a fully set up best practice environment and really concentrate on some of the main areas to see. A lot of partners get concerns around, especially around the setup of connect wise. I know most of most of you guys are only only looking at your own connect wise instance day in and day out, so this is really an example to be able to showcase what some other setups of connect wise. PSA look like. Well, give it a minute or two before I get kicked off here and then will be underway. Excellent, well, yes, we're late journey, so we'll go ahead and start getting kicked off now. Uhm, so. Purpose of this call today is really to run through best practices and best setup guides inside of tech wise. PSA I will be utilizing my current environment which has been worked on with the consultant team as well as the sales engineering team. To really give a full picture of what a fully set up PSA instance should look like. Lot of relationships around how the structure and the foundations are configured so we can get the best reporting out of the system here as well. Today's session is going to mostly focus around service delivery inside of connect wise running through some of the service board setup configuration records inside of the service board SLA reports. Best practice of what you should be do utilizing the service board for different views that are helpful as well as some kind of process automations when it comes to two step closing processes of tickets and a few of the common workflow rules that most partners should have set up inside of the system. Then eliminate any of the manual work the text might need to do to clean up some of the the sale tickets. So I'm going to kick off here by going into our service board setup inside of connect wise for those of you on the last call with me, we did concentrate mostly on the company structure in the department piece of it where service boards were a major part of how the data relationships tie into connect wise. Today I'm going to mostly be concentrating around my service desk board which is associated with my DropBear IT ABN and my tech services P&L type department. So really any ticket that gets created and worked on on the tech services board is going to be associated with the tech services P&L for data reporting and keeping that data separate from my managed services, my professional services, profit and loss centers. So starting at the overall service board setup, again noting the location of the apartment. These fields are unable to be edited once you start creating tickets and time entries against the system. If you do have an if you are looking through your system and see this is misconfigured, really the only way to be able to repair this is to actually create a brand new service board, at which point you're able to change that department field or location field on that new board going forward, and then after inactivating and retiring the old board. That way you'll be able to get the right data reporting inside of your connect wise instance. But for something like a help desk or service desk board, typically most people throw underneath a tech services level department. So kind of going through the general setup of this board. Main area I see a lot of partners struggle struggle with the current setup is going to be around the ticket finance and default billing overrides. So really what this section over here has to do is with the financial information of once people start putting time against the tickets on this board by default, how the billable fields are going to start to interact within connect wise. So starting with my work role in my work type. What these field dictate if they are filled in is anytime a new ticket gets created on my service desk board. This is going to override what the default work rule is in work type on this service ticket. And what it's going to look like is if I click into a random ticket. It's going to dictate these options inside of here on the finance information. So on my board right now I work role work type or blank and these guys are all set to no default because it's pulling from these ticket finance default settings on my board level. Now. From a general standpoint, my recommendations is keeping the work role in the work type field blank. If you have a varied amount of different work rules and work types that might be used on this service board. The use cases to use in these overrides is let's say if it is a service desk board that is only worked on by my tier one level resources, I can set overall work rule so that whenever my technician stop putting time against these tickets, they're able to default the right work rule in on the time entries. Maybe the hourly rate is always going to be $120 an hour for my service desk board. This work rule override will make sure this is set and it's not going to pull from whatever. Maybe my default work rule is that's tied to my member or maybe tied to my overall company page. Work type field. This is a field that. You that can be filled in more often than the default work role. This generally controls the where and when the jobs being performed inside the system, so typically this is going to be like business remote business hours remote after hours. If you're using the same work type 99.9% of the time, you don't necessarily need to have the default work type specified inside of here connect license going to use whatever your default work type is that set up on your work type setup table which 99% of the time it's going to be remote business hours anyways. So a lot of times I see partners have this configured for the sake of just having an override in place. So having these two blank generally generally best practice based on the use case of a service desk board. Getting into the build time, build expenses and build build defaults. This build time field is going to really interact with if all the time entries on this boards can be built or not. Now a lot of times I see partners setting this override right to a billable field which is going to dictate every single time entry on this board is always going to be billable. Now, usually I recommend saying this is no default because your work type is really going to be what dictates if the time entries billable or not. Again, going back to if you have are using remote business hours work types primarily for all your technicians. Again, usually 100% of the time work on your work type is going to be billable anyways. So having this override in place is really just. It's not helpful and it can actually cause some issues if you're using something like maybe a communications work type which is non billable. This will actually override this communication work types and make them billable records in there as well. It will start throwing off some reporting like if you're trying to get some profitability or billable numbers by technicians, it's going to start reporting everything is 100% billable by your by your technician standpoint and not just give you good reporting down the line. So unless it's a very niche use case, this kind of setup here for your ticket billing finance overrides should be what you have inside your environment. Again, exceptions do apply, but probably 95% of the time for service desk or this is all you really need. During my agreement session in a few weeks, we'll go into this a little bit further because there's different ways agreements can override this field too. But yeah, just keep in mind that generally we want this to default from your work types. So moving on into some of the time entering closed loop options, this area here is really going to determine when closed loop is enabled on your service tickets, mostly for sending out emails from the time entry notes inside of here. So generally I only want closed loop enabled for my updates to discussions and then updates to resolutions or the all. Basically what that means is when I'm on a service ticket. And I go into my discussion tab and I hit the new note. I'll get this pop up screen that's going to go ahead and try to have me create a new time entry inside the system. And turn on my closed loop by default. Whereas. When it's updates to the internal in this box is not ticked. This is why if I go in my internal hit the new notes, it shows me this new notes field and doesn't really give me any options for creating time entries for this specific entry. Now you can still get time entries added into the internal of the ticket. If you if you are wanting to go that route by overriding some of these defaults on the time entry screen again, taking if I want to add the notes, the internal will still be able to print the time entry, but the overall default of how the closed loop screen and the time entries work inside the system. Generally, you really only want to update based on the discussions or like a resolution level note. In terms of the automatic email options. What this send to tick box controls? Is whatever new tickets get created inside of connect wise? We have this send notes as email button over here. That takes whatever the default is. For my service board, so generally for like a service desk board, I only really want that send to contacts box teched so that when I do. Start to create a new time entry inside the system. I'll just not show it up inside of here. Let's try this instead. There it is. It will automatically tick this box to show that it's going to send this time entry note as an email to my contact. His best practice inside of connect wise is really any email communication we have to the client should be within the service ticket. But I want to track those emails as true time entries in the system as well as it might take the technician. Maybe 10 minutes to wrap the email, even if it's something covered by an unmanaged services agreement. I want to start tracking how much time is being put against those agreements, and more importantly, how much costing my members are actually putting in these agreements too, especially if it's an all you can eat level agreement. Yep, they determined to work. Clients in the build for it, but I want to be able to track if I'm spending hours and hours in communication to the client as part of the managed services and see what I can do maybe to reduce the amount of admin work that's actually required to finish and communicate on these tickets here. With this as well, we do have the ability to set up an HTML email template so that when we do start to send out emails from the closed loop to our clients, it can use a specific email format rather than that kind of weird blue green one that might be showing up inside of your system as our overall default. What you can do is you can specify which HTML email template you want to utilize here. And pull it in from the drop down. Now, best practice is to really kind of keep this as a dummy status on your service board. So I created a status specifically called closed loop email template. And where this drop down list is pulling from is going to be my list of statuses. And it's going to be essentially this as my HTML email template. Now I'm not an HTML email coder by any stretch of the imagination, but this is where you can start to specify like high contact first name, and utilize some of these tokens in here as well. Find it contact name. Let me run it somewhere. There's a little filter up there too, so it might be easier to look at the filter. And specify that high technician has sent you an email and then maybe format that just with the time entry notes formatted. That way the end user doesn't get a full list of all the history of the ticket. Maybe they just want to get an email with a later response from the technician instead. And to specify this with HTML, if you hit this little source button up here, it'll give you a full HTML email editor. Again, it's nothing fancy by any means. Most of my partners do configure this inside some sort of external system like a Dreamweaver, and then once they build it out in there, just copy the source code and paste inside of here, and it does a pretty decent job getting that into like an actual brandable HTML email template. So for the close communication to your clients, they'll want to have a better experience than just having that weird blue frame background instance of on the emails from ConnectWise. Moving along, another area that I see a lot of partners not have configured is how their technicians are actually getting the updates from the service ticket. So since we don't actually have this resource box enabled, whenever communication gets updated into the service ticket, we're not actually setting that to the resource as well. So what you should be having in here is underneath this customer update notification section, we have the ability to notify different members of the team, and usually what I suggest is to send an email notifications to all assigned resources whenever someone from the client perspective updates the service ticket. That way, you don't have to wait for a workflow rule to run in five to 10 minutes to actually get this thing along. As soon as the email gets updated into the service ticket, it starts to populate here as well. I'll get my friend over here, if he's, you can see him on the side. So if I hit this little save button here, basically any time a resource updates that service ticket, he's able to, or any time a contact updates the service ticket, that assigned resource to the ticket also receives the email copy. Final thing on this board tab I want to show you is going to be allowing the email connection to reopen some closed tickets. So for the longest time, we only have this option here to never reopen a ticket created more than X days ago. Maybe the last two or three years, we've added this option that a lot of partners have not enabled to allow ConnectWise to reopen a ticket closed more than X days ago. So that way it's looking at the closed date for the rules for reopening rather than when it was created. But typically I see people do maybe like 7, 14 or 30 days. So if a client does want to respond back to a closed ticket, it reopens it within a certain threshold rather than worrying about when it was originally created. So I'm going to move along on the statuses tab here and start talking about some SLA configurations inside of the service board, because this is going to be the main driver to figure out if you're meeting your SLA requirements to your clients, or at least for your internal reporting efforts. So each of these statuses are going to be associated with a certain escalation status. And this really tells where in the life cycle that ticket is currently up to. So we only have five escalation statuses inside the system. They're all hard-coded and it generally follows that we have not responded. So we have received the ticket, hasn't been triaged, hasn't been responded back to the client yet. This starts the SLA timer to figure out that if I need to have a response to my client in let's say one hour standpoint, and the ticket gets created at 10 o'clock in the morning, this is going to start counting how long the ticket stays in a we have not responded to status until we move it along to something like a we have responded to. So it's changing of the service ticket statuses is really what's going to drive the SLA reporting, and then making sure each of our statuses are associated with the proper escalation status. So general flow, we have not responded as like a newer triaged. Once it does get triaged and signed out to our resource, you'll need to change the status here as well into an assigned status. So it stops the initial response timer SLA on the ticket, and it starts capturing at least the plan, the resolution still. After it keeps getting worked on from assigned into something like an in progress, so the technician's actually working on it, that will stop the plan timer, and it'll continue just to calculate against the resolution timer on the ticket. Once it has been set to a closed status or let's say a completed status, then it's going to be associated with the escalation status of we have resolved the issue, which is basically going to stop the SLA timer on the ticket as from an MSP perspective, we've completed it. There's no longer any sort of followup needed on this one. It's done in the system. We have this fifth escalation status called we are waiting to not escalate. And what this means is the next action is not on the MSP to complete. So the next action's either going to be on the client, so such as if I'm waiting on the client response to let me know if it's done or not, or if the action's on like a third party, maybe if you go out to some sort of DST or some sort of vendor to get information about a particular issue that's outside of the MSP's route. These statuses are like a paused waiting status, so it no longer starts calculating time against the overall SLA goals. And it essentially sets this ticket to wait until there's an actionable status required by the MSP. Now, the problem I see with these statuses sometimes is some partners might set a ticket to like waiting on customer response, and there's no sort of followup. So it kind of sits in here indefinitely. So that's where we want to start coupling things like workflow rules to be able to make sure we move these ticks along, and they don't get stale in a certain status for X amount of time. I'll touch on that in just a bit. So outside of the escalation statuses and maybe where they can configure them, you configure them just underneath the actual status description up here, and you can specify where in the lifecycle this ticket's currently at. Something pretty handy as well, documentation around this. We do have a pretty good escalation status example list that kind of shows you real life lifecycle, where the ticket's currently at, and what types of tickets should be underneath what types of statuses. For an area inside of ConnectWise called status notification emails, we can specify that whenever a ticket is set to a certain status, ConnectWise will send an email out to a certain party. This is typically used for whenever a ticket's in a new status. So as soon as the ticket gets created, it gets defaultly created into a new status, and immediately I can kick an email response out to whoever actually created this ticket. So once this is set up, it's down here in this overall email template, and by enabling this external contact notification box, I can tell ConnectWise that whenever a ticket is set to this new status, I want to send an email to the contact for this item. And you can specify a few different people you want to send to. Typically, it's just going to be the contact for this item, or something like maybe a CC for this item, if you wanted to have both the contact and the CC receive the same email. And what that email typically looks like is something like, hi, we received your ticket with a summary line, and this is your ticket number. And it has a bit more of information inside of here. Again, you can use HTML email templates if you want, where the client gets in the meet, and they kick back to saying, hey, yep, I've sent through a ticket, I've sent through an email to my help desk team, and this is the ticket that got created from it. You don't want to get too, too crazy along here with having status notification emails for every single one of your statuses, usually like the new status, or like a closed or completed status, or the two typical ones I see partners do. You can also do stuff like a, maybe a tickets have a schedule status, as you want to let the client know, hey, we scheduled someone to follow up on this particular ticket. And there's some different tokens in here we can do as well. You'd be like, it's scheduled for this, and it's looking at the next scheduled record on the ticket to let them know that Kyle scheduled to work on it on the 24th of February at 1 p.m., for instance. So the client can get the right expectations for when the resource has been scheduled to follow up on this ticket. Okay, I'm not really going to touch upon the types of types and items. Those are more or less just the classifications of the different service tickets from a reporting standpoint, for the most part. Every partner does them a little bit differently. General rule of thumb is I like to tell partners have less rather than have more, typically if they're not already in use, because if you have a list of like 20 different types, subtypes and items, your technicians are going to get confused and just start selecting any old one. We have, with the addition of Keck by Sidekick, we can at least have the AI try to do the automatic match for them and take the guesswork out of the technician standpoint. But if you're just starting off with types of types of items, generally maybe five to 10 is all you really need, maybe five types, five subtypes, five items. So I'm going to pivot here into actually looking at the overall service board inside of ConnectWise and show you what I like to see as like a service delivery manager looking at my service tickets. Now, within this screen, we do have a lot of optional customized list view options inside of here. So if there are some additional fields that you want to unhide from the overall list view, you're able to do so by clicking on this little gear icon here. Maybe I want to see the schedule information, maybe I want to see the next date information, as well as maybe what service board it's currently on, especially if you're looking at a service board with multiple different boards on there, I have the ability to kind of see all that level of information on it. I can also customize how many are showing per page. So I'm going to probably show 200 per page because I want to see a list of all my different service tickets. I have this thing filtered out just to take a look at my service dashboard. This will allow me to see all the different service boards I have inside the system here. And from a configuration standpoint, I'm going to start moving around some of these columns here. Go ahead, good old drag and drop. And to have the configuration look something like this, where from a glance, I can see that most of these tickets haven't been updated since the 20th of February, and they're not showing me any sort of next date for when the resources are scheduled along with it. So something I usually do when I do an audit of someone's ConnectWise instance is I have them go through their, basically open up their service board, we'll filter out, we'll see every single ticket across every single board, and I'll start to look through, cool, of all these tickets, when the last time this was updated, and I'll see records like this. This guy hasn't been updated since March 22nd, 2025. So if you do this inside of your own environment, and you start to see things like, yeah, this hasn't been updated in over a year, very likely you're not going to do anything with this ticket anyway. So my question for you is, why is it still open as an actionable item? Really, anything open on your service board should be considered an actionable item, and something hasn't been updated in that long, then there's not really a reason to keep it open to continuously work on the issue. Looking the other way here, maybe I have some tickets here as an endpoint, yeah, Linux server endpoint reporting offline. The other way I like to look at the service board is based on when the resources are actually assigned to these tickets. So let's say this one was supposed to be worked by me, back on the 19th of February. If I add myself onto the ticket with a past date resource, it's going to show on this overall list view that, hey, this thing has only been scheduled in the past, therefore that next date field is going to show me in red. And from a service delivery management perspective, I don't really want to see anything I don't really want to see any of the reds on these boards that are showing me as previous dates, especially if it's at a ticket like in a schedule status. That just to me tells me that the technician hasn't actually planned ahead of what they're going to do on next with the ticket. And that's where I want to start to find some exceptions, like, hey, this one was supposed to work on the 19th, what are we going to do on it next? What we want to be able to see is, if we're continuing to schedule resources out in the future to either follow up on it, or if there is a schedule quality in a week from now, I want these things mostly scheduled out in the future. So that when I go back to my service board list view, it'll show it in black, meaning it's sometime in the future, it's essentially still in compliance, nothing's added to it. It's at a date when it comes to this. So speaking about scheduling, and I want to move across into some of the dispatching components of ConnectWise. So dispatch portal is probably one of the most powerful areas inside of ConnectWise. We have a few different views. I'll kind of show you my personal preference of how I see partners get the most out of the dispatch portal. Typically, I like to do the day view. And then there's a little option on the top right here. This is the view dispatch only. We actually have a dropdown to do a split screen here between the overall service boards. So maybe I want to filter across to my service desk and see which tickets don't have any sort of next day honor or anything that's kind of pending as last updated. So an area dispatcher can really utilize here. If I grab those same kind of hidden columns like the next date, that should be all I need. And then drag and drop this guy over. Same thing in the last updated. I can go ahead and drag and drop onto the different technicians' calendars. Be like, yep, I want this guy to work on this ticket. And then as soon as I refresh the page, it's going to show me the next date field already available inside of here. So this is pretty handy from a manual dispatching perspective. There are some things we can do with the automated dispatching as well. A bit more niche than what we're going to be able to cover off on today. By at least getting these tickets and getting lots of the resources, this is the easiest way to be able to do so inside of ConnectWise. And we can also see their overall capacity planning inside of here. Now looking at Barry, he's showing 100%, but that's not correct. Maybe he's only able to work eight hours per day. Well, I can start to specify what the overall schedule capacity goals are based on the different members inside of the system. So I go to Barry's member profile here. There is a field underneath the scheduling section called the schedule capacity. And let's say I want Barry to be able to have the capacity to work eight hours on tickets today or in general per day. If I specify that and come back to the dispatch portal, it will now show that Barry's in the red because he is only scheduled 0.5 hours of his available day. These fields are configurable based on the scheduling color setup table where you can specify different color codes for your dispatcher based on how many hours and how much percentage is being assigned to the resource. And let's say if I want to go ahead and say, this is actually going to take you all day. He's showing out 50%. So this guy moved across into yellow. And then if I expand this guy out to let's say a few more hours here, he's showing it's green at 78% scheduled for that day. From a technician standpoint, rather than having to live inside of the overall service board in the dispatch portal, there's a very similar view they can utilize. It's kind of hidden underneath the sales area, but most times I like to tell partners to make this the favorited. So the my list view. Sorry, it's giving me the my calendar. And it's giving me the my calendar with my list. So if I really, really care about my own calendar for the day and for the week, I can configure this screen. So as soon as I log into it and look at my calendar, I can see all the tickets that are currently assigned to me. And I can start going through what's actually most important for me to work on for the day, rather than having to look at the overall service board view. Especially if I've got tier one resource, I don't necessarily need to look at the service board. I'm getting tickets fed to me. So some more best practice configurations I've ConnectWise is actually closing out some of these service tickets. Now, pretty common practice is most partners set up like a two-step closing process. So that once the work on the ticket has actually been completed by the technician, we actually don't give them security permissions to close out their own service tickets. We allow them instead to set a ticket into like a complete service ticket. To set a ticket into like a completed status. And what that looks like from a service board configuration setup is we have a completed status here. That's technically, that shouldn't be closed. I'll unclose that. So we'll have a completed status which still resolves the SLA. So the SLA resolution timer doesn't continue to calculate on here. But it's technically not closed inside of PSA system. Reason why we do it is we don't want to, especially if you have rules inside the board where only going to be able to build tickets after they've been closed. I don't want something immediately flowing into the billing component of ConnectWise until I have some sort of service delivery manager, double check the work on it, check for spelling, check for the right agreement on that and so on and so forth and give it a quality control before I actually push it across into the invoicing process. So what that would look like from a end user perspective is if I filter this guy again by my service board. And let's say this particular ticket. I would set my ticket into a completed status. Cool, so it still lives on the service board. Should live on the service board. I did just make that edit so it might take me a second. Try that again. Alright. I'll try that again. Nope, didn't look like that either. I didn't actually save the change there. So what's happening is these tickets are going to be sent into a completed status and then your service delivery manager will have a view on the service board where all they'll need to do maybe once a week is to review all the tickets to complete status. And then we can specify that. Status. Is equal to completed. And it should be able to pull up all those tickets in a completed status. I'm just conscious of time. I'll probably go for another about 10 minutes before I open up for Q&A. Other main area of consideration when it comes to service service delivery type connect wise is some of the workflow rules. So I'm going to concentrate mostly on the classic characterized PSA workflow rules to be able to do front some sort of automation inside the system to make sure these tickets aren't getting still along the way. Now, probably the most common one is going to be the service customer responded change stats. And what this situation really calls for is whenever a client responds back into a service ticket, by default, connect wise flags a tick box that says customer updated, but it doesn't automatically change the status of the ticket into like a client responded to level status so I can code a workflow rule so that as soon as I see that flag enabled on this particular service ticket, I can move it across into a customer responded to level status and. Be able to prompt my technicians hey so and so go back to you. Let's go ahead and follow up on that. So typically a rule I would build out for this is going to be only looking at tickets that currently open. Now I need to start querying my entire closed list of tickets in the database. So at an end operator here. And I'll say that maybe a ticket is has had a customer updated. And it takes, but up to about customer updated. So I'll say that I'm going to say that I have a customer updated. And it takes, but up to about customer. To give you an idea where that lives inside of the actual ticket. As you mean, this little flag right here, customer updated. And that's what makes the ticket bold on the actual service board. And then maybe I really want this rule to run on whatever tickets currently in like maybe a waiting client response time status or some sort of series of statuses. So I can kind of create a. A. Big or statement inside of here so that once these two things are met. I can say. And it's in one of these particular statuses. Say, and it's in a client. Response status. Or. In the status of. Maybe completed, maybe the client didn't actually see that the ticket was was actually resolved. They want to respond back to the completed status. We can kick that into like a customer response level status. So as long as the tickets open in that box is ticked and it's one of these two statuses. I want connect wise to automatically change the status of my service ticket. And I'll set that status to customer responded. Now I think these workflow rules by default. The run schedule is set to just once on these tickets and what that means is any this is this workflow rule action is only going to run one time over the entire lifecycle of the ticket, which is typically not what I want, especially for like a customer response level workflow rule. I want it so that as soon as this criteria is met, no matter how many times the customer response back to me every single time, I want this to be able to flip into a customer responded to level status. To do that, I can adjust the run schedule. And set this guy to run continuously. Let's say if it can, I want to change the status every five minutes. So that as soon as that customer responded to has a customer, I want it immediately to go to a customer responded to status each and every time. And as soon as it moves into customer responded to status, it's no longer going to meet the criteria of this workflow role because it doesn't meet that tickets currently in a waiting customer response status or completed status, so it's not going to continuously loop. So this one run schedule how many times the actions going to perform in the service ticket. And then this activate. After I tested, this activates going to tell me how often characterizes going to query the database. So I probably want to query the database maybe 5 to 10 minutes. There's a schedule task on the cloud that runs about every 10 minutes on the parameter runs about every five minutes, so you can't make it every one minute, but it's just not going to do it. It's going to wait for the schedule task to catch up. Now maybe I want to run every 10 minutes during my company office hours. And now it's going to continuously monitor all monitor all those open tickets on that board for when the clients to respond back to us so we can immediately update the status and know when I need to respond back to the client. The other major workflow rule I see partners do is going to be around making sure these tickets don't get stale in a waiting on client response status. So within this workflow rule, maybe I have some tickets on my board that are in a waiting client response status, and rather than make my technicians manually follow up every X amount of days, I can automate this within my service board to say hey, after three days if no one's responded to a ticket in a waiting client response status, let's send an automated email back out to the client and let them know. And then I can also automate this within my service board to send an automated email back out to the client and let them know is this still an issue with you guys. So in order to do this, I'll specify that ticket is in status of. Of waiting on customer response. I'll say and has been updated. For more than three days. Well, same idea. I don't want just to run once. I want to run continuously. So anytime if a ticket gets stale and it gets reaction again, I can have this thing continue to fire upon it. And usually I advise is rather than taking email from the workflow rule itself. All I wanted to do is change this ticket status. I'll change this ticket ticket status to something like a still issue status or like a even like a completed status or pending response type status. Just to let them know that hey, a ticket is in a waiting in client response status as an action X amount of days. Maybe I want to put the status and then send out status notification email to the client and then after I've changed the status is maybe another two days goes by and the ticket still hasn't responded back to you. That's when I can send it into my closed status. Just gives me like maybe a five or seven day window to let the client know. I have tried to follow up with you automatically twice. You guys haven't responded back to you. We're going to assume that the ticket has been completed and it should have resolved. If it's not, please respond back to us so we'll be able to continue to work on the level issue here. Don't have the still issue status on this board right now. I'll just do needs info. The second one will be ticket status. Is in needs info. And. Updated more than two days ago. Then from here. I'll update the ticket status again. And set this guy into a resolved status for instance. These ticket statuses change are going to be coupled with status notification emails. That let's say whenever a ticket does go into a needs info status. That's where I could specify. To the email to the contact on the ticket. Let them know hey, been three days. Haven't heard that. Is this still an issue? Obviously you probably tap it out much nicer than me with some HTML in there as well. As long as we don't have to go back and redo the whole thing. I'm not going to do that. Much nicer than me with some HTML in there as well. As long as we have the. I'm going here for the ticket number. Somewhere in the subject line. And the response back from this email is going to update the original service ticket and let the technicians continue to know that head is actually still an issue or it's going to be a hey thanks all good type closed issue. I guess I'm going to open up the Q&A here if you guys had some specific questions or areas wanted to kind of know a bit further about just open that up now. We have any questions already inside. I got Mike GM a schedule of and links of upcoming sessions seems a bit of it, but how we hear about these? Yes, so we're going to be running these sessions every week for the next eight weeks. I believe so. To me at the same time and same place just to give you an idea. Next session is going to be around agreements on next Tuesday. Move across into some sales, invoicing, financing the week after project management, procurement. Miscellaneous areas and then an open Q&A level session. I'm not sure if Asher to answer that question for you. Yeah, so we'll be able to send that across to you as well. I'll work with the marketing resources to send across the full list. This is going to be a webinar series, so we'll be able to have all this stuff recorded as well. So in case you do miss the session, you'll be able to catch the recording later on. I was not going to miss the mirror. I missed the show and service board. If it was like that I'm going to be angry. Yep. Amir nailed it, thanks Amir. That's why my completed stats wasn't showing there. Yeah, we will be able to get a recording of the session even after their attempt to session. We're going to be posting all this on on YouTube to be able to document this, because ideally we want this to be available for our partners as a continuing Singularity engagement. So we're doing this for you guys and happy to share the recordings once they're made available. I'll work with the marketing team to figure out how we're actually communicating that with the with our partners. But yes, that's that's the idea of these sessions is. Do it for you guys. Give another 30 seconds or so in case anyone has any other questions. Alright, I think that'll be a wrap for for today's session then. We'll go ahead and get this recording online and share it with the other resources, both in attendees as well as those who weren't able to make it today, but hope you guys learn something from this session today and our next session on Tuesday is going to be around some agreements set up inside of connect wise, so it should be a big one. Lot of information to jam pack in there and hopefully able to break it down and get you guys the most out of connect wise. You guys enjoy their today and will speak next week.
