A couple of years ago, Zuora published their sales deck, which was hailed by strategist and thought leader Andy Raskin as being the best sales deck ever. Amidst the stunning narrative and the air of drama presented by CEO Tien Tzuo, there was a little glimpse on what Zuora calls the Subscriber Identity Record. Or, as a more generalised version would be appropriate, a customer profile stack — a tiered structuring of customer information that can be created, stored and consumed in any way best suited to an organisation’s business model.
The Holy Grail of Customer Data Management
Traditionally, all software companies have attempted to hold and own all customer records. For example, you can bucket Facebook user profiles into basic, interests, behaviours, engagements and transactional profile components. Salesforce, on the other hand, provides extreme customisation and flexibility in defining account/lead record models for their customers. For a niche product like Zuora, a rigid subscriber identity record makes sense as their key metrics revolve around subscriptions.
Whether it’s a bespoke software, or whether it relies on third party integrations, profile stacks range from simple normalised database tables to advanced, continuously updating, transactionally active data stores.
Do you need to build your own customer profile stack? Yes, definitely! If you’ve started building your product/app, chances are you’ve already built one. The richer your customer data, the wealthier you are. However, with there being an awesome SaaS tool for any business operation, what’s important is to know how much data you want to own, and where you want to draw the line between building your own customer information stack and leveraging the goodness of third party API integrations.
Why do you need to build one? It’s simple — because you want to know your customer in the best way possible.
Key Ingredients of a Great Customer Profile Stack
A profile stack is not a traditional user model. Nor is it a transactional history or a MongoDB dump of anything and everything a user has done on your platform. Also, a customer profile stack is certainly not an all-in-one system of storing whatever you know about your customer.
Instead, a great profile stack should be one that keeps the three levers of business operations in mind:
- The business model: What are the key business goals and metrics? What are the key drivers and motivators in support of your value proposition? What are the transactional parameters of your business?
- The user experience: What actions can a user take? What is the length of the onboarding cycle and experience? What are ‘good’ experience indicators?
- The sales process: What are the top-of-the-funnel buckets? Where are your leads coming from? What are the after-the-funnel segments?
In other words, a profile stack should include all the touchpoints in your customers’ lifecycle, starting from pre-sales, and ending in a continuous renewals and upgrades loop.
While designing a customer profile stack, it’s not necessary that to own, or even populate, all the above buckets. For example, in a consumer product, there might not be any company details under demographics. Or, for an e-commerce product, there might be simpler sales cycles with very narrow decision windows — in which case, pipeline movement and communication context are fairly irrelevant. It is, therefore, extremely important to always understand and implement customer identities in accordance with the three main ingredients.
Customer Profile Stacks in the Age of API Integrations
Software, arguably, does not call for ground-up development any more. Instead of writing software that does everything, you want to write software that does one thing exceptionally well. Open-source and other SaaS integrations available for each peripheral service (e.g., invoicing, scheduling, communication etc.) allow you to write software that only focuses on your value proposition to the customer. But as a fallout, do you risk losing out on the opportunity to own that single source of truth?
To answer, here are some considerations that you can throw up in your next tech meeting:
Is your system of record convergent or divergent?
A convergent SoR is one that pulls data from disparate systems, while a divergent SoR sends data to disparate systems. Convergent stacks work better when you’re aggregating data for analytics or data-driven actions. On the other hand, divergent stacks work better when you intend your customers to initiate actions from your system, and use your system as the primary point of contact.
Is your system or record an action set or a storage set?
In other words, does your SoR, for example, keep track of invoices or does it also send invoices to customers? If the actionables are not central to your proposition, best to trim it out and let a third party API handle it for you.
Do you need decorative profile buckets?
Mostly, this is a no — you only need what you need. However, there could be cases where you’re using a, say, third party ticketing system and you need to provide custom labels for issue types for in-house analyses. Or, there could be cases where CRMs or ticketing systems are unable to fulfil your support process.
Is your system of record aware of your customer states?
This is perhaps the most important consideration while defining a SoR, and probably takes priority over all other considerations. Your system may not need to perform peripheral actions, but needs to be aware of all transactions and actions that are being passed on to APIs.
In other words, your SoR is that empathetic manager who is on top of what her employees are up to, does not interfere in their functioning, yet gets her hands dirty whenever needed.
We’re building an intelligent profile stack for cloud service providers to manage and monetise their cloud offerings. If you’d like to know more over a cup of coffee, just drop us a line.
