<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

Hey folks, Phil Zito here, and welcome back. In this post, we are going to be discussing seven ways to avoid non-billable warranty calls. So, every year, at the beginning of fall, we see the same thing happen. The warranty calls start to come in.

Well, what is a warranty call? Quite simply, a warranty call is when you have completed either a renovation, retrofit, or capital project of some nature and from that completion, you now typically have a one-year period during which you need to support that installation, that retrofit, that work.

There are 2 types of warranty calls:

  1. Billable warranty calls, which means that it wasn't actually an issue that was caused by your lack of installation, or lack of process, or lack of programming. It was an issue that is not within warranty, and therefore is billable, meaning you can bill the person who calls you.
  2. Non-billable warranty calls. These are calls that are not billable, you can't charge for them. So essentially, it's just pure profit erosion. Now, those are the calls we want to avoid.

So, as you’ll see throughout this post, there are some very specific steps we can take to avoid these non-billable warranty calls. I will tell you, both from the contractor side as well as from the owner side, there are some significant issues with percent of completion, 90 +. So basically, how a project works is, you have percent of completion thresholds. The most common one that we see in the building automation industry is that 90%+ threshold. Typically, the owner's manuals have been done, the owner training has been done, and there are things like some basic functional test, and there are some other things that need to be closed out in order for us to get to that 100% percent of completion.

However, on the flip side, we also start to see warranty phase kind of being invoked during this period. So, some of the tips I'm going to cover are going to be, how do we get from that 90 to 100% completion so that things that are project scope aren't misinterpreted as warranty issues. Then we're going to cover how do we focus on things that are post 100% percent of completion.

 

Tip #1: Close out the project

Tip #1 is to actually close out the project. I mean, who would have thought, finish the scope of work that you've been contractually obligated to do? However, as I talk with different building owners, as I talk with different general contractors, as I talk with EORs, Engineers of Record, I’m increasingly hearing that the last 10% of projects is not being closed out, due to labor shortages. Folks are doing okay on the install side, but when it comes to doing functional , when it comes to doing owner training, when it comes to doing final tweaks on graphics, these things are not being done because people have shortages of labor.

So, it's kind of one of those catch 22 problems, right? So, are you going to pull someone from another job, potentially get yelled at and not be able to revenue that job, hold up that job, and maybe even face things like liquidated damages, etc, or are you going to devote the labor to that last 10% and close it out? As we'll see in some of the tips later in this post, there are things we can do before that 90% point that will help us to not be in this situation in the first place.

So, tip number one is to close out the project. I would be remiss if I didn't openly acknowledge that a lot of you are short staffed, a lot of you are struggling to man projects. So, you have to make that choice of, where do we send the people today? Which project are we going to upset today? With a shortfall of 100,000 plus BAS technicians and employees in the United States alone, that is a problem we all are facing.

 

Tip #2: Document what you did

This brings us to tip #2 which is, document what you did. Oftentimes, a lot of the reasons I see us stuck in that 90% or greater completion hellhole is because of lack of documentation. If you know, in Section 3 of Div 23, that there are commissioning requirements involving functional tests, you should be engaging the commissioning agent, as a project manager, as a lead tech throughout the project. You should be understanding their commissioning test plan, you should be providing your voice to that commissioning test plan, and then you should be documenting that commissioning test plan.

So, whether that is point to point checkout, whether that is functional test, whether that is system operation procedures, whether that's an O&M manual, whatever it is, document your contractual obligations. At the end of the day, I've seen, personally having run a $60 million P&L with 20+ technicians doing about 120+ projects at any given time, where documentation was not produced, or it was kept on someone's laptop and not shared with the commissioning agent. Then we would get warranty calls saying this system never worked, this system was never tested, this system was never commissioned. In actuality, it was, but the technician who had the functional test form that was maybe signed off, had it on their laptop, and they're on a different job site. So there you are, in a meeting, wasting time on these warranty calls for a system that's not operating because it hasn't been commissioned, and hasn't been functional test, when in actuality it has.

So, document what you do. Then get in a process of at the end of each day, having your technicians, whether this is Google Docs, SharePoint, whatever mechanism you use as your in-house document management solution, get in the process of if there is a signed document, upload it to the central server under that project folder. Now, at any time anyone who's being questioned about the completion of a task, they can go and point out that that task has actually been completed.

 

Tip #3: Train the customer

Let's talk about tip #3, which is train the customer. Recently, having talked to some major school districts, having talked to some federal institutions, having talked to some large commercial building operators, I have heard repeatedly of the lack of Project Closeout training. You know, I've heard everything from, “We will be given a voucher and we simply do not have the time to utilize that voucher,” to “We get four hours of training and doughnuts on a 40-hour training time block, and we just accept it.”

