Watson Commerce Ideas

Submit new product ideas for Watson Commerce Offerings including Digital Commerce, Websphere Commerce, Watson Content Hub, Watson Commerce Insights, CPQ, Dynamic Pricing, Order Management, Inventory Visibility, Store Engagement, Watson Order Optimizer, Price Optimization, Promotion Optimization, Markdown and Deal Management. Before you submit, please review existing ideas; if an idea close to yours already exists, it's better to add comments or vote on the existing idea. We will review your ideas and use them to help prioritize our product development. Best of all, the portal will automatically update you when the status of your idea has been changed.

Connect with your peers and IBM experts on the Watson Marketing and Commerce Community

Submit ideas for other Watson Customer Engagement Products:

  • Watson Marketing
  • Watson Supply Chain

Make/Configure To Order Product - Native Model Support

This idea would address the need to offer/sell products that are more of a "make to order" or "configure to order" model natively using a dynamic SKU creation model.  Currently the native product model would be comprised of a main product which would then have attribute selectors for the various properties of the product, which ultimately refine down to a purchasable SKU in the catalog.  This is controlled using Defining Attributes.  In this model, the final resulting SKU needs to actually exist in the Commerce catalog.  There is by default a 500 SKU limitation.  In this model, the actual SKUs you'd need to manage would look like this:

Primary product with 1 attribute with 5 possible values = 5 SKUs
Primary product with 2 attributes with 5 possible values each = 25 SKUs
Primary product with 3 attributes with 5 possible values each = 125 SKUs
Primary product with 4 attributes with 5 possible values each = 625 SKUs

Additionally, we have the Omni Configurator tool which integrates with WebSphere Commerce and essentially various "options" in a configurable model relate to/reference actual SKUs in the WebSphere Commerce catalog.  So possibly many of the choices or options, would just point to a single SKU in the commerce catalog/database.


This idea is to allow for attributes to be specified or categorized in a different way so they can be used to "define" a product, but won't actually generate all of the underlying SKUs like today's current model, if the product was selected as a "dynamic product".  It also wouldn't have the dependency on Omni Configurator as a separate solution which needs the underlying SKUs in WCS for checkout.

This model would allow a user to land on a product page and select properties from drop downs and since it'd most likely be a custom or unique configuration, it wouldn't have an actual final SKU in the catalog DB.  So this capability would essentially build/create a unique SKU on creation specific to that order.

Once example of this would be a video console game controller:

Possible Options To Define/Select:

  • Main controller chasis color:  Upload a custom image/photo, pick a color or a combination of both
  • Button colors
  • Joystick colors
  • Personal engravings (name or gamer tag or console serial # or custom user entered values)
  • Color for L1, L2 or R1, R2 triggers/buttons

 

 Another example could be commercial paper products:

In this example, you'd have possibly 3 attributes (ie:  Length, Width and Core Size)

Length:  Potentially hundreds of attribute values as they offer lengths in 1/8" increments
Width:  Potentially hundreds of attribute values as they offer widths in 1/8" increments
Core Size:  Potentially hundred of attribute values as they offer core sizes in fractional inch increments

 

In the above example, if you were to build this all out with defining attributes (current model), you would end up with so many possible SKU variations in the Catalog tool, it'd be a nightmare to manage.  If we were to leverage Omni Configurator you'd need a way to properly expose/reveal custom defined properties that aren't actually defined by attribute selectors on a product page.

 

Assumed Dependencies:

Dynamically generated SKU would need to persist for the sake of re-orders, shopping carts and order management / fulfillment systems.

Dynamically generated SKU would need to be able to honor B2B contract, pricing and catalog filters.

  • Avatar32.5fb70cce7410889e661286fd7f1897de Guest
  • Feb 4 2019
  • Needs review
How will this idea be used?

This idea is submitted to enhance and update the base product catalog model/tooling/options available in core Commerce without requiring add-on solutions.

What is your industry? Retail
What is the idea priority? Medium
DeveloperWorks ID
RTC ID
Link to original RFE
  • Attach files
  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    05 Feb 11:43

    Yes, I like the idea of being able to generate SKUs on the fly during the ordering process, and have seen the same requirements with many customers before. Presumably this will require strict housekeeping support too, to purge any unused SKUs right away and only keep the ones that have been submitted in an order, or at least kept 'alive' in active shopcarts.  So we would effectively end up with a SKU collection of product variations that the end customers are actually wanting & buying. Yes, effective housekeeping is key here. Thanks Brian!

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    05 Feb 14:41

    Great point!  Somehow while being a dynamically generated SKU, only for that user's configuration, it would need to be made available to them in the future if they want to repurchase, but since the concept is uniqueness for that user, it couldn't/shouldn't be available to other shoppers nor should it show up in search results in the catalog, yet it does need to persist for cart, order management and re-order needs for that user.

  • Avatar40.8f183f721a2c86cd98fddbbe6dc46ec9
    Guest commented
    05 Feb 14:42

    Perhaps it's be a similar BOM like Configurator uses...