You as an organization have tried to communicate a digital offering to the market. You know that it is a big challenge to organize your customer touchpoints (Channels, eCommerce stores, mCommerce, and catalog). It is a relatively straightforward thought process to decide on colors and strategies for achieving a great customer experience on paper, because these are all very visible challenges. But to generate the content that will create the story of your products, and get it out to all customer touchpoints with consistency is very hard over time. However, this content is the foundation for giving your customer that great experience. The information you want to get out to your channels must be rich in content to tell an inspiring story around your products. This is basic information logistics.
There are three basic rules when working with information logistics and moving product information across channels in an efficient way.
- Keep information as clean as possible – for easy channel integration
- Information needs context to be understandable – Create an attractive product offering for a specific channel
- Context disrupts flexibility of information – To much channel-specific information will make it harder to share cross-channel
These are all contradictory rules, which is why it is a challenge to keep a consistent and inspiring story around your products in all customer touchpoints over time. The challenge is to know where to draw the line; you must know what information is needed for generating a great customer experience, but you must also know where the line for flexibility and adaptability to all customer touchpoints goes.
Here I would like to stop and highlight inRiver´s fantastic partner community with well over 600 certified consultants from the inRiver Academy. With the skill, knowledge and ingenuity that this community has acquired, combined with the way inRiver is architected, we have a very good recipe for creating and building flexible and agile solutions for our customers. This is something we believe makes us very strong: our community.
If we take a look at a specific area where this mix of Community & inRiver Architecture is very useful, it is in the decision-making process where a business challenge is addressed. Should this challenge be addressed within the platform, or should it be addressed in the framework around the platform? Obviously there are a lot of answers to this question, but these arguments can be made:
- The more functionality you build into a platform, the more narrow it will become for certain use cases - and the less useful and adaptable it will become to changes in that use case.
- The more decoupled you can be in your platform, the more antifragile you will be - and the more easily adjustable to future changes your platform will be.
One area where this is truer than others is information logistics, where information travels in and out of different domain models. More often than not, these models change in either format or the information they require to perform.
So when information is onboarded to a platform, the information arrives as data in a specific format. When it is released, it goes out as enriched information, with more data in a new format. To excel at this, it must be easy to add new fields, or new content - but also easy to adjust the format of the data structure when building a solution.
When making a platform choice, I believe you should seek to minimize your exposure to risk, and maximize the gains (create better product stories and customer experiences) for your organization. We all know that implementing a large platform is always tightly linked with corresponding large risks. You can never have 100% control over the risks involved when implementing new platforms, but by choosing an agile, purpose-built, best-of-breed platform, you will probably minimize your exposure to unknown risks when moving forward.