Open APIs

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Experts, Any advice on this please ?

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Hi Mahesh

It seems to me that your challenge is primarily one of bill presentment, rather than the underlying charge calculation. I don't think it's scalable to add offerings and prices for each possible combination of characteristic values.

So I would isolate this logic in your bill presentment solution, and keep the charge calculation model as simple as possible.

Please note that I am working on an enhancement to the Product Catalog API TMF620 signatures, to allow easier modeling for parameter-driven pricing. It's early days yet so I cannot tell you when this enhancement will be released.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 06, 2024 23:22
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Experts, Any advice on this please ?

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 01, 2024 22:40
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd
------------------------------

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Hi Mahesh

I'm going beyond what your table shows, since in my view also the contract term can be regarded as a pricing parameter, even though it's a property of ProductTerm and not formally a characteristic. Similarly for channel, which is a reference from ProductOrder and not a characteristic. So the entire table could be attached to a single POP. if that's the way you want to implement things. And for acquisition vs retention.

Of course maintenance is needed to add new combinations to the table, but no more than would be needed with the current approach, adding an entire POP for a new combination.

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Hi Mahesh

I'm going beyond what your table shows, since in my view also the contract term can be regarded as a pricing parameter, even though it's a property of ProductTerm and not formally a characteristic. Similarly for channel, which is a reference from ProductOrder and not a characteristic. So the entire table could be attached to a single POP. if that's the way you want to implement things. And for acquisition vs retention.

Of course maintenance is needed to add new combinations to the table, but no more than would be needed with the current approach, adding an entire POP for a new combination.

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

Hi Jonathan,

If there is any further work/progress on this, could you please let the community know. I believe, this is an excellent approach to how things are modelled right now. Would be great to know if there're better ways of handling this.

------------------------------
MMH HH
Vodafone UK Ltd

Original Message:
Sent: May 15, 2024 06:22
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi Mahesh

I'm going beyond what your table shows, since in my view also the contract term can be regarded as a pricing parameter, even though it's a property of ProductTerm and not formally a characteristic. Similarly for channel, which is a reference from ProductOrder and not a characteristic. So the entire table could be attached to a single POP. if that's the way you want to implement things. And for acquisition vs retention.

Of course maintenance is needed to add new combinations to the table, but no more than would be needed with the current approach, adding an entire POP for a new combination.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 15, 2024 04:16
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 04:14
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 03:49
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 14, 2024 06:34
From: Matthieu Hattab
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 01, 2024 22:40
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd
------------------------------

Hi,

Jonathan has left Amdocs to start a new life as a pensioner.

to follow up the current work on this API, you could follow the progress from TMF Wiki and from TMF JIRA. Search for Jonathan

to be honest, I feel that you requirement can be achieved in different ways but everyone has a preference.

Last month, I saw a demo of a TMF-compliant product catalogue ODA component and the creators chose to use Policy for all pricing rules, even when the SID or the API would support the pricing requirement without a policy. The rationale behind using Policy is to have a single management tool for pricing.

with a policy, you have total flexibility. I'm myself investigating this approach with some open source rule engine.

For instance, Camunda DMN offer a friendly UI to manage "decision table" that looks very much like your post from "May 15, 2024 04:15"

Decision table sounds a lot like what Jonathan was trying to achieve but within the product catalogue.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Tele AS

Original Message:
Sent: Jan 27, 2025 07:21
From: MMH HH
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi Jonathan,

If there is any further work/progress on this, could you please let the community know. I believe, this is an excellent approach to how things are modelled right now. Would be great to know if there're better ways of handling this.

------------------------------
MMH HH
Vodafone UK Ltd

Original Message:
Sent: May 15, 2024 06:22
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi Mahesh

I'm going beyond what your table shows, since in my view also the contract term can be regarded as a pricing parameter, even though it's a property of ProductTerm and not formally a characteristic. Similarly for channel, which is a reference from ProductOrder and not a characteristic. So the entire table could be attached to a single POP. if that's the way you want to implement things. And for acquisition vs retention.

Of course maintenance is needed to add new combinations to the table, but no more than would be needed with the current approach, adding an entire POP for a new combination.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 15, 2024 04:16
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 04:14
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 03:49
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 14, 2024 06:34
From: Matthieu Hattab
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 01, 2024 22:40
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd
------------------------------

Thanks @Matthieu Hattab. Did you investigate this approach of using decision table policy for flexible pricing? I would be very much interested in this to collaborate.

Btw, @Mahesh Kothamasu what is the TMF standard term to depict the process (Acquisition, Retention, etc)? I've seen some people referring to it as 'journeys'. 

Hi,

Jonathan has left Amdocs to start a new life as a pensioner.

to follow up the current work on this API, you could follow the progress from TMF Wiki and from TMF JIRA. Search for Jonathan

to be honest, I feel that you requirement can be achieved in different ways but everyone has a preference.

Last month, I saw a demo of a TMF-compliant product catalogue ODA component and the creators chose to use Policy for all pricing rules, even when the SID or the API would support the pricing requirement without a policy. The rationale behind using Policy is to have a single management tool for pricing.

with a policy, you have total flexibility. I'm myself investigating this approach with some open source rule engine.

For instance, Camunda DMN offer a friendly UI to manage "decision table" that looks very much like your post from "May 15, 2024 04:15"

Decision table sounds a lot like what Jonathan was trying to achieve but within the product catalogue.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Tele AS

Original Message:
Sent: Jan 27, 2025 07:21
From: MMH HH
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi Jonathan,

If there is any further work/progress on this, could you please let the community know. I believe, this is an excellent approach to how things are modelled right now. Would be great to know if there're better ways of handling this.

------------------------------
MMH HH
Vodafone UK Ltd

