This audio was created using Microsoft Azure Speech Services
Amazon’s stated goal is to be “the earth’s most customer-centric company.” We know how that turned out for Amazon — it’s now the world’s largest retailer and cloud services provider.
How does customer centricity play into B2B relationships involving complex system designs with multiple stakeholders? What happens when a complex value chain is involved — how do we stay engaged on the value for the end user?
I’m talking about, for example, installing a building management solution for a large healthcare facility. For that transaction to be customer-centric, you need more than a slick app and friendly service. You need to build relationships that allow for discovery, experimentation, and long-term thinking.
In this post, I’ll explore how Schneider Electric approaches customer centricity — how we define it in the B2B context and what it looks like in action.
What is customer centricity?
Fundamentally, a customer-centric relationship between buyer and seller is built on empathy and collaboration instead of opportunism and persuasion.
This sounds good on paper, but it requires shifting away from the traditional mindset of closing the sale, no matter what. And that’s easier said than done: Prioritizing a customer’s long-term needs can affect short-term profits.
When you dig a bit deeper, you find that, over time, what’s good for the buyer is also good for the seller. When it comes to physical and IT infrastructure, there are significant opportunities beyond the initial purchase. In fact, we estimate there’s a 5:1 ratio of operating costs to capital costs over a full building’s lifecycle.
“It’s not the end of the sale. It’s the beginning of the relationship.”
In Schneider Electric’s end markets — buildings, data centers, industrial spaces, and infrastructure — interconnected and intelligent systems are the new normal. This connectivity challenges us to unite previously siloed sales teams to present a comprehensive vision for each project.
For major projects, there are dozens of requests for proposals. In the past, companies, including ours, would respond to 10 RFPs with 10 different sales teams. This led to missing the forest for the trees: We promoted individual products without an overarching story of how these products work together to drive even greater value.
I want to share another approach that we use to manage integrated project deliveries. It’s called the solution architect method.
Building a future-ready hospital with the solution architect method
How do you design a hospital that meets the needs of patients, doctors, facilities teams, and the front office — both now and decades in the future? That’s the question we faced as a partner on the construction of the Pavilion at Penn Med — a 1.5 million square foot, 504-bed hospital under construction in Philadelphia.
This project involved three major divisions of our company. To achieve true integration across the realms of power distribution digital energy, and building management, we used the solution architect model. It’s a framework used by NASA, nuclear plants, and other organizations to unite siloed teams around a single vision.
The solution architect method
Solution architects connect the technology to the customer’s goals. They also focus on aligning stakeholders’ perspectives. This can get tricky, for instance, when CTOs and IT teams buy products on 3 – 5-year timelines, whereas facilities teams do so on 25-year cycles. If decisions get made purely from either perspective, they can diminish the overall system efficiency, reliability, and cost.
There’s also the challenge of solving what Shadow Ventures calls the CapEx-OpEx conundrum. In typical projects, the design and build team are incentivized to deliver on-time and on-budget. But that can lead to choices that end up raising operating costs, which account for the majority of the lifecycle costs. All value chain players need to care about the lifecycle costs and user experience of the facility — not just the narrow scope of the capital costs.
To coordinate these perspectives, the solution architect sits down with stakeholders in a room and sets desired outcomes, like “How can we enhance patient comfort?” and, “How do we reduce energy use?” Instead of leading with the technology we offer, we let the customer’s needs determine the solution we build. When we let the system’s users help design the system, we ensure the hospital will meet the community’s needs for decades to come.
But the benefits of the solution architect method aren’t limited to long-term goals like building a scalable platform or a future-ready hospital. The method also creates immediate benefits. For example, the Penn Med team expects to save five percent on the CapEx phase through greater cross-team collaboration and visibility. The method’s focus on collaboration and customer centricity was key to realizing these short- and long-term benefits.
The bottom line: We’re all human beings.
Customer centricity takes empathy and humility: empathy for the customer’s needs and the humility to know we don’t have all the answers. At the end of the day, customer centricity for us means seeing our customers as humans, and seeing ourselves as humans too. We don’t have all the answers. We know things the others do not, and vice versa. By pooling our expertise and uniting around a shared vision, we can together build infrastructure ready for whatever the future holds in store.