Any organization that sells a solution with many options, components, or parts has a significant challenge when it comes to providing documentation for their customers. When a new product is launched, someone has to produce a document. That document might be the long, carefully folded insert in an unreadably small font that warns customers about important things like not using toasters in the bathtub or refraining from holding a chain saw from the wrong end (I did not make that one up).
Or it might be a repair or service manual that is hundreds of pages long.
Products need accurate documentation for compliance purposes, but they also need it for customer support (whether call center support or self-service), or for solution development. Documentation also is used for educating customers in presales situations where they are trying to decide on features and configure choices.
When solutions are complex, the documentation needs to be adapted to different scenarios; i.e., if products have many possible configurations, are comprised of subassemblies and other products, or are custom configured to meet specific needs. This task is not trivial but is critical to providing content that is tailored to each product and in some cases, to the different languages spoken or skill level of customer service reps.
Failing to keep content in alignment can lead to many problems if not performed in a consistent, systematic, well-designed manner. Complex configurable products and solutions can have large numbers of possible combinations and variations that can lead to a “combinatorial explosion” where documentation costs skyrocket and become economically unsustainable. This leads to higher support costs and workflow and logistical problems with updating documentation throughout the product lifecycle. Many traditional content, document, or knowledge management and product information systems are not built to support documentation for products that have large numbers of variations in configuration.
The answer is to break content up into smaller, reusable pieces that can be reassembled based on configuration choices. This approach ensures that the correct content is associated with each configured product variation. It allows customer service reps to locate specific knowledge associated with product combinations and variations, and can also automate conversational access to question-answering systems.
Component content can be used in a variety of ways, either feeding downstream systems (website, customer support, configure price quote, etc.). It can also be fed by upstream systems such as product information and product content management systems.
Product Content Management (PCM): PCM is a technology used to manage rich content and product attributes for marketing and eCommerce. It is more suited as an end point than an integration point. What does that mean? PCM is a good place for final digital assets used in eCommerce and marketing – the various media such images, videos, audio, design files as well as information rich specification PDFs and documents. Product attributes and metadata can also be stored in a PCM. However, PCM’s are not necessarily good at taking information from multiple feeds, manipulating it, and syndicating it out to other systems and channels.
Product Information Management (PIM): PIM is used to orchestrate, integrate and syndicate product data. PIM on the other hand, is purpose-built for such integration, transformation, and syndication of data out to multiple channels, consuming platforms, and applications. PIM is best suited to taking in information from multiple systems, harmonizing and integrating that information, and preparing it for downstream consumption through enrichment, merging information sources, or data quality scoring and remediation. This allows an end point tool to then serve it up to a customer via eCommerce sites or push it out as part of marketing campaigns. PIM is the traffic cop, whereas PCM is part of the customer experience platform.
Configure Price Quote (CPQ): CPQ brings together content and data from multiple systems to provide pricing and prepare proposals and contracts. That data may come from a number of different systems; an ERP system for equipment pricing or licensing calculations and financial details, a PIM to retrieve product specifications, a component content system to add boilerplate language, or descriptions of different modules that are substituted depending on user requirements. Contract clauses and legalese for proposals and agreements can be switched in and out, as well as related financial terms and details.
Within one unified architecture, upstream component content can feed downstream PCM, PIM and CPQ applications as well as customer support and self-service.
Data flows can become quite complex for large distributors and manufacturers when data governance, reporting requirements and supplier/partner/distributor feeds are added in.
Various industries can benefit from component content. Manufacturing, aerospace, and customer support are good examples for how content chunks leverage the product data model to make sure the right component goes with the right product.
In machinery manufacturing, multiple types and models of industrial machines are available to meet the needs and specifications of each customer. Each customer receives a custom configuration of the machine, and maintenance engineers must have quick access the documentation on the machine requiring maintenance. Since troubleshooting procedures can be complex and involve multiple configuration-specific variations, having the correct content is critical. Without that (for example, if the maintenance engineer relies on generic content), support calls increase because the purchaser cannot find what they need, and customer satisfaction decreases. Customer support will require a greater degree of effort due to a large amount of configuration-specific variations. Add to the mix the need to provide the document in multiple languages - sometimes product content is translated to over 30 languages - and the cost becomes prohibitive.
Each aircraft model has multiple modifications, so no two aircraft have the same configuration. When an airline receives a custom configured aircraft, all modifications that differ from the base model have to be properly documented. The approval and review process to ensure compliance with industry regulations is also very complex. These requirements combine to place heavy demands on documentation. Given the complexity of an aircraft, the need for a detailed breakdown on content is clear.
Many companies grow through acquisition, and supporting multiple products and product lines with a large and growing customer base is a problem for which component content is part of the solution. Customers are looking for personalized, precise, and accurate product content that helps them resolve specific issues. Providing high quality customer support requires highly qualified support personnel. However, regardless of training and experience, support reps require access to accurate and timely information in order to maintain a high level of customer satisfaction. The presentation of content must also take into account the language skills of overseas personnel, who may not speak English as a first language. As with machinery manufacturing, a global customer base in an acquisition scenario also may mandate multi-lingual documentation.
A more generalized benefit of componentized content is that it can be served up through a chat interface and a chat question answering/FAQ bot automatically generated from this approach. Chatbots are a channel, and once product data is aligned with component content, they can be made more portable, scalable and reusable, making them more economically viable. In the future, a maintenance engineer will be able to walk up to a machine and ask it what maintenance procedures it needs or, with the right integrated diagnostics what parts need to be replaced.
Many elements need to be aligned for component content to correctly support complex configurations. This begins with the correct taxonomies – a hierarchical, parent child whole/part collection of terms representing products and concepts related to the support and service of those products. Multiple taxonomies represent various elements of the knowledge and product domain: Product categories, product families, product type, solutions, troubleshooting processes, problem topics and more. It is not unusual to have ten or more hierarchies or facets. These dimensions of knowledge concepts and their relationships (troubleshooting processes for each product type, for example, problem topic and solution pairs, etc.) become the ontology. The ontology is the knowledge scaffolding for the organization. Content models, metadata structures, content profiles, components and standards are designed using the ontology. Until this structure is in place, component content is not feasible.
Our webinar, Complex Product Configuration: The Intersection of Knowledge Management and Product Information Management inspired this post. Access the webcast here.
To discuss piloting a component content/product data project, feel free to reach out to me at seth@earley.com