Hey folks, Phil Zito here and welcome back! In this post, we will be discussing how to manage the warranty phase of a construction project. Up to this point we have gone through the entire construction project process. We've covered everything from sales to operations handoffs, takeoffs, submittal creations, subcontractor line outs, working with your different trades on the project, all the way now to performing a proper management of the warranty process.
Now, I'll be honest with you, I have seen a lot of folks lose their shirt during warranty phase because they do not understand how to properly manage the warranty process. What typically happens is, you will have a tech or maybe a senior tech who don't really have a lot of project training, and they will be responsible initially for managing the warranty process. It won't be until you start to get a lot of calls, and rack up a lot of dollars, that it will flag the eyes of the operations manager who will then be asking, “What the heck? Why are we billing so much time to this project? This project should be closed out,” only then to realize you've established a basis now for the customer to be coming back to you and requesting “warranty service,” or they're requesting stuff that isn't remotely within the scope of the warranty.
So, we're going to address how to put some controls in place to make sure that we basically avoid these warranty calls in the first place, if possible, how to ensure that we really understand what's considered warranty and what's not, and how can we actually take this warranty phase, which so many people lose money on, and actually turn it into a money making and service-generating opportunity.
Before we do dive in, if this topic intrigues you and you want to know more about it, I encourage you to check out our BAS Project Management Bootcamp. If you have found our Construction Series to be valuable, I encourage you to check out this course where you will learn about each of these topics in much greater detail.
Warranty is the phase after Certificate of Occupancy where you basically, in most cases, support the project for a period of a year. What should happen is that there should be a defined warranty process of what is considered an “in-warranty claim” and an “out of warranty claim”. Then you should address those claims on a case-by-case basis within the standards of the specification. Once you have addressed that as either a valid warranty claim or a non-valid warranty claim, you should actually be able to even pivot further to sell a planned service agreement or to sell some form of ongoing service support. This may be in the form of labor and materials at a specific price per quarter or price per year, and you sell time and materials to support that customer.
However, let's contrast this to what often happens. What often happens is, the customer calls in to complain, they normally will have the tech’s number from training, because the tech gives them their number and says, “Hey, if you have any issues, call me.” Then they'll call, they'll complain, “Such and such isn't controlling right,” or “This is happening,” and the technician, rather than triaging the issue or running it through our warranty process, will immediately respond and we'll bill time to the project.
This will fly below the radar, not intentionally, but because of the operations or project manager. It won't be until you start to have significant labor hours hitting this project in a post warranty, and this usually takes a month or two to show up, that people are going to be wondering, “What the heck is happening here?” We need to stop this.
What will typically happen is, it'll be a couple hours here and there, and about a month to two months in, you'll notice you’re still getting charges on this project. We've already, although you shouldn't do this, re-estimated the project (even though you should never re-estimate a project until it's closed out). As a matter of fact, legally, there are some ramifications of re-estimating a project before it's closed out.
So, what should happen, in my opinion and based on my experience having run ops teams and projects, is you should have a flowchart. You should have a decision chart on warranty. First, everyone on the team should be educated on the warranty policy.
So, the warranty policy. A policy dictates what you are expected. So, the police says we're going to check the specification and execute our warranty process. Then, the process is the actual steps. The policy is going to dictate out what people need to do in regard to warranty, and then the process is going to dictate out how to do it.
How the process will happen is, the call should not be routed to the tech. It should be routed to an agent, either a service agent or a construction agent or even the project manager. It should be routed to someone who has the ability to look at this and say, “I am going to make a decision if this is within the standard of warranty work.” Now, this call will come in and we need to look at the specifications and say, “Specification dictates, this is how we're supposed to respond to warranty.”
So, one of three things may happen:
- The specification may say that you need to immediately respond and then submit your bills. I hate those kind of spec languages because those bills rarely get paid.
- Typically, there is an escalation. The customer will submit a warranty claim to the contractors, and then the contractor will submit it to the owner’s rep or to the general contractor. That person will submit it down the chain to the subcontractors, and it’ll get handled accordingly that way.
- The customer will make a request of warranty and then it'll be up to you to determine whether you want to respond. This is the least common response. I would say the most common, unfortunately, is to respond and then sort it out from a bill perspective. I do see increasingly where it goes to the GC or to the owner’s rep, and then gets pushed down to the contractors, and you handle it accordingly. Then you have what is called a warranty log.
Now, there will be a warranty log typically on all projects and this is similar to a change order log, or an issue log, etc. Now, in a warranty situation, it is critical that you have a warranty log, so if the site or project does not have a warranty log, you need to create one.
You need to document the following:
- What is the issue?
- How was the issue noticed?
- What caused the issue?
- How was the issue resolved?
This is going to be important, and you need to take screenshots if this is on the computer, or you need to take pictures with your phone and document. For example, and this is an actual scenario, the customer complains, “Central utility plant is not providing enough chilled water to the air handlers.” There's a design issue.
Let's go check it out according to the warranty process. Go to the site, walk into the central utility plant, hear a deadheading pump. It's an obvious noise, if you've ever been out in the field, you know what a deadheading pump sounds like. Sure enough, the multipurpose balancing strainer check valve thingy, someone bumped into it during maintenance, and it was slightly closed. Take a picture of it and send that picture to the test and balance. Tell them they need to reset this to whatever position it is to be, and then bill the customer for the issue, because that was not a control issue. It was not within the warranty.
So, I figured out the issue was the deadheading of flow. I figured out the cause was someone bumped into it, or adjusted it, during maintenance. The matter wasn't my folks who did it because we didn't install that valve. Then, I took pictures of it and documented how it was resolved.
This is how you have to manage and approach warranty. You have to have a definitive process of documentation. I know, it seems like a pain because documentation is a pain, and I don't personally like to document things, but it is important.
I hope you really enjoyed this series. I look forward to hearing from you on what future series we can do. Send us an email or leave a comment below. Our next series will focus on BAS careers. We're going to talk through how to establish a BAS career, why you'd want to do that, and then we're going to go through each of the different roles and identify the skills they need, how to develop them, etc. Then we’ll move into sales and then finally, we're going to move into workforce development. We’ll cover how to manage your team, how to grow your team, how to find talent, and a whole slew of things related to workforce development.
Thanks so much for being here. Thanks a ton. Have a great day. Take care!
