Sharing Data, Content across the DX Architecture
One of the essential tasks for customer communications management (CCM) is template creation. In fact, templates serve as the foundation of other types of communication created and distributed by other systems in the digital experience architecture. And really, there are only a handful of communication categories (e.g., brochures, contracts, correspondence, bills, statements, etc.) that are used throughout an organization.
In the "Age of the Customer," when companies are increasingly focused on customer experience and consistency of branding, messaging, etc. across channels, “the last mile” is to connect all of the systems of engagement together at the content layer, where assets and reusable objects are made universal and shared across the entire digital experience (DX) architecture, rather than being replicated across systems. Sharing content this way minimizes redundancy, maximizes resources and efficiency, and ultimately improves the customer experience.
In this article, we’ll look at the concept of sharing content in detail, looking at individual assets and ways to share them across your DX architecture. It’s not a short read, but worth the effort.
It All Starts with a Layout
When you’re creating a digital-first communication template, you start with a layout. The layout, as we’ve mentioned before, defines the relative position of content on a page or screen. As an example, correspondence as a category of communication has a well-defined, almost universal layout. We would typically expect to see, starting from the top, a header, opening, body, closing, and footer. Everyone can visualize how those pieces of content relate to one another on an 8.5 by 11-inch piece of paper. That’s a layout.
In theory, using this approach to openness and interconnectedness, layouts could exist at an enterprise level. There could be a repository somewhere responsible for storing all of the layouts that define all the types of communications an organization would generate – a statement, correspondence, newsletters, etc. Ideally, every department within an organization would use a single shared corporate layout for whatever communication type they’re going to create.
Making Styles Shareable across Applications
Then we move to the line of business or department that needs to create a specific type of communication from a shared layout. Say an administrator in an insurance company’s claims department needs to put together a piece of correspondence to request information from the insured to help settle a claim. There are additional enterprise requirements that this type of correspondence must meet. It has to follow visual brand guidelines, conform to the brand’s voice, use the correct logo, etc. These requirements translate into styles and formatting, like font choices, colors, line spacing, header sizes, justification, and more. These elements should match across touchpoints and channels for consistent branding and customer experiences. Like layouts, styles could be shareable at the enterprise level from a central repository, but they’re not (yet).
Today, that means someone has to go into each DX application and re-create the company’s approved styles, defining style sheets manually by selecting fonts, sizes, colors, spacing, and so on for things like headers, bulleted lists, image captions, addresses, body copy, quotes, signatures, etc. There’s a nearly infinite number of ways to brand communications, and branding has to be consistent across every application in every department.
At Topdown, we’re going to apply industry standards and define styles in such a way that any other app using the same open standard, CSS, could pick up and use. That’s assuming everyone can get at the central repository, though. Again, our approach is to create our repository from open source code, like Apache Jackrabbit (itself based on the JSR 170 and JSR 283 open standards), and will store all content in JSON to make it as reusable and open as possible. Style sheets will be made available through REST APIs, and any app that can speak REST (which is pretty much any app) will be able to use them. Users would then be able to make changes to styles in any app and then make those changes available again to every other app in the ecosystem that accesses that central repository. It just makes sense to go this way. It’s so much more user friendly and better optimized for business efficiencies.
Sharing Templates Throughout Your DX Platform
When you have a “single source of truth” – a central repository of shared objects and assets that include templates, layouts, and styles – and a portfolio of DX applications that can all interact with that single source, you’ll be able to optimize resources like never before. You’ll no longer have to duplicate resources across multiple databases and applications for use by individual departments for different purposes.
That’s not the current state for the majority of companies. For example, a typical CCM application will reach into a database, digital asset management (DAM) system, or other central repository to get customer data or objects like logos or images to use in the creation of documents, then make a copy of each asset in its own database. We’re working to make it so that duplication no longer has to take place. We’re leveraging the open standard CMIS to connect to content repositories to link to each asset rather than create another iteration of it.
With layouts and styles in place and easily accessible for all, and reusable content accessible the same way (stored as JSON in the central repository, or available via CMIS), we have most of the components of shareable templates. Now we need customer data to populate and business logic to further personalize communications for individual customers.
Data, Personalization, and Your DX Platform
Data can (and usually do) live in lots of places. Ideally, it’s defined in a single corporate system of record, like a customer relationship management (CRM) tool. But usually it’s spread across multiple systems. How do we get access to these data? With INTOUCH, we embedded open source data virtualization software to get that data for us. Variables then become just another asset in our repository. We let users alias the variables and call them what a human might name something rather than using the name of the mapped data element(s) in the system(s) of record, and we can operate on the data before it comes in. Call us crazy, but we think being able to reference a single “Customer Name” variable is a lot nicer than using “Policyholder.FNAME” [space] “Policyholder.LNAME”, or worse, having to write a SQL join statement. By using variables in templates, if there’s ever an update to any one of those elements (which there are all the time), we automatically inherit it.
At every single step, we’re making sure that our CCM solutions are as open as they can be, that they support relevant industry standards, and they allow any necessary integration at the data, content, and API layers.
Consistency can’t be a departmental solution. It requires collaboration and coordination of people, processes and technologies across an enterprise. You simply can’t achieve consistency with siloed solutions. How can you achieve it? With an open platform approach using open standards and open APIs.
Want more great content like this? Be sure to subscribe to our blog.
About John Zimmerer
John Zimmerer is the senior director of marketing at Topdown, where he leads market research and outreach efforts for the company's customer communications and customer experience products. Most recently, John has been researching and writing about the future direction of the technologies that power customer experience, and is regarded as a thought leader in this area. John has nearly 20 years of software product marketing experience. His areas of expertise include market research, analyst relations, public relations and digital marketing.