We did one session with Anuj on Enterprise Product Catalog (EPC) Best Practices. This post will talk about what is EPC and different best practices to implement the product catalog in Industries CPQ project. Products define a Company. Company generates value through Products. Customer pays for the value from Products.
Best practices driven Product Models development in a shared Enterprise Product Catalog (EPC) benefits from:
- Quicker Time to take Products and Propositions to market.
- Cost reduction in developing and taking Products and Propositions.
- Flexibility to create newer Offers and Promotions.
- Differentiate in market by right Pricing and Promotion strategies.
- Minimise proliferation of Specifications by inheritance and reuse of model components.
Why use an Enterprise Product Catalog (EPC)
- Product Catalog is a key building block in any Sales journey.
- SFI EPC contains all commercial product information that enables product managers to define and map new product offerings.
- It contains technical information that enables fulfilment managers to define and map to the required order fulfilment process.
- It is used by CPQ, Digital Commerce and Order Management.
- You perform product design, pricing, product life cycle management, product versioning, and product publishing.
Enterprise Product Catalog
Enterprise Product Catalog is a combination of Commercial and technical products. Commercial product are what the customer sees and technical products are what the back-end sees. Communication cloud (Vlocity CPQ) is a combination of EPC, CPQ and order management. EPC, CPQ and Order Management Enable Business Agility.
Enterprise Product Catalog (EPC) Best Practices Video
Check out our Enterprise Product Catalog (EPC) Best Practices session recording.
Commercial and Technical Catalogs
Approach the product modelling by separating two aspects of the product i.e. commercial & technical.
What is Commercial Catalog?
Commercial Catalog which will consist of all the commercial products which will be sellable to customers. Here is Commercial Catalog Example.
What is Technical Catalog?
Technical Catalog which will consist of the products which will hold the service layer information for the corresponding commercial products and these technical products are non-orderable so these will not be visible in the cart.
Why it is important to define separate catalogs for commercial & technical products?
- To avoid loading unnecessary technical information into the CPQ cart which is not required by the customer.
- To avoid creating service layer products under the bundle or individual offers to just pass the information to provisioning system.
- To avoid the deep hierarchies of bundles.
- Will help to improve the performance of CPQ Cart.
Catalog for Communications Industry
Enterprise Product Catalog (EPC) Best Practices
Let see Enterprise Product Catalog (EPC) Best Practices in details.
Product Model Solutioning
- If there are multiple solution options then define them.
- List pros and cons of each option.
- Make use of Proof Of Concept studies – this will help greatly in evaluating the pros and cons.
- Define your selection criteria.
- Score your criteria against each option and summarize your results.
- Review your options with knowledgeable reviewers and provide a recommendation.
- Inform all key stakeholders to get consensus and buy in for the preferred option.
Simplify
- Digital Transformation efforts are accelerated when simplification is established as a key principle:
- Objective is not to reproduce existing processes, rethink…re-invent
- Rationalize products and aim for re-use, instead of creating multiple permutations and combinations of similar products, for example, a mobile handset with a different color and storage options.
- Avoid modelling products to make order-capture look better, such as introducing a hierarchy just to collapse available product options.
- For guided selling flows, minimize attribute capture and use default values and overrides to improve the accuracy of order capture.
- Limit custom implementation to when necessary, code heavy implementation will lead to longer release time and technical debt will slow innovation.
Asset Migration
Take into consideration asset migration if there is a need to migrate legacy assets into the Salesforce platform. Some questions that maybe asked during the migration process.
- Who owns the data?
- Where does my source data live?
- Do I have access to my data?
- What format is my data in?
- Do I need to cleanse or deduplicate my data?
- How much data do I have?
- What data do I truly need?
- What is the target production date?
MACD – Considerations
Take into consideration all your journeys that need to be supported.
- Add – This is normally referred to as Provide.
- In -flight changes to the Provide journey – Amends – Customer would like to make changes but continue with the order.
- In -flight changes to the Provide journey – Cancel – Customer wishes to cancel the order.
- Disconnect – Customer wishes to cease their service.
- In-life service changes – Customer wishes to change their service.
Think Downstream – Order Management
Your SFI Communications solution may or may not include SFI Order Management. If so, consider the technical catalog model as early as possible in design. Modelling in SFI Order Management begins with design-time configurations that result in the running of dynamic workflows to fulfil the products, service and resources defined on orders.
The process of order management leads to creating the assets for the customer. This occurs when the product is being provisioned and external systems must be contacted to book or provision the product.
The assetization process creates, updates, or deletes assets and technical inventory items. Technical items, also called inventory items, are the realization of customer-facing services (CFSs) and resource-facing services (RFSs), just like assets are the realization of commercial products.
Commercial and technical catalogs related attributes should be parted to prevent unnecessary handling.
Identify Pricing Patterns
1. Fixed Pricing
❏ Fixed pricing is used most often. A charge can be one-time or recurring but the amount is always the same for a given offering, regardless of service configuration or other conditions. This pricing pattern is similar to product pricing in groceries.
2. Conditional Pricing
- Conditional pricing is the pattern when the price (can be one-time or recurring) for a product offering depends on a simple condition. For example, a service provider can include a free cable modem if a customer signs up for a 12-months contract. Otherwise, the modem is offered for $75. Another example is free shipping on orders over $25.
- Conditional pricing can be thought of as the simplest example of attribute-based pricing, which is tailored for complex conditions with multiple criteria.
3. Promotional Pricing
- Promotional pricing is used by service providers to create interest, increase market demand, generate sales, or create brand loyalty by temporarily offering products and services at lower (compared to standard) prices. More attractive prices (can be both one-time and recurring) can be defined using both absolute (in currency) and relative (in percent) approaches. Promotions are designed to be time-bound and are tied typically to some event, holiday, or period. Bundled
4. Bundled Pricing
- A single price is specified for a bundled offering, while prices for bundled items are waived (zeroed).
- A bundle price is defined as a sum of bundled item prices, while prices for all or some bundled items are discounted.
5. Custom Pricing
- Some service providers have unique requirements to price the product in such cases, Pricing can be customized based on the requirements ( Not recommended unless pricing can’t be achieved by OOTB solution).
Product Attributes
Attributes are “Characteristics” per TMF. It can be thought of as product features. For each product record, there are additional information that can be associated without requiring customization in Salesforce (no custom field, data is stored as Name/Value pair for each of the following features/specs as “Attributes”):
Note: There is no hard and fast rule around what is to be defined as a product vs an attribute. It depends on many things like customer requirements, existing application ecosystem etc.
Rule of thumb: An attribute cannot be added to cart without having a product first.
Attribute Data Modelling
- Maintain a pure product specifications as much as possible. Product details that support the ordering of the product should be kept to a minimum in EPC and strive to model this data outside EPC.
- Product supporting data can be modelled in the order, order line or other standard Salesforce objects if appropriate eg Account, Site, Premises etc.
- In some situations it is appropriate to define a custom object to hold a group of data eg Product qualification
- Ensure only commercial data is modelled in the commercial layer and avoid modelling technical data requirements for downstream systems in the commercial layer
Categorise Attributes
- Pricing Attributes ( Customer/Resource Facing): Attributes that are required that will have an impact on product price.
- Provisioning Information (Customer Facing). Not needed for Pricing: Attributes that are required from the customer. 2 options to consider. If assitization is required then capture in EPC otherwise can be captured against the order if information isn’t required for assitization.
- Provisioning Information ( Resource Facing) : Information needed for downstream systems and not provided by customer. This should ideally be maintained in the Technical catalog.
- Service Information from downstream: Sometimes downstream systems may provide data back to the customer – eg IP address values for network configuration. This data will be populated in the commercial layer during the order fulfilment journey.
EPC Performance Considerations
- The depth of the offer has a major impact on CPQ performance. We recommend minimizing it and to aim at not having more than 4 levels.
- Deep product hierarchy will make the product bundle heavy and will significantly impact API performance.
- We usually recommend leveraging attributes and design fewer products and offers when it makes sense from a business standpoint. While the initial benefits may not be so obvious, a catalog will typically grow rather quickly and not only the performances will be impacted but the related maintenance will become increasingly complicated.
- Commercial and technical catalogs related attributes should be parted to prevent unnecessary handling.
- How a product is displayed in the UI does not need to match how it is modeled. Avoid using visually appealing cues to drive product-modelling decisions.
- You should also consider MACD scenarios, which are more complex than new-provide user stories.
- Use Virtual Products if you need a logical grouping, for instance, you could group all Add-ons together.
Context Rules and Advanced Rules Frameworks
Vlocity has two rules frameworks that work in tandem: context rules and advanced rules.
- Use the context rules framework to determine what products, promotions, and prices appear in Vlocity cart. You can specify when to apply a penalty for cancellations and what the penalty will be.
- Use the advanced rules framework to design product compatibility rules based on conditions in order line items and related objects. You can also create advanced pricing, availability, and eligibility rules.
You can use rules to change standard product and pricing behaviors in Vlocity Cart. Vlocity rules are essential to creating the perfect order. You control all the products and services you offer to your customers, and offer them at the right prices.
Context Rules or Advanced Rules: What Type to Use?
Because context rules and the advanced rules frameworks work together, you must determine what type of rule to use to accomplish your business objective.
Always prefer context rules unless key functionality is not supported.
Context rules and advanced rules support slightly different functionality, so it’s important to understand these differences to determine the best type of rule to use. You must fully define your requirements end-to-end before you can map your requirements to the rules functionality matrix below.
What object will the rule apply to? Will it be used to determine eligibility for a product or promotion? Will it apply pricing? Will it apply a penalty when canceling a promotion or a contract?
At what point in the order capture process will this rule apply? Will the rule evaluate items before they are placed in the cart in an order, quote, or opportunity? Will it be used to evaluate the line items after they are in the cart?
Rules best practices
- Understand your customer requirements end-to-end before you decide on which types of rule to use.
- Consider reviewing business processes and related requirements to reduce rules complexity.
- Ensure all active rules are not missing configurations.
- When possible, leverage cardinalities or override functionality instead of advance rules.
- For performance considerations, it is recommended to use context rules instead of advanced rules for penalties.
- When possible, consider grouping rules using common entities.
- Keep entity filter’s conditions to an optimized number (max 2).
- Avoid creating too many auto add/remove rules as these rules are validated each time the APIs are invoked instead try to utilize Cardinalities and overrides.
- Ensuring you enable cacheable mode, have populated values for caching, and default values for context dimensions to cache eligibility combinations.
- Avoiding user-specific logic (rules, context rules based on contact data)
- Avoid writing too many rules for each and every business scenarios it could make the cart validation slow and performance will be impacted.
Modeling Patterns
1. Hierarchical Pattern
A hierarchical pattern is a design option when the following conditions are met:
- Bundled items are an offer option or add-on not sold as a standalone offer.
- Bundled items have an explicit price.
- A request for a hierarchical representation of the item composing the commercial offer is made.
- Different commercial offers have the same service with different cardinality and prices.
- It contains both a single relationship and group cardinality that applies to embedded bundles within a hierarchy.
- The number of items in the bundle increases. A linear representation might have these negative results:
- Complex to read for the end-user
- Hard to configure for the administrator by forcing a hover of advanced rules, and complex Move, Add, Change, Delete (MACD) logic.
| Pros | Cons |
| ● Efficiently manage the cardinality requirements without using advanced rules, such as the minimum/maximum/default cardinality and group cardinality. ● Define reusable components across different EPC bundles, saving time and offloading the maintenance effort. ● Cardinality requirements of product bundle components are easily satisfied in a hierarchical product structure. | ●The front-end application of order capture needs to render the complete product hierarchy of mandatory as well as optional add-on children products |
2. Offer Meiosis Pattern
An offer meiosis pattern is a design option when the following conditions are met:
- A bundle add-on defines a different offer than the initial bundle from a business perspective.
- Bundle items have an explicit price.
- A hierarchical representation of the item composing the commercial offer.
- The same service belongs to different commercial offers with different cardinality and prices.
- There is a wide need for cardinality rules in a single relationship and group cardinality.
- The number of items within the bundle starts to increase. A linear representation might be too complex for the end-user to read.
- The two offers have some diverging configurations, such as these examples:
- Offer A includes some options not included in offer B.
- Offer A and B have two different prices for the same service.
Considerations
The offer meiosis could mix the linear and hierarchical patterns. This mix is a different pattern because it represents a different and distinct modeling option compared to the linear, hierarchical, and attribute-based patterns.
- Carefully evaluate how the model is applied and used during the MACD scenarios.
- EPC architects should carefully evaluate how this model is applied and used during the MACD scenarios to avoid creating bulky orders.
- Hierarchical representation doesn’t represent catalog categories.
- Hierarchical structures should omit any product used to represent service fees, such as shipping fees, installation fees, and penalties
3. Linear / Relies-On
A linear pattern is an option when the following conditions are met:
- The new item is not requested to be represented as hierarchically related to another commercial offer.
- The item is not requested to have different price or cardinality rules based on other commercial offers.
- The number of offers and relationships managed with advanced rules is limited, and the advanced rules don’t have complex conditions.
Considerations
For limited cardinality rules or product relationships, the same model may be applied by relying on some product capability, such as the following:
- Advanced Rules: Auto Add, Auto Remove, Requires, Exclude
- Product relationship: Such as Requires, Relies On, Excludes, and Recommends
This mainly applies to Offering Management (OM)-specific requirements with a request to represent a connection between two separate commercial offers that have provisioning dependencies or connections. For example, the Sports entertainment package is a standalone commercial offer that can be sold independently from any other offer, but it relies on a specific setup box or smartcard.
4. Attributes Based
An attribute-based pattern is a design option for items that meet the following criteria:
- The item is seen as a characteristic of the main offer and is not a standalone offer.
- The item does not have an explicit price.
- The item is not subject to the target of advanced or eligibility rules.
- From a functional perspective, the item should be a characteristic of the assigned product.
Considerations
EPC is where you model and define the technical products to use in the decomposition and fulfillment steps. EPC provides the concept of ObjectType to confer the aspect of inheritance to the product model.
Specifications in the Technical Catalog are defined like other products, meaning that most of the fields you configure for the Commercial Catalog also apply. However, there are some differences: The technical specifications do not need pricing, and the product should never be orderable.
There are likely no attachments as the product is never exposed in CPQ. You also can manage product attributes through EPC and use appropriately designed layouts to simplify product creation. Therefore, it’s highly recommended that you design the Technical Catalog using Object Types.
You model the Commercial Catalog from the perspective of the order capture and assets created for a customer. However, you model the Technical Catalog to meet the technical fulfillment requirements and simplify integration with fulfillment systems.
Here are the two main approaches to modeling a Technical Catalog:
- Hierarchical Modeling: This model comprises the Customer-Facing Service (CFS) and RFS layers. The CFS layer confers an abstraction of the RFS layer that is less technical and more understandable from the commercial side.
- Linear Modeling: This model is only concerned with the RFS layer and is modeled to support the integration with fulfillment systems. Linear modeling is typically less complex because of fewer decomposition relationships and mappings.
Summary
I hope this Enterprise Product Catalog (EPC) Best Practices will help you for a better Vlocity CPQ implementation.
