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

Selling Audio-Visual Integrations

By Phil Zito on Dec 30, 2021 4:00:00 AM

Hey folks, Phil Zito here and welcome back! In this post, we are going to be discussing selling audio-visual integrations. Everything we discuss can be found at Smart Buildings Academy Blog. I encourage you to take a look at our previous posts on integrations as we are halfway through this integration series now. There's been a lot of great information covered so far and it will really help you understand what we're going to teach today. Let's dive into selling audio-visual integrations. So, what does this look like? In my experience, there are really two ways this comes together.

The first is via specifications. You get a plan and spec or a design-build specification, And in DIV 23, Section 1, there are going to be additional sections, additional specifications that are involved, and those are going to be the audio-visual one. There may even be a mention of integrating into the audio-visual system, but that's typically all you will get.

That's where things go wrong. That's where things go very wrong. Oftentimes, you are not going to get, “We want the building automation system data on these points, we want to be able to display it and make it interactive for this.” Oftentimes, those AV audio-visual use cases are not actually designed and implemented until the warranty phase, at the earliest.

So, how do you estimate this? How do you understand what is expected? How do you understand if I'm having to do a protocol integration or if I'm having to do an API integration? How do you understand the level of support that you may or may not need to provide to the audio-visual manufacturer or contractor? These are all great questions.

Here's how I break it down. The first thing I determine is, what system is in control? If I am simply pulling data out of the AV system, that is a lot different than me simply providing data to the AV system. They can be equally complex, but they have complexity at different stages.

If I'm providing data to the AV system via BACnet, very common BACnet IP, then from an estimating perspective, that's pretty easy for me to cost out. How much time do I need to potentially give for support for the AV contractor? That will typically be a day or two because once they get one of your points mapped in, once they get it communicating to one set of points, they can follow that process and do it again and again and again.

Where it gets very time-consuming and where my risk alarm starts to go off, and I start to say to myself, “Man, I better account for this,” is when I have to pull data out of the AV system. At this point, I am dependent on their system and its nuances. Most AV systems are not BTL listed, they have not been tested for their compliance to BACnet, and it gets even worse if I need to pull data out via an API.

So, what is an estimator or a salesperson to do? How do you estimate and scope out this work? First things first, we need to use the RFI process to get very clear on the scope and use case of the AV system.

  • How are we using the AV system?
    • Am I providing temperature control?
    • Is the AV system the primary system?
    • Am I providing occupancy control? What level of control am I providing?
  • Am I pulling data out of the AV system?
    • What data do I need?
    • How often do I need it?
    • What format does it need to be in?
  • What integration options does this AV system support?
    • Is this something where I need to go to a gateway provider and get some sort of RESTful API to BACnet gateway, which is going to cost money and most importantly, time?
    • Is this something where it's a relatively simple BACnet IP interface, and I just need to make sure that I account for BBMDs, BDTs, subnets, etc, on the BACnet system so that it can properly integrate?

Those are two totally different cost structures. If there is an API integration, that is a high-risk integration, and it should be priced accordingly. If it is a BACnet protocol integration, and you're providing points to them, that is the lowest risk integration. If you're consuming points via BACnet protocol from the AV system, that is a medium-risk situation.

Now, I know those of you reading this, are saying, “Phil, tell me the numbers, tell me the numbers!” I can't tell you the numbers because medium-risk to you could be a completely different burden than medium-risk to one of your competitors.

So, for example, if you hired someone who used to work in a products group building BACnet integrations and API's, and they were your integrator, that person's version of medium-risk is going to be completely different than if you hired someone who has struggled in the past with integrating BACnet IP chillers. That person's level of risk, what medium is to them, is completely different than that previous person who has product development and actual software programming development experience. So, you need to account for that.

Alright, so just be cognizant, API is the riskiest. BACnet IP out of their system to you is medium-risk, and then from you to the AV system, BACnet IP is the least risky.

So how do you position this? How do you get involved? Well, if it's plan and spec, or design build, there's not much you could do other than RFI and getting really clear on scope and the use case of the AV system.

That being said, if it is an owner direct, or a retrofit opportunity, you often will have much more involvement, specifically, if it's owner direct. Now, up to this point, I haven't talked heavily about use cases, I haven't talked heavily about business use cases. I want to give you a methodology to approach, and this is going to be kind of off the seat of my pants.

