A Unifying Foundation for the Customer Journey at Mercedes-Benz

Find out how the luxury automaker is using modern software development and a cloud-native platform to better serve customers.

Jeff Kelly
Built to Adapt
8 min readApr 13, 2018

--

Photo courtesy Mercedes-Benz.

Providing an enjoyable customer experience is important for any company. But it’s especially important for luxury car makers. Customers expect the customer journey to be as smooth and pleasant as a drive in the car itself.

That’s why Mercedes-Benz decided to act. The German luxury auto-maker’s online presence was disjointed. Customers navigated through three disconnected web properties: a product focused website, an online customer portal, and a brand and lifestyle-focused site. All three sites were supported by different legacy platforms and couldn’t share user or customer data. So if a customer visited the product site, then jumped to the customer portal, there was no continuity of experience.

“The behavior of the customer was not clear to each of those sites because they were separate,” said Thomas Seibert, lead architect at Mercedes-Benz.io, speaking at SpringOne Platform. “It was a clearly broken customer journey and on top of that we didn’t gain any coherent knowledge of the customer or their intentions.”

But that was then. Today, Mercedes-Benz deploys new software several times a week. Its customer journey is supported by a single, cloud-native platform. And the company has plans to roll out dozens of new services and applications to customers around the world. This is how it got there.

A Holistic Approach to the Customer Experience

Think about the last time you made a major purchase. Was your first and only step walking into a storefront or logging on to a website to make the purchase? Almost definitely not. Today, multiple steps are usually needed to satisfy a customer need according to Harald Fanderl and Nicolas Maechler, both partners at McKinsey & Company.

Maechler, on a recent McKinsey podcast, described the typical customer experience in the auto industry:

“If you think about buying a car, in most countries today, you have car configurators online. So you go there, you have an ID, you look at one brand, and you configure your car. Then maybe a few weeks later, you pay a visit to the dealer, and you test drive that car. Maybe you hesitate again, and then you have a financing discussion later on.”

Eventually, if the customer is satisfied with each step in the process, he or she may buy a car. “But if you don’t connect these elements,” Maechler said, “you don’t have the view of one single journey, which is, ‘I want a new car.’”

That’s a problem because if one step in the journey doesn’t inform the next one and the one after that, frustration can quickly set in. For example, if a customer uses an online configuration tool to build the car of their dreams, and later has an online chat with a sales associate who knows nothing about it, the customer may feel like they have wasted their time. The more experiences like this that occur over the course of the customer journey, the less satisfied the customer will be. And the less likely they will make a purchase.

“It’s all about putting customer needs at the center of what a company needs to do, and then ensuring along all the touchpoints and even more so along all the relevant customer journeys that the customers have a flawless experience,” said Fanderl.

The challenge for large enterprises is that most are organized in silos, both organizationally and technologically. That was the case at Mercedes-Benz. The team responsible for its customer portal, mercedes.me, was distinct from the group that managed the company’s product-focused website, which itself was disconnected from the team that handled the lifestyle and brand digital property. And each of the three ran on different foundations — JavaEE and two different content management systems, respectively — that were disconnected from one another and made it difficult to change the applications.

But an effective customer journey requires cross-functional collaboration. CMOs understand this, and must implement practices that encourage collaboration across organizational and technology silos that provide a cohesive foundation for the customer journey. From an organizational perspective, this often means taking a balanced team approach to development, in which members of the business join their IT and developer colleagues on small teams dedicated to specific functional requirements along the customer journey. In this case, teams take a product, versus project mindset and are responsible for that functional requirement from beginning to end — developing it, deploying it, running it in production, and improving it over time.

From a technology perspective, the balanced team approach coupled with a product mindset demands an application platform that breaks down the traditional development silos in order to be effective. A balanced team, in other words, can’t support the full software life cycle if the platform on which the software is developed doesn’t also support running it at scale and iterating in small, high-velocity batches.

One Platform for A Unified Customer Journey

Working with colleagues in the business, Seibert and his colleagues helped Mercedes-Benz adopted the balanced team approach. Rather than the business only being involved at the start of a software project to spell out requirements, line-of-business people joined Seibert’s developers, designers, and project managers on small, balanced teams. Each team would focus on a single functional requirement, or microservice, that together formed the larger customer journey.

Photo courtesy Mercedes-Benz.io

