Episode Description:
A service call can start going wrong before you ever arrive at the building.
A vague work order. Missing credentials. No clear site contact. The wrong tools. No understanding of what changed before the complaint started.
For building automation professionals, preparation can be the difference between spending hours chasing symptoms and arriving on site ready to troubleshoot with purpose.
In Episode 563 of the Smart Buildings Academy Podcast, we explore how to approach service calls with more structure and discipline. You’ll hear how experienced technicians prepare before they roll out, organize their thinking when they arrive, and leave behind information that makes future service work more effective.
Topics Covered
• Turning vague customer complaints into useful troubleshooting context
• Preparing access, credentials, tools, and information before arriving on site
• Developing a focused troubleshooting plan without locking into assumptions
• Creating a repeatable approach for the first minutes of a service call
• Documenting findings and communicating results so customers and future technicians can act on them
If you work in BAS service, commissioning, controls, or facility operations, this episode will challenge you to think about how much of an effective service call happens before the troubleshooting begins.
Click here to download or listen to this episode now.Podcast Video
A building automation service call often begins with a work order that says something like, “Third floor is too hot. Customer requesting service.”
That is not much to work with.
You arrive at the building without knowing who reported the problem, when it started, which equipment serves the affected area, or whether anyone is expecting you. Then you discover you do not have the credentials, software, cable, or physical access needed to troubleshoot the system.
The clock is already running, but very little troubleshooting is happening.
For building automation system technicians, preparation has a direct impact on the quality of a service call. Technical knowledge matters, but it only helps when you can apply it efficiently.
A structured service process helps you arrive with context, test the right things first, adapt when the evidence changes, and leave the customer with useful information.
The first mistake in many service calls is treating the work order as a complete description of the problem.
“Too hot,” “too cold,” “not working,” and “system keeps alarming” are complaints. They are not diagnoses, and they usually do not provide enough information to begin troubleshooting efficiently.
Before heading to the site, gather context.
When did the problem begin? Is it constant or intermittent? Which areas are affected? Has anything recently changed? Does the problem happen at a particular time of day? Has anyone attempted a repair? Are there alarms associated with the complaint?
These questions help transform a broad complaint into observable symptoms.
That distinction matters because troubleshooting becomes much more effective when you know what behavior you are trying to explain.
For example, an occupant reporting that a room is hot could point toward airflow, hydronic performance, control sequences, sensors, scheduling, setpoints, equipment operation, or even an issue outside the BAS.
The goal before arriving is not to diagnose the problem remotely. It is to narrow the field enough that you can begin intelligently.
A technician can have the perfect troubleshooting plan and still lose hours because of access problems.
Before traveling to the site, determine what you will need to reach the systems involved.
That can include BAS credentials, VPN access, software, licensing, network information, controller passwords, mechanical room keys, panel access, ladders, lifts, escorts, parking instructions, or security clearance.
You also need to know who your site contact is.
Arriving at a front desk and saying, “Someone called us about the third floor,” creates unnecessary delays. Confirm who requested service, who can provide access, and whether that person knows when you are arriving.
Access planning is part of technical preparation. If you cannot reach the system, you cannot troubleshoot it.
A service vehicle may contain dozens of tools, but that does not mean every technician is prepared for every call.
Use the information collected before the visit to think through what you are likely to inspect and test.
If the complaint points toward airflow, you may need instruments that help verify actual conditions instead of relying entirely on BAS values. If communications are involved, you may need the appropriate networking tools, cables, adapters, and software. If you expect to work at a controller, confirm that you have the hardware necessary to connect to it.
This is especially important when working across different BAS manufacturers and generations of equipment.
The right laptop is not useful if the necessary software is missing. The right software is not useful if you forgot the adapter. Neither matters if your credentials have expired.
Preparation reduces those avoidable failures.
Good troubleshooting is not random.
Before arriving at the building, develop a short list of plausible explanations based on the symptoms you know.
The purpose is not to decide what the problem is before seeing the equipment. The purpose is to give yourself an organized starting point.
Rank possibilities based on what is most likely, what can be checked efficiently, and what evidence would support or eliminate each possibility.
Then remain willing to discard that list.
Buildings regularly provide information that contradicts the original assumptions. A disciplined technician changes direction when the evidence changes.
This is where preparation and adaptability work together.
Preparation gives you a starting point. Evidence determines where you go next.
When you arrive, resist the urge to immediately start changing setpoints, commanding equipment, or overriding points.
Begin by confirming the complaint.
Talk with the customer or site contact. Verify what they are experiencing and whether anything has changed since the service request was submitted.
Then observe the system in its current state.
Check relevant alarms, trends, schedules, operating modes, setpoints, sensor values, commands, and equipment status. Look for patterns that help explain what the building is doing.
This initial period can provide valuable evidence because the system has not yet been disturbed by your troubleshooting.
Changing values too early can erase the conditions that created the complaint.
Understand the current state first. Then begin testing.
One of the most important habits in controls troubleshooting is verifying what the BAS says against what is physically happening.
A graphic may show a damper at 100 percent, but that does not prove the damper is physically open.
A controller may show a temperature that looks reasonable, but that does not prove the sensor is accurate.
A command may be present without the equipment responding as expected.
The BAS is an important source of information, but it represents what sensors, controllers, programs, and networks report. Troubleshooting often requires comparing that digital representation with actual field conditions.
That comparison can reveal sensor problems, failed actuators, disconnected linkages, wiring issues, incorrect sequences, mechanical failures, and other conditions that might otherwise appear to be control problems.
Once testing begins, maintain control of the process.
If you change multiple variables simultaneously, it becomes difficult to determine which action caused the result.
Make a change. Observe the response. Record what happened. Then move to the next test.
This approach may feel slower than making several adjustments at once, but it usually produces clearer evidence and reduces the chance of creating additional problems.
Overrides deserve particular attention.
Every override placed during troubleshooting needs to be removed before leaving the site. The same applies to temporary schedule changes, altered setpoints, and testing modes.
A simple reminder can prevent a temporary troubleshooting action from becoming tomorrow's service call.
Service documentation should allow another technician to understand what happened without starting from zero.
“Checked unit. Working now.”
That does very little for the next person.
Useful documentation should capture the original complaint, relevant observations, tests performed, results, changes made, and the condition of the system when you left.
If you identified something outside the scope of the current call, document it as a recommendation.
This becomes especially valuable when dealing with recurring problems.
A failed component that cannot be replaced that day, an equipment limitation, an unresolved mechanical issue, or an incorrect sequence should not disappear when the service ticket closes.
Formal documentation creates continuity between service calls and gives the customer information they can use when deciding what to address next.
Before leaving, perform a final review of everything you touched.
Release overrides. Restore schedules and setpoints modified during testing. Return equipment to the appropriate operating mode. Close panels. Verify that affected controllers are online and communicating.
Check for new alarms.
The building should not be left in a temporary troubleshooting state.
This final walkthrough is a small part of the service call, but it protects both the customer and the technician from avoidable problems.
A technically accurate explanation is not always a useful explanation.
Customers do not necessarily need to hear every control term involved in the repair. They need to understand what was happening, what you changed, whether the system is operating correctly now, and what should happen next.
Instead of describing the work only through programming terminology, connect the technical work to system behavior.
Explain what the equipment was doing incorrectly, what was corrected, how you verified the result, and what the customer should watch for.
That gives the customer something they can understand and communicate internally.
It also creates a clear follow-up expectation.
If trends need to be reviewed again, explain when that will happen. If the customer should watch for a particular symptom, tell them what to look for. If additional work is recommended, document it clearly.
Service should not end with uncertainty about the next step.
Technical knowledge sets the ceiling for what a BAS technician can accomplish. Preparation determines how effectively that knowledge gets used in the field.
Strong service technicians do more than respond to whatever they find when they arrive. They gather information before the call, confirm access, bring the appropriate tools, develop possible explanations, observe before making changes, test methodically, and document what they learn.
They also know when to abandon an initial hypothesis because the building is telling them something different.
That combination of preparation, organization, technical skill, and adaptability creates more productive service calls.
The objective is not to arrive already knowing the answer.
It is to arrive ready to find it.
For a deeper discussion and insights from the field, listen to this episode on the Smart Buildings Academy podcast.