[4] Ticket Notifications

Welcome to PSA Impact, your podcast for all things PSA, RMM, and MSP, with your hosts, Raeann Buccianico and Chris Tim. Learn how to get the most out of your PSA tool and manage your business by maximizing profitability and increasing efficiency within your MSP business. Let's listen in. Hi, everybody, and welcome to another episode of PSA Impact with your hosts, Raeann and Chris. With me, I have my co-host, Raeann.

So, Raeann, I was thinking of some topics to talk about today. And we, just before we started recording, we had a very quick chat about this topic. I was out with a customer this week, and we were talking about, you know, how to notify customers on tickets, on updates on tickets. So, I just wanted to kind of get your thoughts on that, and, you know, when you're talking to your customers in your business, how do you actually notify them on tickets? That's a really great question.

I'll bet it's one of your favorites, actually. It's always my favorite. But, seriously, so when we get the ticket coming in, the ticket notification goes out to the customer. Hey, we received your ticket, thank you very much. And then the ticket lands in our workflow.

And so we work on the ticket. Generally, we don't notify the client every time we touch that ticket. However, if the ticket came in through the portal, they will have the ability to see all of the activity on that ticket if they're logging into the portal, and they post the ticket there. If the ticket comes in through email, it's probably not hitting the portal, so they're really not going to have any visibility of it. Every time we work on a ticket, we log our time, we put in what we've done in the summary notes, and we generally don't notify the client after every time entry.

I think that's just a little overkill. The only exception to that might be is if we're logging our time, putting in the summary notes, and we're changing the status to waiting on customer. That means we need some feedback from them before we continue. And so that's probably the extent of it. And then when we close the ticket, we notify the client because the ticket's been closed.

We don't often send out those surveys like we should, but that's a different topic. So what are your thoughts on this? So yeah, you've got some great ideas there. I mean, it's pretty much exactly the way that we do it. So when I spoke to this client during the week, I said to them exactly that, right?

We only send out a notification when the ticket is first created. So that's, you know, thank you for logging the ticket with us. Your ticket number is X, Y, Z. And you know, at any time you can just respond to that and, you know, update us on whatever you want to update us on. And then what we do is we then send a closed notification as well.

So we don't send them on every single little update that we do on the ticket, unless of course, as you say, you know, the customer specifically asks us for it, or maybe it's a particular kind of customer where we need to do that. So we'll have some workflow rules set up where we say, you know, if it's a particular customer, maybe they're a Platinum Managed Services customer, and we want to let them know about every issue, then we'll certainly do that. But otherwise, we give our engineers the ability to pick and choose when they send out that email. So when you do log that time, does the customer ever see the entire thread of time that's on that ticket? Do you send it on the invoice, for instance, or do you give them a report at the end of a ticket?

So what I'm talking about here is a ticket comes in, there's a specific task that needs to be done, and you're working on it, but it may take multiple touches before it finishes. Does the customer ever see the multiple touches, whether it's on an invoice or a report? Do you ever do anything like that? Great, great question. And the answer is, it depends.

It really does depend on the customer. So again, some customers don't really want to see that. All they want to know is that the ticket is closed. They don't really care what's been done to close that ticket. There are some who want to know every step that you've taken to solve that.

So with those kind of customers, we'll give them the ability to log into the portal where they can then go and see any of those updates if they really want to. Or as you say, we may just send them out a report on that, or we may send them that as part of the invoice, whatever the case might be. But it really does depend on the customer themselves and what information that they want to see specifically on that ticket. Yeah, that's a really good point. Generally, we put all of the ticket entries, the ticket summaries on our invoices.

But it's often kind of hunched together, right? So the tickets on the invoice are not necessarily in chronological order of ticket number. So it's not like you can follow ticket all the way down. It's really more based on date order, I think. And so the invoice itself might be difficult to read, now that I think about it.

So I wonder if there's a better way to do that. Maybe we could sort the invoice instead of date order. Sort it in ticket order, so it might be a little more chronological. Yeah, I mean, there is some level of customization that we can do on that. I mean, again, to be honest with you, I haven't seen that many instances where the customer has necessarily wanted to have any of that information.

I don't know what it's like over that side of the pond, but certainly here in the UK. At this point, I'm sort of listening to people dialing their phones at the moment to tell me otherwise. But certainly from the experiences that I've been in recently, I haven't seen that many people that have wanted that level of detail on the invoice. So I don't think it's too much of a big deal. What I would rather do is send out a report to the customer.

If they ask for it, I can send out a report and say, this is the work that we've done on that ticket and this is who dealt with it. This is how much time we spent, all of that kind of thing. Interesting. So many MSPs over here, some of them say, I don't want my customers to see anything. One line, monthly MSP service, pay this amount of money.

Others are like, let's tell them everything. And so they end up with invoices five or six pages long, outlining every ticket and every summary note right on that invoice. I think there can be some sort of happy medium here where it's not one line and it's not five pages long. I guess that's a topic for a different day. We'll talk about invoices one day.

Absolutely. So to shout out, I guess, to anyone who's listening then, if you've got a different way of doing it or you want to phone in and tell us off, then by all means, do that and visit our website, leave us a message, tell us how you guys do it. I would love that. I always find it fascinating how MSPs inform their customers what they're doing and how often they're doing it and what level of detail they give to them. Absolutely.

