Monetizing a connected product involves creating revenue streams from the product itself or the services it enables.

Within Servitly, through the Monetization module, you can enable and configure in the DPS the Store Experience allowing you to monetize your DPS solution. 

Main Concepts

To provide your DPS users with the Store experience, you first need to understand:

What do you want to sell?

Here is the list of products and services that you can sell:

• Service Levels enabling advanced digital capabilities of the connected products. 
• Spare Parts that can be replaced within a product due to sudden breakage or because they are subject to wear and tear.
• Consumables used by products during processing phases, and which require periodic refilling.

Each product can be associated with a Pricing Model, which can be a one-time purchase, or subscription based.

Who is the BUYER?

The Buyer generally is the end-customer, so the user of your products, but you can also allow your Partners (e.g. CAT, Resellers) to be Buyers for certain type of products (e.g. Spare Parts and Consumables).

For more details about Buyers, refer to the Buyers and Providers article.

Who is the PROVIDER?

The Provider is who sell the products and sell orders, and in a DPS solution it can be the OEM itself, or one of the sub-organizations (e.g. local area subsidiary), or a Partner (e.g. CAT, Resellers).

For more details about Providers, refer to the Buyers and Providers article.

Configuring the Store experience

In the DPS, the entry point of the Store experience, is the Store page which allows to:

• view the product catalog;
• manage subscriptions;
• manage the shopping cart and complete a purchase;
• manage orders;
• manage payments.

The Store page is available for BUYER and PROVIDER users, but depending on the user's role the functionalities will be slightly different. For instance only a BUYER can place an order, and only a PROVIDER can modify an order.

Here's a step-by-step guide on how to configure the Store page in the DPS:

1. Enter each View where you want to make the Store page available.
   Generally the Store page is made available to Operation Managers, and Back-office Managers (Organization or Partner), but you are free to enable it also to other personas.
2. Press the Add Page button and select the Store page.
   This will add the predefined store page and all its subpages.
   
3. If necessary, you can configure certain aspects of the store page, such as the label, icon and menu in which this page is visible (side menu, top bar or user menu).
   You can also define whether the page should contain the Catalog tab.
   Optionally, the catalog section can be embedded into a thing dashboard by using the Catalog widget. In this case the catalog content is automatically filtered according to the product model associated with the thing.
   Optionally, if your view is shared among multiple User Types, you can restrict the set of User Types that will have access to the Store page.
4. For each User Type, that will have access to the Store page, you must also configure the Permissions in order to improve Security (principle of least privilege) and enable the right functionalities according to what do you want to sell and who can buy products.
   See the User Permissions paragraph below for more details. 
5. Navigate the DPS with one of the views involved in step one, you should see the Store page in the menu.

For more details about how the Store page is structured, you can refer to the Store Page article. 

Catalog Access Point

The Catalog can be accessed by users in two points:

• Store Page: directly in the Store page as the first tab. This requires the user to select the machine or product model and then find the right part to purchase.
• Thing Details Page: from the buyer's point of view, it might be more useful to have the catalog automatically filtered by navigation context. This can be done, by using the Catalog widget placed directly in the Thing details page (dashboard). 

User Permissions

Each user accessing the DPS are associated with a User Type (e.g. Back-office Admin) which has a set of Permissions defining what the user can see and do in the DPS. 

To improve the security (principle of least privilege), also the store is subject to permissions, and by entering the User Types page, you will find a group of permissions named Store you can configure on each User Type. Note that, some permissions could be available only to certain user type categories (e.g. only Organizations and Partners can modify an order).  

Here are the permissions involved in the Store experience and their effect in DPS data access and UI.