What you have to understand, and I feel like as an industry we forget this, although building automation is critical to achievement of sustainability goals, is critical to achievement of your energy efficiency goals and your tenant and occupant comfort and safety goals, it is critical. I would argue it's the most critical system in most vertical markets. It is not the only system in most vertical markets. We have conveyance, we have access control, we have lighting, we have video surveillance, and that's just the building systems. Then you have specialty systems in healthcare or education, and you have business systems as well.

So, what we have to realize is these facility operators, often, they are getting trained on multiple different things at the same time, so they will go from the building automation training to the access control training to the video surveillance training, and it'll just ram them all through. Then they're handed this system, and they're told,” Good luck.”

So, when you have an opportunity to train a customer, I do not want you to look at it as, how can I do the least amount of training so that I can recoup that 36 hours as profit? You know, how can I do four hours of training on a 40-hour training engagement, and recoup that 36 hours? I know this wasn’t maliciously done; it was just done. You know, nowadays, I wouldn't do that. I understand the importance of training, but the customer didn't want to sit in 40 hours of training, I didn't want to do 40 hours of training, so we kind of both agreed that we're going to do four hours and we're going to go through some basic stuff.

So, what I want you to see is, every hour you put in to training the customer, the likelihood of them doing a warranty call for the graphics not working, can't change the setpoint, why is the valve not opening, those kinds of silly warranty issues that then you have to piss off a customer and be like, “I have to bill you for this, I mean, you had the valve in override.” You know, you see the issue.

So, here's how you train. And we've done posts on this in the past that you can find at blog.smartbuildingsacademy.com and you can search up our past blogs. You can see an exact walkthrough of how to train customers, but I'm going to give you the quick, like 30,000 foot fly by here. Find out the roles of the customer, find out what they actually do in those roles. Just because this says they are building engineer does not mean they're a building engineer. They may be someone who literally just changed the set points. So, find out what they do, train them on what they need to do, videotape what they need to do, document it, and then hand it off.

 

Tip #4: Attend the job site meetings

Next up, let's attend the job site meetings. I am continuously shocked by how many folks hop into our forums, hop into our office hours, reach out to me on LinkedIn or Facebook or Reddit and say, “Phil, this project is out of control. I'm behind on billings, I can't get people to pay. I've got the project saying they need controls working next week and they don't even have power yet. They want me to do test and balance with the test and balancer, so I'm supposed to follow this person around. The mechanical systems aren't working; I found one fan rotating backwards. What do I do?”

The first question I always ask them is, “How many jobsite meetings have you attended?” Then I wait. They’ll usually tell me they were at the kickoff meeting, and I’ll ask, how many other meetings were you at? It's literally crickets. It's so often crickets. If you want to defend yourself, which you should be prepared because it's controls’ fault all the time, every time, I highly, highly recommend that at least once a month, you attend the jobsite meetings. At least once a month.

As you get closer, when the slab is being laid, and they're starting to do stub-ups, then you definitely should be at least every other week in that job meeting. What do you want to do in the job meetings? It's one thing to just attend the job meeting, but what do you actually want to accomplish?

You want to get your schedule into the master schedule. So, if you need six weeks after power, to test your control systems, you need to communicate that. If you need a reliable building envelope in order to put in that hardened IT gear for that OT network, you need to communicate that. If you need mechanical systems up and running, both hydronic and airside, in order to do functional test and test and balance, you need to communicate that.

You need to give reasonable expectations of, “If you give me mechanical system access and control on January 1, then expect March 30 when we can get the controls fully functional and ready for functional test.” If you don't communicate these things, then you're going to have some major issues with people not being prepared.

 

Tip #5: Understanding General Conditions and related sections

Tip #5, understanding general conditions and related sections. So general conditions are the general conditions of the job. These are things like work hours, these are things like general scope. From there, you can shift into what are called related sections. So, if you were to open up a CSI MasterFormat Specification, which we’re in the US here, so I'm talking about MasterFormat CSI spec, it typically is structured in three categories: General, Materials, and Execution.

Within the general, it will give a baseline narrative of Div 23, which is the controls and instrumentation division. It will give, “These are the related sections to this specification.” So, specification details out the specific details, like “We're going to use these materials; this is our scope. The mechanical electrical plumbing plans, these are the drawings, these are like the Lego blocks. So, they’ll say, “You put the Lego blocks here,” and the spec will be, “We’ll use a red 8-dial Lego block for this.” So, specs give granularity and mechanical plans give details, installation, and visualization.

Now, when you read the spec, you want to understand the related sections because that will point you to the related mechanical electrical plumbing drawings. Imagine this: You're sitting there, you're looking at this Div 23 spec, and it says, “Lighting,” and it says, “Shall coordinate with lighting.” That should be a red flag to you that there's something going on here with the lighting system. Don't quite know what it is yet, but there's some form of most likely an integration going on with lighting.