So actually, another one that kind of leads off the back end of that, and this was a really interesting conversation I had with basically the same client, was about when you send out that close notification, very often MSPs will send that close notification from support at and with the ticket number in the subject to, of course, which your customer invariably will reply saying, thank you for closing my ticket. And of course, it reopens the ticket. So he asked me for a way, how can we actually get around this and how can we stop this from happening? And there's actually a very, very simple way we can do that. And that is simply send the email notification on the close notification from do not reply at and don't put the ticket number into the subject line.

And then have some wording in there, which is what I do all the time. Just have some wording saying your ticket is now complete. If this was an error or you just want to reopen the ticket, then send us an email to support at and reopen the ticket. And then we can do some internal stuff by merging the tickets and what have you. But you encourage your customers to essentially create a brand new ticket rather than replying to the one that's there already.

That's really interesting, you know, because what I have done is, and I had not considered sending the email from a do not reply address as opposed to the support at email address. What generally we do is if a ticket is closed and then it gets reopened, we'll set up a workflow rule that if it hasn't been touched again in two days, it automatically gets closed back out. But I think I like your plan even better because this way, you know, you don't have those rogue tickets out there just waiting for somebody to look at. It's just something for somebody else to look at, something for somebody else to touch. And I think I like your plan better.

I'm going to have to try that. Thanks. Great tip. Absolutely. I mean, it's actually something that's built into the notification rules and the workflow rules, certainly within Autotask PSA.

I'm not sure whether ConnectWise has the same or any of the other PSAs have the same. But certainly, you know, from an Autotask perspective, you can use a different email address to send that notification out from. So that's all we do is send it out from do not reply, which actually is a valid email address. To be honest, all it does is if they did reply, it just pops back into an email box that we can read, but it doesn't then go and recreate and reopen that ticket. So at that point, we'll then know which customers have not read that email or not read that notification that's come out.

And, you know, again, that then allows us to educate those customers or whatever the case might be. But we still know about it. So I know a lot of MSPs at this point are probably thinking, well, we'd never put it to a do not reply because we want to know if the ticket's been reopened. But you can always just have it as a valid email address, but just tell your customers do not reply to this. OK, so one last follow up question on this.

What are your thoughts on sending out those those ticket surveys every time a ticket is closed? Do you send out a survey, you know, with the smiley face, the frown face or, you know, the plain face? Do you do any of those things? Personally, no, I don't know of anyone who does them. And and if if I'm really honest with you, I actually hate them because I don't think people really, really do those surveys, really respond to them.

You know, I find very often people just ignore them and maybe because they either don't know what to do with them or they just get too many of them, whatever the case might be. So what I would rather do rather than sending that off the back end of a of a ticket is, you know, have somebody in the office maybe randomly call up the customer and say, you know, we just closed the ticket for you this week or last week or whatever the case might be. And, you know, how did you find our engineer? So we find that that actually works a lot more effectively when somebody calls the customer and asks them that rather than it just something coming out of a, you know, out of a ticket closure email or something to that effect. Oh, that's interesting.

Yeah, I don't do them either. And and it's not that I'm opposed to them. I just don't find an awful lot of value in them. And you're right. People don't respond.

Every time I call up Intuit or QuickBooks for a support issue, I get bombarded with, hey, don't forget to fill out our survey. How did you do today? Would you, you know, would you recommend QuickBooks based on your experience with us today? And, you know, so if I get one from Intuit, if I get one from Build.com, if I get one from my IT person, you know, all of those things, I think it's a little too noisy in my already very noisy inbox in my email. So I also am not a huge fan of the every ticket survey.

But, you know, maybe if you wanted to do one a month at the end of the month, send them out. Hey, how did you like our service this month? Are we doing better? Are we doing worse? I'm not opposed to that.

I think that's a lot less bothersome. Absolutely. No, I would fully agree. Personally, though, I still don't like them. And I do that from personal experience because exactly the same.

I'm getting calls from people all the time going, can you rate our service? Or, you know, recently my wife and I flew abroad and, you know, literally within an hour of us landing, we got a survey from the airline saying, you know, rate our flight. How did you think it went? You know, and to me, I think it's an overkill and I really hate them. I just delete the emails and don't respond to them.

So but, you know, they certainly have their place. And so I think it is something you absolutely could. And if, you know, if you wanted to, you know, get those kind of answers from your customers and see how you're doing and improve your service, then by all means, go ahead and add those to the Closure email as well. So on that note, everybody make a mental note. Don't send Chris Tim a survey on your service because he probably won't answer.

Just teasing, of course. I definitely won't answer. So you might find your email being deleted. So I thought we had a really, really great conversation here today. We kind of touched on a number of subjects.

We started off with, you know, the tickets and how often do you tell your customers what you're doing on those tickets? And we kind of took it all the way out to the end through the survey. So great topics today. And I really, really want to see more about the how to change the email address on on those closed tickets to have it go to a Do Not Reply email address. Absolutely.

And I can certainly show you that, you know, obviously that's something I reserve for for my clients that I charge consulting fees for. But as it's year A.N., I'll absolutely show you how it works. Thank you. Yeah. So great, great topic.

Great conversation, Rayanne. Your PSA is the key to your MSP success. Go out and make an impact today. Thank you for joining us today on PSA Impact. We hope you've learned something and that you'll join us next time when we answer new questions posed by our listeners.