Building a transparent Notification Center to Enable Customer Control

Personalization is critical to a guided customer experience. It helps build trust, foster relationships, and enables a deeper connection with customers.

At Cisco, we have been trying to help our customers along each step of their post-sale experience for nearly a decade. And as a key part of that experience, we want our customers to have more control over what communications they receive – a more intentional step towards the right message, right person, right time goal that we are all striving to achieve.

Before we could begin, we took a thorough inventory of what exactly the post-sale experience for customers today looked like.

Evaluating a disconnected customer experience

Over the years, we’ve built several programs where customers could sign up for various post-sale notifications to help guide them on their path to success – but they were fragmented and lacked transparency.

One of the customer pages from the legacy experience

For instance, a customer could access a link via an email where they could enroll or unenroll from a specific Cisco product architecture. There was no way to access the link again if the customer changed their mind after unenrolling. It also was not totally clear to the customer exactly what they were unenrolling from.

Similarly, a customer could enroll in a digital journey from a form on the main website, Cisco.com, but they could not see what else they were subscribed to. There were 6+ programs of this nature that evolved over the years – each designed to help provide the customer more control over their experience, but lacking a critical ingredient – transparency.

Thus, began an initiative to build a Notification Center that was flexible, centralized, and personalized just for what a customer was eligible to receive. One tool for a customer to rule their post-sale experience.

Rooted in research

We built the Notification Center collaboratively with our customer research and design team, evaluating all the different existing programs we had, we defined MVP parameters that would enable us to evolve the data model to support a more cohesive experience. We experimented with design, naming conventions, login experiences and more. Each piece of feedback helped our design team iterate and ultimately finalize the MVP requirements so our Orchestration & Notification team could build out the digital experience.

The research as well as consultation with Forrester served as the foundation and guiding principles as we went through the development process. These principles included:

• Build an experience that fosters trust and respects customer privacy and choices​
• Collect only data we can act on​ – do not collect unnecessary data
• Design scalability and flexibility, between MVP to future platform​s
• Design consistency ​
• Configurable UI that can be personalized based off of customer eligibility for products and services
• Flexible data model that can handle changing products and services
• Strict adherence to Cisco data security and privacy standards

The new interface replaces two of our previous data collection customer experiences that were linked in our emails. Now customers have full access to:

• View all subscriptions associated with their email
• Activate/Inactivate subscriptions for Renewals, Services, and Adopt Emails at the Use Case or Solution level
• Continue to nominate contacts for respective subscriptions
• Provide feedback on the experience directly to the experience design team

This new system supports all of our critical integrations with Snowflake, Salesforce Marketing Cloud (SFMC), Cisco Single Sign On, and it can be integrated across other channels as well.

Implementation Changes

This new approach to subscription management not only transformed the front-end customer experience, but it also changed the granularity of data we were collecting. To enable it, we designed an entirely new back-end process to support the front-end application. We also had to make some significant changes to the data model and our custom activities in SFMC.

The new experience design

• The Notification Center UI, built on an SFMC Cloud Page, is supported by a Python-based Flask API, acting as an intermediary connecting the front-end with the backend database.
• We made the strategic decision to use PostgreSQL as our backend database, hosted on Google Cloud Platform’s Cloud SQL instance, to replace SFMC’s native Data Extension for storing customer choices and Custom Activity log data. We chose this because of the advanced data capabilities, indexing options, ACID compliance for data integrity, trigger support, and scalability.
• The database shift significantly reduced our reliance on SFMC as a database. This change decreased the overall number of SFMC API calls from 18 to 13 and increased the Custom Activity processing efficiency from 52 to 70 requests per second while concurrently reducing latency from 60 seconds to approximately 13 seconds.
• Digital journeys executed through SFMC previously had Cisco product architecture level entry criteria, meaning customers qualified for journeys if they bought a particular product. With the introduction of Notification Center data, we are mapping at the use case level, so we can build our journey segments based on the particular reason a customer bought a product. This transition has increased the granularity of our data while enabling a more personalized customer experience.
• Additionally, we enabled a daily sync between the Notification Center customer database and Enterprise Use Case Eligibility data to ensure Notification Center UI displays content in accordance with each customer’s eligibility criteria for a specific use case.

Source: cisco.com