Larry Ellison once said that a “CRM provides a 360-degree view of your customer, provided you don’t care about getting paid.” This quip was intended to ward off new threats to the dominance of ERP. Many organizations, having implemented GL and ERP, were dipping their toes in the CRM waters––particularly service heavy industries, such as utilities and manufacturing. These industries built their services, sales, and marketing functions into this CRM domain.
In today’s customer centric world, these legacy architectures require re-examination. This is because, by their nature, these architectures provide the enterprise with a fragmented view of the customer. Often, in modern enterprise architecture, the expedient tendency is to just replicate this approach in the new target-state Cloud CRM. Customer centric design can help avoid repeating this mistake, and provide a more holistic and accessible customer view.
Why is this necessary? Some customer interactions have more impact on the customer experience than others. There are some critical moments, above others, that allow us to touch the right customer at the right time, with the right solution. Some folks call this a “moment of truth.” Get it just right, and it can be an “ah-ha” moment, enhancing brand attachment. But if it is a little off, it can be spammy. To get this right we need to understand customer preferences and apply these learnings at a one-to-one level, rather than at the cohort or persona level. Furthermore, this capability needs be accessible to all customer channels in real-time.
To achieve this, architecture and implementation should not be considered in the initial design phases. The first task is to understand the business through customer behavior; this will be the primary design driver. Interactions to support these behaviors will surface in a number of customer channels, all of which need to be informed by customer attributes and preferences housed in lower-level processes and systems.
Physically, these can be accessed in real-time through APIs. These APIs will often not map directly to physical systems, and so principles of domain driven design can help. Additionally, when designing these APIs, it is important to consider developers and the developer experience (DX). A mistake commonly made by API designers is to focus on data, rather than the customer and the developer. As a result, APIs will often surface as generic query interfaces to data sets, which limits the opportunity for reuse within the enterprise.
The most successful organizations think about these APIs as products. Once an API has been designed, the initial versions should be tested with developers in a number of different channels. To support this, and to encourage adoption and reuse, developer portals need be deployed for easy API discovery and documentation. As these APIs mature, tracking API consumption metrics provides important data on the usage of APIs, which help drive API innovation.
This is the path to the “Golden Customer API,” one that enables that 360-degree view of the customer. It’s reusable––enabling multiple customer channels to share and enrich the customer view. It’s personalized to support “moments of truth” for consuming interfaces, and it’s abstracted from specific systems––enabling architectural flexibility moving forward.
Read MuleSoft’s Connected Consumer Report to learn more about best practices and examples to delivering a world-class customer experience.