Seibert and team also knew they needed a single, cloud-native platform to support and connect its various digital channels and applications. But the platform had to meet a number of rigorous requirements:

It had to integrate with legacy infrastructure and tools. This included content management systems, analytics tools, and applications and data running in Daimler’s data center (Mercedes-Benz is part of Daimler AG.)
It had to easily scale out and back again to adjust to vacillating traffic and workload requirements.

The platform needed to support a microservices architecture. This would enable Mercedes-Benz to reorganize into small, independent development teams, each working on a distinct piece of functionality. This way, each team can develop and release software at its own pace.

Any platform had to abstract away as much of the underlying infrastructure and operations tasks as possible, freeing up development teams to be more productive and focus on what they do best — build great software.
Relatedly, it needed to provide developers self-service tools and automate delivery pipelines to reduce the time from feature inception to production deployment, so teams could quickly deploy new features, analyze how they are used, and iterate to improve them.

Ultimately, Seibert and team chose Pivotal Cloud Foundry to support their customer journey initiative. The cloud-native platform allows IT teams to quickly build loosely-coupled, resilient applications connected via a high-performance routing tier. Through software design approaches like the strangler application pattern, developers can also break down existing monolithic applications into microservices, while still connecting to legacy data sources and related systems.

From a self-service perspective, the Pivotal Services Marketplace offers developers an easy way to provision supporting services — including data management services, messaging and integration services, and networking services — and with just a few clicks bind them to their application instances. There are also monitoring, metrics, and logging tools in the marketplace, which developers use to better understand how their applications are being used and iterate to improve them based on the data.

The Road Ahead

Since deploying Pivotal Cloud Foundry, development teams at Mercedes-Benz have been working diligently to simplify and improve its customer journey. Its previously disjointed web properties now all run on the platform, providing a common foundation for development and data sharing. And it’s development teams are now organized around distinct domains so they can focus on customer outcomes.

Photo courtesy Mercedes-Benz.io

As a result of the platform and organizational changes Seibert and his colleagues implemented, Mercedes-Benz development teams today are building and releasing microservices applications faster than ever. Because development teams don’t have to provision hardware or virtual machines with Pivotal Cloud Foundry, they can quickly build and experiment with new functionality. And with small, independent teams working on distinct domains with few interdependencies, each team can deploy software at their own pace and without having to wait for infrequent, coordinated release windows.

“We … learned that a PaaS solution can tremendously help you in increasing the efficiency of your team because it automates specific tasks like the creation of PCF routes when you deploy applications. You don’t have to worry about this,” said Gregor Zurowski, an independent consultant that worked with Mercedes-Benz on the implementation. “You have service bindings which implement the concept of attached resources like described in the 12-Factor Apps, where you don’t have to worry about managing credentials by the development team. And it’s also extremely easy to scale in and out.”

Photo of Mercedes.Me, courtesy Mercedes-Benz.

Importantly, usage data and customer feedback informs feature development, which, as mentioned, are built and rolled out in small, frequent batches. This, as much as anything, puts the customer journey at the center of attention.

As part of the initiative, for example, Mercedes-Benz determined customers would benefit from local versions of the company’s web properties and applications. In the past, it would have taken months just to get an initiative like this off the ground, let alone deliver to production. Not so today.

“Provisioning of a centrally managed platform drastically improves the velocity of the teams and also improves the stability of the components.”

“We have rolled out to 20 countries in less than five months,” Seibert said. “This means on average we have rolled out four countries a month. Sometimes we even managed to roll out three countries in one week.”

Seibert credits the pace of delivery on not just an improved developer productivity, but also on the platform itself.

“Provisioning of a centrally managed platform drastically improves the velocity of the teams and also improves the stability of the components,” Seibert said. “This has all been done without any critical production incidents. And we had zero management escalations. This is why I’m confident that in the next year, 2018, we will be able to achieve more than 40 countries worldwide with our platform.”

While there’s still plenty of work to be done, Mercedes-Benz and its customer journey has come a long way in a relatively short period of time. And with Pivotal Cloud Foundry and a modern approach to software development, the road ahead for both the company and its customers is an exciting one.

Change is the only constant, so individuals, institutions, and businesses must be Built to Adapt. At Pivotal, we believe change should be expected, embraced, and incorporated continuously through development and innovation, because good software is never finished.

--

--

Jeff Kelly
Built to Adapt

Senior Director of Product Marketing at Privacera.