So, what do we do? Well, we need to read that related spec and we need to understand the sequence and any potential integration points. But we also want to go to the mechanical and the electrical plans and see if there are any lighting systems that we need to integrate with. At this point, we want to figure out what exactly are we doing with this lighting system. That is going to be in our related sections, but furthermore, stepping away from integration because not every job is integration, there may be links to the mechanical section. There may be links to the plumbing section. You may be expected to provide thermowells. You may be expected to provide dampers and damper actuators, or you may simply be required to coordinate the installation, or you may simply be required to coordinate the electrical wiring. The only way you start to realize this is by reading the related sections, and also referring to the related mechanical documentation and notes on those mechanical plans.

So, it's really important that we understand what is in scope and not in scope. I have seen things like entire rooftop units not being mapped into a building automation system, because someone didn't read the related section and realize that there was a BACnet card that should be integrated. So, guess who's getting the warranty call? Once again, it goes back to, its controls’ fault every day, all the time.

 

Tip #6: Clarify ownership of integrated systems

Tip #6 is to clarify ownership of integrated systems. It's lighting, but no it's BAS, but no it's access control, but no… I mean, the list goes on and on and on and it's super annoying. I used to run the technical integration program at a large OEM where I did some crazy cool integration stuff. Built BACnet stacks, integrated all sorts of systems, actually did the MSI stuff that so many people talk about. It was really cool. But one of the areas that I could always look at and tell, this project is not going to go good or this project will go great, was the coordination.

Imagine this very, very, very simple example. You have a lighting system; we'll just call it ABC lighting. Your lighting system is integrated to building automation system XYZ. They're integrated via BACnet IP. Now here's the issue, your sequences, when the space is occupied, the light should be enabled. First issue is going to be objects. You have zones in lighting, and you have spaces in building automation. Zones can have multiple spaces, but a zone cannot overlap multiple spaces, and a space can actually be in multiple zones.

So, the first thing you have to do is figure out which zone is which, which space is which, and that comes down to who takes priority. If Space 101, which happens to be in Zone 1 and Zone 2, is occupied, do I turn on Zone 1 and Zone 2 lighting? Or do I only turn on Space 101 If Zone 1 or Zone 2 is occupied? Okay, I don't know. What happens if someone pushes temporary occupancy on the thermostat in Space 101? Does that turn on the lighting? What if the lighting switch is turned off?

See, all of these ownership issues, who's on first, whose system takes control, which system has master, which system has slave, you know, those kind of ideas. Those need to be clarified and coordinated upfront. They are often not in the specification, they're often not in the system diagrams as well. This is stuff where you have to attend the job site meeting, you have to understand the related sections, and you have to then clarify the ownership of the systems.

 

Tip #7: Don’t give access to everything

Let's move to tip #7 which is, don't give access to everything. Okay, I get it. This goes completely against what I've communicated in the past. I've always been a strong advocate for owners having a copy and license of their control system software. They should have access to all of their programs, they should have access to all of their systems.

With a specific context in mind, just because you have access to something doesn't mean everyone at the owners’ site should have access. I remember a specific school district I was with in the Pacific Northwest, that I was working on their job Every morning, they would show up and it was hot as balls. Like, you thought you were in hot yoga. It was really bad. The issue was, they had this little old lady who was the janitor, and every day she would come in to do cleaning in the afternoons and evenings. If you know anything about the Pacific Northwest, it gets hot in the afternoons and gets cold and cool in the evenings, and then right around mid-morning, it gets hot again.

So, she would come in and she would crank up the heat. She would operator override the setpoint to 85 degrees. Now she didn't think she was doing anything wrong. She just thought, every time I come in here, it's cold, so I'm just going to turn it up. Obviously, they turn it back down because it gets turned up. Well, the issue was that she had access to that setpoint override and that was costing that school district a significant amount of money in energy loss. Pretty easy fix though, right? Not the end of the world.

Now contrast that to another job that the company I was at actually didn't do. We were brought in to fix and this project they had no logging of any calibration set points. So, K factors, I-values, prop bands, etc. All these configuration factors were recorded nowhere, no logging on the system whatsoever. They thought to themselves, that's fine because we can have these set points, but we're going to put them behind a button that says Engineering Points. Do not click.

Now what happens when any curious person sees a button that says Do not click? They click on it right? So, these folks would click on the Do not click button. They didn't know what they were doing. They changed K-factors, they changed min and max settings, flow settings. A job went absolutely crazy.