In our MSI in a Box course, we go into it in much greater detail, but I'm going by memory here. So, the template may be a little off, but basically, it is: User, System, Business Impact, ROI. That is the methodology.

So, the user would be, maybe it's a tenant or the maintenance person, whoever the user is. Our systems would be AV or building automation. What is the KPI, the business impact that we're driving? And then what's the ROI on that?

Now with AV integrations, it's typically much more difficult to figure out ROI because ROI, if you're doing lighting to AV integration, there can be a hard ROI on that. The AV system shuts down the lighting, saves energy, right? It's usually minimal because conference space is only a small subset of the overall tenant space.

That being said, when you move into AV to BAS integrations, it's much more tenant experience. It's tenant satisfaction. These are what I call qualitative KPIs. They're not quantitative. Anyone who tells you that they can measure tenant satisfaction and tenant experience quantitatively, I'd say is not truthful. Here’s why:

I go to the gym in the morning. I work out. I'm doing crazy, heavy lifts, and my body is burning, right? I'm super hot. I come into a space, and it's 72 degrees, but I feel like it's hot. So, my tenant experience is, “This space sucks. It's hot.” Right? The next day, I don't work out and I have the air conditioning blowing on me. I'm in my car. It's like 50 degrees outside, beautiful day I walk from the car to the building, I come inside, 72 degrees, it feels great, right? Building automation system’s great.

What changed? It's 72 on both days, but I changed. That's why I think tenant satisfaction is a load of crap. If they get in a fight with their spouse, if they're hot because they're running from the car because they're late, their satisfaction with the space is going to be completely different, even though the space variables have not changed.

So, be cognizant as you are driving a use case to those tenant experiences and tenant satisfaction, KPIs; those are very fickle. I would call them weak KPIs. The reality is, for most of us with audio-visual integrations, that's really the only KPI.

Now, there is an unwritten KPI though, that we need to be aware of. Basically, it’s what I like to call, “keeping up with the Joneses,” my space looks better than your space. Back when I worked at Johnson Controls, we had this really nice executive showroom, and I liked to go up there and eat the snack food. I probably drove the people crazy, because they're like, “Hey, the snack food is not for you, it's for the customers.” But whatever, you know, I like food.

So, the reality is that those spaces... they just gave this presence, this experience, and it was part of the greater experience that just made people feel like, “Oh, I'm in a nice place,” and people have associations with nice places and values. That puts them in a mental state to make high-paid buying decisions, right.

So, if you're using your space for selling, that can be something you communicate to your customers. When we start to get into some of these later integrations like AV, access control, parking, etc, it's all about the experience, and it's painting the picture for your customer. So, you become a very narrative-driven salesperson.

I know we're going way off-topic here. But it's something I feel is just not properly taught in selling. I've seen some of the best salespeople do and it's narrative-driven selling. There's only so much you could do for plan and spec work. You quote, you be low, and hopefully you're lower than the other person. Hopefully you have a relationship with the mechanical so you get last look, right? That's kind of how it happens.

When we get into owner direct selling, or we get into collaborative selling, solution selling, we need to focus in on narrative. So, our narrative, in regard to audio-visual integration with building automation systems, is going to be about single-point control. How high tech, or Tony Stark, do you look, when people can come in, and with their phones they can have like a pre-generated app in the phone with Bluetooth beacon tracking them and it knows their temperature preferences, and turns the spaces to their temperature preferences? Isn't that cool.

Also, it's like taking it a step further, when you go in there, and you can control the lights, the access, the shades, you can have digital signage, you can have temperature, all this stuff integrated. That's a story. That's a narrative that paints the art of the possible for your customers and for your tenants. So, that is something that is needing to be considered when you're selling integration.

The reality is, at the end of the day, any of these integrations are going to fall into this low, medium, high-risk category:

  1. Low risk being when I'm integrating and providing points available to others.
  2. Medium risk is when I'm having to consume points out of a system using a protocol. I'm common and understand well.
  3. High-risk is using things like API's or protocols, that I'm not well versed in, to pull data out of.

So, that is your big thing from an estimating perspective. But the really big takeaway I want you to take from this is narrative selling. Have one or two good stories, good experiences associated with these technologies, and use those to tell your customer the story. Help paint the vision, so that they can go and buy into that vision, make it their own, and then you'll be able to sell the solution.

That being said, thanks so much! I hope this was helpful. Be sure to go in the comments at Smart Buildings Academy Blog.

Thanks a ton, and I'll see you next time. Take care!

Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?