In this episode, we discuss how to respond to troubleshooting calls.
You will learn how to apply the five-question methodology to pinpoint troubleshooting issues and how to potentially address the issue before even showing up on site.
Click here to download or listen to this episode now.
Resources mentioned in this episode
Show notes
Phil Zito 0:00
This is the smart buildings Academy podcast with Phil Zito Episode 235. Hey folks, Phil Zito here and welcome to the smart buildings Academy podcast and in this episode, we are going to be continuing to dive into troubleshooting processes. We are going to be doing a recap of our previous episode and we're gonna be looking at what exactly happens when you're called out for a troubleshooting call. What do you do? How do you approach it? And what can you do to make the call more effective? This episode is sponsored by our troubleshooting bootcamp. If you are looking for the quickest way to learn how to troubleshoot, building automation hv AC control it and protocol issues, then troubleshooting bootcamp is the course for you this completely online course will teach you everything you need to know in order to start troubleshooting common and uncommon issues that you will find in your building automation career journey. So if you're a service tech, operational technician, controls engineer, anyone who is encountering control systems and building automation systems on a day to day basis, then make sure you go to smart buildings academy.com and check out our troubleshooting Bootcamp, you can get a direct link to it at podcasts, smart buildings Academy comm forward slash 235 scroll down and you will see the troubleshooting bootcamp link. Once again, that is podcasts at smart buildings academy.com Ford slash 235. And you'll be able to find the troubleshooting boot camp link, I encourage you to take advantage of that link this week, because we have a special on troubleshooting boot camp where it is 50% off until January 22. are right so last week, we started to go through the troubleshooting process, which is a four step process, we have to go and identify the desired state, identify the actual state, identify the root cause. And then we have to solve the issue. That's our general troubleshooting process. So last week, we went through three scenarios, we went through a no heat at the terminal unit level scenario, we went through some BACnet mstp devices being down. And we looked at an air handling unit being down. What we really need to focus in on this week is when we arrive at the site and actually prior to our arrival to the site, what can we do to increase the likelihood that we are going to be able to completely resolve the issue in a quick and timely fashion and get the customers systems back up and running? Well, in order to do that, we really have to flush out a series of issues. And our first issue that we need to flush out is what exactly is the issue, oftentimes our dispatch, if we're working for a service contractor, or our help desk, or you know, our work order desk, if we're working as a customer is going to get a complaint, but that complaint is going to be severely lacking in detail. And maybe it's not severely lacking, but it's usually going to be lacking some key points. So I want to take a look real quick at the five questions I like to focus in on when I'm first going to talk to my dispatch when I'm showing up at the site and talk through the document gathering process and talk through how all of that kind of plays together. The reason I'm doing this actually is part two instead of part one, because logically you would think to yourself, well, wouldn't you want to have taught us this in part one. And if you're listening to this in the future, you may be tempted to not go to Part one first and go through this first, the reason I wanted you to go through part one first, which was more of focusing on the troubleshooting process. And focusing on those examples is because by exploring those examples, understanding what it was we looked at when we are troubleshooting a terminal unit, understanding what it was like when we were troubleshooting that BACnet mstp system or that air handling system. But understanding these approaches and these interactions and kind of where we were at. What we are now going to be able to better understand is what questions we probably want to ask and the importance of these questions.
So the first question I like to focus on is related to frequencies and relationships. And I have kind of three questions I will go through and I don't necessarily ask all three questions and I may deviate from this format. But the generic format is when did this issue start occurring? That's basically what we're trying to Figure out here. And we're looking for patterns, what we're looking for are time and frequency. So if it happens at a specific time, maybe not always frequent, but at a specific time, that could be a sign as to why a failure is occurring. If there's a frequency to the failure, then that could be a sign. So understanding these frequencies and timings really gives us some clarity on the issue. You know, I recall being called to a school, an elementary school that was being used after hours, and getting a troubleshooting call and the troubleshooting call, basically, what they told dispatch was, every time that we have this meeting on Tuesday nights, it's hot in the building. Now, hopefully, your brain immediately went to where I my brain went, which was system even on I mean, if it's after hours, and they've got the system occupied during certain hours, but unoccupied during after hours. And this is only happening on these Tuesday meetings, then that's the first part place where my brain went. And that's actually what it was. I mean, it was really simple. I didn't even have to go visit the site. I just simply said, Oh, that's interesting. Let me call the customer back. And I called the customer back and I said, is the unit even scheduled to be on? And he goes, man, I'm so stupid, I'm sorry. And I was like, No, it's okay. It's okay. Don't worry about it. He felt horrible that he didn't even think to check the schedule. And that's actually what it was, it was that the system wasn't even scheduled to be on and it was an unoccupied mode, of course, it was getting hot in the space, you have all this thermal load coming off of these people. And I would have otherwise, if I didn't think to ask, When is this occurring? If I didn't think of that pattern, I could have driven out to the site, and had to charge the customer for our minimum three hours. Instead, I called I spent a minute on the phone, solve the problem. And actually, we had some work that came out of this down the road, because, you know, I didn't make it a big deal. So there, you know, leadership didn't realize that the guy didn't know to check the schedules. And he kind of appreciated that. So when it came time for looking for who they were going to give some work to. Our name naturally came up. So it worked pretty well. Things were pretty good. Alrighty, so the next thing, we need to determine what if anything has been done, the most important thing when troubleshooting in my experience has less to do with what hasn't been done and more what has been done. Know, we've all been to that job site where the person tries to fix it themselves. And they put things in hand and they alter stuff, and they sometimes forget that they've done these things. So understanding has the system been taken out of service? Have you modified it? Have you done anything to fix the issue? Have you put anything in hand, all of these questions they really help us understand. And these are questions that you can have, either when you show up, or you can have with the customer over the phone, I mean, ideally, this conversation with the customer over the phone should take 510 minutes, tops. If you're going longer than that, then you're taking too long. So at this point, we understand the frequency and relationships, if any exist, we understand if anything has been done. And now we need to understand the conditions, right? This is where we start to say okay, do you have any documentation on the system? Have you done any maintenance? Is any work being done anything like that? Oh, by the way, can you pull the documentation and email it to me. So I can have a look before I head over. So I know if I need to bring any parts or anything like that. Because for example, if you look at an air handler, and he said, you know, the air handler keeps tripping out on high static, and we've checked the high static sensor, it's fine. Maybe you're gonna bring a new high static sensor with you. But the only way you can know about that new high static sensor is by going and actually having that information upfront, right. So you want to understand the conditions, you want to understand what the site is like, what's there. These are all questions you're going to be asking. From there. We move on to question four. I mean, what is really going on?
who observed the issue? What made the issue come to your attention? What was the initial complaint? What did it look like? How did you detect all these kind of discovery questions? And once again, at this point, you should not be spending a whole lot of time just basic, who observed it? Is that person going to be available for me to talk to them? Is it still occurring How do you know it's occurring? etc? And then finally, question five, we want to determine if it's an issue with the system or if it's an issue with changes. So we want to understand, do you have the previous set points? Do you have the data? What should the system be controlling to? Has there been any recent changes? Now, I will tell you oftentimes, the customer cannot answer these questions, especially if you're dealing with like, you know, a janitor or someone like that, Who's most likely at the site after hours, they will not be able to answer these questions, however, and you'll be able to tell that right away, by the way, however, you should ask these questions if you get someone who's capable of answering these because oftentimes, especially in nowadays, with remote access, you can resolve these issues before ever even visiting the site. Okay, so at this point, we've asked five questions, we've tied up our frequency and relationships, we've looked at, what if anything has been done, understanding the conditions, understanding what really is going on and determining if the issue is with the system itself, or with some changes that have occurred? Now at this point, we want to go and actually do some document gathering. So we're going to show up at the site, we're going to get the latest as builts OEMs, if possible, and we're going to have the customer take us to the issue. And now we're going to start to work through our troubleshooting process, right, we're going to find out the desired state, we're going to look at the actual state and then we're going to find the root cause we're going to identify any interrelated issues, we're going to identify any multi layer issues. If you're like, what's interrelated issues and multi layer issues, then you need to check out our troubleshooting bootcamp webinar recording, which will be available for you to sign up and watch at podcasts, smart buildings Academy comm forward slash 235, I highly encourage you to watch that webinar, it's completely free, check it out. Alright, so it's at this point that we gather our documentation, and we begin to work through our troubleshooting. So we're gathering MEP sets, we're gathering specifications, or gathering any controls submittals, or gathering any data from the building automation system and historical logs, trend logs, we want to get a good sight picture of what's going on. Now, obviously, if it's something blatantly obvious, like the air handlers not running, it's tripped on high static code, check the air handler, go figure out why it's tripped on high static, take a look. You don't have to necessarily gather all these documents before you go look at that, it may be something super simple. However, it often is not something super simple. And that's why you're gonna want these documents. Once you have these documents, you'll want to go through these five questions one more time, because it's likely at this point, that the person who maybe was on the phone and was not able to answer the questions for you may have been replaced by someone who's a little bit more experienced, especially if this is a critical environment. And you can ask these same questions again, also, and here's like a pro tip is when you're asking these questions, you don't necessarily need to be asking a person, you can be asking the system. Now what would that look like? If you were to go and say to yourself, has anything been changed? What has been done? Understand the conditions? Right? So that's questions two in questions, three, then you could log into the building automation system, run an override report, look at any exception reports, look at the current conditions, you can go and see all of this on the building automation system. So just because
the person is not available to answer those questions for you, does not mean that you can't go and ask them through queries into the system. Now it's at this point that we would transition over to our troubleshooting process. And it's actually at this point, we're gonna have a pretty short episode this week. But this episode ends, because now, you know, you understand kind of the step before and the step after. So I'm going to recap one more time, I want to bring this all together. And then I'm going to let you be on your merry way to have a good rest of your week. So to recap, we need to go and have a process. And that process needs to begin at the first interaction with our troubleshooting call. And that would either be through dispatch, or our front desk or whoever, depending on if we're in service or if we're an operations. Once we've done that, then we need to start working through our questions to get a good sight picture. Hopefully, our questions lead us to resolution and we can solve the issue prior to even leaving to go to the job site. However, if we can't, then we need to go through the site arrival process, which is document gathering. And once again, working through those five questions. If we can ask someone those five questions, we definitely should. But if we can't, we shouldn't abandon the process, we should ask as many of those questions ourselves of the system through system queries. And at that point, we should have a pretty good sight picture of what issue is going on, we should have a pretty good idea where our troubleshooting process should start. And then we're going to have identified our desired and actual states so that we can go and identify our root cause, and then move into solutioning the problem, which will be the problem resolution phase. So that's it, my friends. That is the approach to troubleshooting. If you'd like a very formalized, structured approach with checklists, training videos, and supporting materials that you have complete online access to for a full year, then I encourage you to go to podcast smart buildings academy.com Ford slash 235. Scroll down about halfway down the page, click on the troubleshooting bootcamp online course, and sign up for the course while it's still in that 50% discount window. As always, if you have any questions, do not hesitate to reach out. do go and apply this process this week. I'd love to hear back from those of you who apply this process this week, how it worked for you what challenges you faced. Feel free to let us know in the comments section or discussion session, depending on where you're listening or watching this podcast episode. Thanks a ton and have a great rest of your day. Take care
Transcribed by https://otter.ai