So, how do you avoid that? Well, quite simply, is you should still give your owners everything they purchased. Absolutely agree, my stance on that has not changed. However, you should understand the roles at your owners’ organizations, and you should make graphics contextual. Pretty much every building automation system out there has contextual graphics. I'm not aware of any modern system that doesn't.

You can have role-based access where we say if this person is a building engineer, they're going to have access to all of these categories of points; this person's a building operator and they're only going to have these points, this person's janitor and they're only going to have these points. I'm a firm believer of having the same graphic for everyone, but you only make points visible based on roles.

Now, granted, your owners have to practice not sharing accounts and stuff like that, but that's not your fault. So, don't give people access to everything because guess who's going to get the warranty call to come back and recalibrate everything, especially if the points weren't logged?

 

Tip #8: Utilize Request for Information and Request for Clarification

Alright, let’s take a look at tip #8 which is to utilize Request for Information and Request for Clarification. You all have heard it and I've said it a million times: Have a release to operations. Meaning, if you're a contractor, have the sales team meet with the Ops team, release the documents, release the scope of work, go through and do another takeoff, do any re-estimates you need to do, and really understand if your project has any issues. Then as you do that, you should create your first list of RFIs and RFCs.

Now what are RFIs and RFCs, and when do you use each?

  • A Request for Information is when you do not have information: I do not know if this system exists, or I do not know if this exists on the project.
  • A Request for Clarifications are clarifications: Can you clarify this sequence of operations? This is how I read it, it doesn't make a lot of sense. I don't know how you're going to turn on 100% outdoor air unit and have the damper to the outside of the unit closed at the same time. That's a very new sequence to me. I don't know how that will logically work. Can you please explain it? They'll be like, “Oh, we meant to say that the damper should be open.” And you're like, “Thanks, because I didn't feel like sucking in duct work today.”

So, utilize these processes. These processes should be listed in the General Conditions of the specification, or at least at the kickoff meeting of the project itself. When I say kickoff meeting, I'm talking project kickoff meeting, not release to operations. So, this is all the trades, not just your specific company. It should be listed out that we use this RFI sheet/RFC sheet, this is who you send them to. You'll usually, typically get that from your mechanical, but if you are owner direct, you may have to create this on your own. So, definitely utilize those, clarify anything that is not clear.

 

Tip #9: Understand the limitations of systems from Day 1

Finally, Tip #9 is understanding the limitations of systems from Day 1. I can't tell you how many times I’ve been out on a project and there is no way on God's green earth that this is going to work. I'm reminded of an all-wood music studio that we did for a university. The genius idea in southern Texas, where it's super humid, was that they were going to have a fan coil unit with hydronic cooling and no reheat. The theory was that dehumidification would be achieved by bringing in hot outside air to mix with the saturated air that basically had been sub-cooled by the coil.

Now if you know anything about psychometrics, you know that there's no way that can work. I mean, unless you're in like a quantum universe with different math. There is no way when you're at saturation, if you bring in hot, humid air that has more grains per pound, it has more moisture mass in that air than the air that you're cooling and you mix the two, that your relative humidity is going to decrease. You're actually going to create this self-fulfilling cycle of increased humidity.

So, I said, “Hey, this isn't going to work.” I pulled out a psychrometric chart, drew the lines, and was like, “I cannot make this work in any possible way, unless you put reheat in,” and they basically dismissed me. I asked for my concern to be added to the meeting minutes so it showed that I brought this up, and they agreed.

So, they put it in the meeting minutes and six months into warranty, guess what has to happen? Well, you can't put in hydronic heating now because one, they didn't have boilers. They had domestic, but they didn't have hot water boilers, and two, they didn't have piping, so you have to put in electric heat. Guess who they tried to come back to us and be like, “Hey, controls, you guys need to put in electric heat, and you gotta wire it up, and you gotta do it because you should have known and you should have brought it up. You don't have to provide the strip heat, but you gotta do all the wiring and reprogramming at your cost.”

I'm like, “Oh, no, no, no, no, no, no, no,” and then pointed to the meeting minutes and told them that I said there was no way this could have worked and it’s exactly what I told them was going to happen has happened. Told them we weren’t doing this, and we were able to defend our position because it was in the meeting minutes.

We understood from day one, this could not work. We submitted an RFC, a request for clarification, with the psychrometric charts attached, with the lines drawn, showing that there is no way mathematically this could work, and we were able to defend ourselves. So, we are able to avoid absorbing that deductive change order, which is what it would have been.

So, there you have it, folks, I know I said I’d give you 7 tips, but I threw in 2 more. You’re welcome. Nine tips to avoid un or non-billable warranty during the warranty phase in your building automation projects.

I hope you found this beneficial. Thank you so much to everyone. I appreciate you all being here. I hope that we have provided you with some great knowledge and great information. Thanks a ton and take care.

 

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?

 

BE A GUEST