Original Message:
Sent: May 15, 2024 06:22
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi Mahesh

I'm going beyond what your table shows, since in my view also the contract term can be regarded as a pricing parameter, even though it's a property of ProductTerm and not formally a characteristic. Similarly for channel, which is a reference from ProductOrder and not a characteristic. So the entire table could be attached to a single POP. if that's the way you want to implement things. And for acquisition vs retention.

Of course maintenance is needed to add new combinations to the table, but no more than would be needed with the current approach, adding an entire POP for a new combination.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 15, 2024 04:16
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

My table doesn't show it clearly. POP1 is for the 'acquisition' combinations & POP2 is for 'retention' combinations. But is it even needed ? can we just maintain one POP for all combinations ?

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 04:14
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks for your inputs Jonathan and Matthieu.

Yes, its clearly evident that having a separate product offering & prices for each combination of characteristic values. I am sorry, i shouldn't be asking more details of the new proposal you are working on Jonathan, but can i ask if my approach is correct considering the below scenario.

Every POP has process type, term contract, channel as mandatory/ optional based on the system requirement . And it can have additional ProdSpecCharValueUse (0..*) combinations that define pricing (in a nutshell i guess this is what matthieu has suggested above). I have to pass all this info to CPQ and CPQ decides the final price based on the UI selection. There is no constraint / policy that runs to come up with the pricing with the above approach.

 This approach is scalable, but wouldn't it cause maintenance overhead in case if a new characteristic / characteristic value is introduced in the above matrix of combinations.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd

Original Message:
Sent: May 15, 2024 03:49
From: Jonathan Goldberg
Subject: TMF 620 Product Modelling for Additional Chargable Items

Thanks Matthieu

Your proposed approach is what is currently supported by the price model in TMF620. But at least in our experience it is very unwieldy to have a separate POP for each combination. And this is the motivation behind and the source of my ongoing proposal to model parameterized pricing as a price table dependent on characteristic values. So a single POP with a table will model the price amount.

------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.

Original Message:
Sent: May 14, 2024 06:34
From: Matthieu Hattab
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

There are many ways to model your requirements, but choosing the right one depends on many things, from market strategy, CX, type of customers or users, BSS and OSS capabilties...

I suggest you read this trail: Product Modelling PlayBook

It's important you have, at least, an awareness of the TMF PSR (Product-Service-Ressource) modelling technique.

I also posted on various occasions, in this community, a comprehensive list of TMF assets dedicated to product catalogue. You should be able to find them easily.

I didn't quite understand your approach 1 but we currently use approach 2 to model bandwidth price.

TMF620 supports it.

search for "prodSpecCharValueUse" or "ProductSpecificationCharacteristicValueUse" in both the API documentation and in this community.
When searching the community, also search for "PSCVU" to see examples.

That our payload for characteristic-value-based pricing, using the prodSpecCharValueUse technique.

each price is first associated to the PO (not shown here) and then some prices are also associated to a specific charValue and such prices are only intanciated if the related charValue is selected:

{    "id": "POP0001",    "priceType": "recurring",    "price": {        "unit": "NOK",        "value": 779    },    "prodSpecCharValueUse": [        {            "name": "Bandwidth",            "id": "PSC0010",            "@type": "ProductSpecificationCharacteristicValueUse",            "productSpecCharacteristicValue": [                {                    "value": "100_100",                    "displayName": "100/100 Mbit/s",                    "@type": "CharacteristicValueSpecification"                }            ]        }    ],    "productSpecification": {        "id": "FIBPS0002",        "name": "Fiber Broadband ProdSpec",        "@type": "ProductSpecificationRef"    }}

you don't worry about that. 

This is covered by a "modify order" and all decent BSS must support "Asset-Based Ordering", i.e. taking an active product from the product inventory, make changes to it and submit a "modify order" to apply the changes in billing, provisioning etc.

------------------------------
Kind regards,

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 01, 2024 22:40
From: Mahesh Kothamasu
Subject: TMF 620 Product Modelling for Additional Chargable Items

Hi,

I have this below scenario and need suggestions on what would be the best modelling approach from you experts.

Say, our company is selling Broadband Internet. I configure this as below.

Broadband Internet (Simple Product Offering)

      |_____ B/w (Characteristic) -> 100Mbps, 200Mbps ... (Characteristic Values)

      |_____ IPs (Characteristic) -> 8 (default), 16, 24 ... (characteristic Values)

      |_____ Broadband Monthly Fee (RC), Broadband Install Fee (OTC)

Now, once customer is purchasing the above offering, if they choose 16 IPs instead of default 8 IPs, i want to show additional charge in the bill like Additional IPs charge - $100. So, in order to achieve this, are below approaches correct ? if not, can suggest the best approach.

Approach 1: Create Additional IPs as another product offering and show it as recommendation during configuration. With this, customer can choose this upsell item and configure the required ips and to this product offering, OTC and RC pricing will be attached. This will be treated as a order item. But i want this product offering to be just a billable offering, the actual provisioning should happen on the parent Broadband Internet offering, which means, during ordering, what ever is the additional IPs chosen will be overwritten on the Broadband Internet parent order item, and this child order item will be automatically completed as soon as the parent order item is completed. The child shouldn't be sent to OSS systems for provisioning activities. Is this a valid approach ?

Approach 2: Instead of creating a separate product offering like in approach 1, just create an additional charge item which will be additionally added when customer chooses any IPs other than the default 8. This way there is no need to maintain any separate offerings and COM to SOM is much more convenient. But the downside is, if on day 2 customer want to terminate this additional ips and go back to default 8 ips, i don't know how straight forward is the approach.

Thank you for taking your time to reading it.

------------------------------
Mahesh Kothamasu
SP Telecommunications Pte Ltd
------------------------------