Content Strategy Best Practices

Follow these best practices to build a scalable tenant and content management strategy.

Not having a carefully planned content strategy can cause inconsistency across your tenants. An ineffective strategy that fails to meet the product and tiering needs of your customers will lead to technical debt and rework. A scalable tenant and content management strategy minimizes the disruption and technical support overhead needed following a general availability release. You want to maximize reusability across different products and tiers, while retaining blueprint inheritance. For more information, see Blueprint Inheritance and Tenant Hierarchy and Blueprint Inheritance.

Defining modules

Best practices to help you design your modules, which determine what content is visible and available pertaining to specific solutions.

Develop a content strategy during the implementation phase

The design decisions that shape the content and tenant strategy will be a key focus very early on in the implementation phase of a project. Modules and related content created during this phase are a result of product packaging strategies defined early on in the account kickoff. Use cases and content strategies may also change after a solution scoping and design meeting with the Visier Partner Success team.

Develop a strategy that fits most permutations

Building an effective, scalable tenant and content strategy requires forward vision to ensure that all permutations of partner products, offerings, and tiers can be supported by a configuration that fits most permutations.

Define modules that serve multiple products

Think about all your products and tiers. Can one module per tier serve multiple products? Try to keep the number of modules to a bare minimum at the start of the project and think about reusability across products.

Define modules around tiers

As tiers generally define what features a customer can access, it is best to design modules around tiers. Rather than selecting module content for the specific tier, gate capabilities and content using the security model. Inheritance of object-to-module relationships is preserved this way.

Use generic terms when naming modules

Keep module naming conventions as generic as possible. For example, product tier naming conventions are common across products. If a product has a Bronze tier, do not append a product name to this tier name, as reusing this tier for another product is confusing.

Building Content

Best practices to help you curate and customize guidebooks for your solution.

Create a copy of a Blueprint guidebook before making changes

Building guidebooks for use by products will require a certain level of curation and customisation. We recommend that you create a copy of a Blueprint guidebook before making any changes to ensure inheritance is preserved. This means you will get the changes when the Blueprint guidebooks or analyses are updated.

Avoid labeling guidebooks with tier or product names

When curating prebuilt content, it is recommended not to label guidebooks with tier or product naming conventions but to maintain a product-agnostic approach where practically possible.

Use security to hide content

Avoid cloning custom guidebooks to make subtle changes; it is best to leverage security to gate specific content from appearing within these guidebooks. Creating specific analyses for specific products and tiers is normal, and these analyses will be gated by security and modules.

Do not make changes at the analytic tenant Blueprint level

Avoid making changes at the analytic tenant Blueprint level because you must maintain those modifications over time, and it will become difficult to manage over time and scale. Configuration for data models, concepts, analyses, and metrics should always be inherited from the parent admin tenant.