Hey folks, Phil Zito here and welcome back! Like the previous two lessons on integration, we're going to spend a bit of time getting to the core basics of selling integration, and then we're going to talk about selling lighting integration. So, like the previous two posts, this one's going to be a little bit longer, but then we're going to continue this moving forward as we go through AV, access control, and other systems, as I see fit, over the next couple of weeks.
How exactly do you go about selling integrations? Well, there's really three ways that integration sales come about. There are the integrations that are just part of a plan and spec project.
In your plan a spec project, you’ll go into Div 23 and check out what's in related sections. You’ll see lightings and related sections and you’ll check out the general section in your specification. I'm talking CSI MasterFormat, primarily used here in the United States, and you'll see in the plan and spec projects that I have some integrations here. Maybe I have an integration to power metering, maybe I have an integration to lighting, maybe I have some integration via BACnet cards to chillers.
That's the first way you'll find out and you're not really selling integration, per se, you are estimating integration. There's a big difference between selling the value of integration and estimating cost of integration. Whenever you're integrating, the actual cost of the integration is largely variable. Is this an existing site? Am I doing a plan and spec job?
In our design course, for example, we have a university expansion that people use for their design project. As part of that expansion, there's an existing chiller, chiller 3, and it has a BACnet interface. There are some notes, if you actually pay attention to the submittal set, specifically the MEP submittal set, that mentioned about the BACnet integration and what to do and what not to do.
With some of these plan and spec projects, you're putting in all new stuff, and integration really isn't that big of a deal. If you just go through what I discussed in Posts 271 and 272, we do our research, we understand what data points we're integrating, we understand how the use cases come together, then we work on the physical implementation, and then we just test it. In those scenarios, cost is actually fairly low. It's no different, in my opinion, than adding in a controller from a costing perspective.
Now, when we get to existing sites, in plan and spec, things get a little more complicated because, if the points aren't exposed and if people don't know what systems are in there, you have to actually do a site walk. Sometimes you can't do a site walk, and maybe there's not even an equipment model number, so you don't know what points and what capabilities are available to you from an integration perspective. So, what's the salesperson to do?
Well, there's a couple options in these scenarios. Option one is to think about worst case scenario and say, “We might have to replace with a new BACnet card, we may have to actually put a controller on.” You’ll quote putting a controller on and controlling this manually in case you can't integrate.
Then there's the other scenario, which is, “I'm going to just treat it like another integration and I'm going to use exclusions,” and that can sometimes work. I wouldn't do it with government work, large municipality work, or large institutional work. They will probably slap down those exclusions and just say, “We don't accept them.”
So, just be careful. Understand the general conditions of the project, understand what you're going to inherit, as far as responsibility, as well as the funding mechanism. Is it a GMP? Is it at-risk? Those are both contractual, as well as funding mechanisms. So, just understand those things and how they impact your scope, your exclusions to your scope, and your assumptions to your scope.
No one really meets in the middle of the road, when it comes to integration costing. They either swag high or they swag low. I don't know why that is, but it's always been that way ever since I've been in the field, and probably will continue to be that way.
Next, we move on to design-build, integrated project delivery, P3 projects, anything where there's a collaborative environment. In a collaborative environment, two things tend to happen. One, the integrations tend to be more complex because this is more of a designed solution and people are more willing to be focused on use cases, business outcomes, etc. Because of that, your integrations are going to be more complex, so they're going to be more costly.
In these kinds of scenarios, how I like to sell is with a project development agreement. I like to do this owner-direct as well. A project development agreement is where we're going to develop your integration use case, your integration maps, and we're going to come up with your solution. Based on that, if you choose to accept us that cost will be applied to the implementation, if not, you pay for the integration design, and you can take it to whoever you want.
That is a favorable way of doing complex integrations because it shifts the cost of sales off of you, it reduces the risk to your business, and it gives you revenue to basically justify all your sales efforts. Whenever you're selling complex integrations, whenever you're selling developed solutions, those are time consuming, and they're taking time away from sales.
So, in order to keep your sales manager happy, in order to keep your revenue flowing, you need to be able to offset that cost as well as have commitment from the owner. We don't want to just be committing our development resources to developing integrations and developing solutions and then say, “Hey, I sure hope they buy this because I'm spending time here.” We don't want to take that approach. That's a really bad idea that unless you're a major OEM, with money to burn, your business probably will not survive too many of those.
The third solution is selling owner direct. Owner direct is both, my favorite way to sell as well as my least favorite way to sell. It's my favorite way to sell because, as someone who is an idea person, you ask anyone on my team, I love ideas. I love coming up with strategy. I love coming up with vision. I am not the person to go and execute. I'm the person to read the tea leaves, understand the market, understand kind of what's going on. I'm really good at that, and then understanding the problems, coming up with the solution, and handing it off to someone else who is very detail oriented, who's going to execute it.
If you have a team structured as such that you can identify the business problem, create a business use case, create buy-in among executives, hand it off to the executive’s team as well as to your development team and then those two can then collaborate, that's great! That's a great way to sell integrations, especially if you're using project development agreements.
It's when you, as the salesperson, have to lead this integration. In my opinion, the skill set to do complex integrations is completely different than the skill set to actually sell these integrations. I mean, that's kind of where I was miserable at my previous employment. I loved going in front of the customers, problem solving, creating solutions, creating ideas, but I didn't have anyone to hand it off to. And so, I actually had to implement it, and I was good at implementing.
So, the three types of selling:
- Plan and Spec: We mentioned the issues, really reading the specs, really reading the MEP set, and understanding the details and the notes. This will help understand exactly what's going to happen. Being cognizant if it's integration to an existing site, plan and spec, or major retrofit expansion.
- Design-Build/IPD/P3: We mentioned the collaborative approach to that and the need to get a project development agreement.
- Owner Direct: Once again, project development agreement. Be aware that you're typically going to be the construction manager at-risk in that scenario, and you're typically under a guaranteed maximum price scenario. So, you really want to do as much pre-development, paid pre-development, as possible to make sure that your scoping is accurate.
Now, what does all of this have to do with lighting? Well, plan and spec lighting, pretty simple, right? We're going to have a project and the lighting manufacturer, for example, Lutron.
Lutron comes in there and puts in their quantum gateway with the BACnet option. You map it in and it's all in the Div spec. Typically, it's just going to be lighting and zone control, integrated into the graphic for monitoring only or for control. As we know from posts 272 and 271, we need to do our data map, understand zones to spaces, and map all that out.
This is typically done during the submittal phase, not by the salesperson. So, from a costing perspective, from a selling perspective, you just need to make sure who has the gateway, who has the BACnet card, and who has the setup. From there, you need to add some time for supporting that setup, testing, and validating.
So typically, what I like to do is, if it's a single building, I'll add like a day or two, usually that covers everything. In my scoping, I will add the exclusion, or add something to the scope, to say, “Lighting system is set up and validated prior to execution of integration. Any additional requirements, based on improper setup or team not being ready, will be at contractor’s cost.” And then I'll just quote that and call it a day.
When I get to selling design build, once again, this is more collaborative. Usually you are , SD or earlier, maybe even prior to tendering, especially if it's like a P3 or IPD, where you're part of a team or consortium, and you're selling that way. You're basically selling off of use cases, and lighting is just one of the use cases. So, you just start identifying the business needs: Can I solve that with lighting?
Business needs may be safety, may be egress, may be saving energy, or even wayfinding. There’s a variety of lighting use cases that you can actually implement. If you're ever curious about it, just look up “Smart Buildings Lighting Use Cases and you'll get like the role of lighting in smart buildings. You'll get unique, connected lighting use cases.
Lastly is owner direct. It's like a combination of the two. For owner direct, we're going to be focused in on understanding the owner’s problem, understanding the use case. This is typically an owner that we already have a relationship with from a service perspective, and we're going to be going as part of our, ideally, quarterly meeting with the owner.
We're going to be talking about their pain points, understanding that lighting may be one of their pain points. Some of the signs that lighting may be a pain point is by visiting their site at night when their lights are on or maybe it just looks crappy.
That’s not really a very technical term, but I've walked into buildings where the lighting is trash. And I'm like, “Man, this is crap. It is definitely affecting the business, it's definitely affecting the productivity of the employees, it's affecting safety, potentially, let's fix this.” You could then pull so much data around that.
understand who you're selling to. The facility manager probably doesn't care as much as a business unit leader. Also, if this is an investment property, it's going to be a completely different response than maybe a school district. With a school district, you could potentially show the benefit of lighting to education and retention and student test scores. You’d then communicate that to the school board or to the superintendent, get a different level of engagement, typically get pushed down, but that will at least start a conversation. Then maybe there's incentives from the local utility.
So I hope you're starting to see that I'm throwing a bunch of ideas at you. But I want you to have this kind of thinking like, “Who can I talk to? Who is going to potentially be influenced? How are they going to be influenced.”
Always keeping in mind, if you've ever done business with us, we tell people not to take our training if we don't think it will fit them. Always keeping in mind, if lighting integration isn't good for your customer, don't suggest it just because you want to get a sale. Yes, you may get a sale, you may be able to put fear into people and get them to buy something, but at the end of the day, they're not going to use it if it's not going to benefit their business. That reputation is one you don't want to have in our industry.
So, this all being said, this is an approach to selling lighting integrations and our approach to selling integration as a whole. Over the next several posts, we're going to be looking at more types of integration. Next post, we're looking at audio visual and then I think we're looking at access control.
My hope is that we will start to dive more into use cases, start to dive more into scenarios. I'll tell you some lessons learned, just things I've discovered working with these systems. My hope is that you can take all of this information and use it to better serve your customers. If you are an owner, to better serve your tenants. If you're an engineer, to have better designs.
As always, if you have any questions, please go to https://blog.smartbuildingsacademy.com. And I can't encourage you enough to enroll in our BAS Sales Bootcamp in 2022. Our students have written to us after going through this course to say that the course has paid for itself. They've increased their pipeline, they've increased their close rate, they've increased their confidence to approach the market and to approach different customer buyers, different customer types and different buyer types. You can learn more about it on our Course Page.
Alright, thanks a ton and I will see you next time. Take care.
