Thanks to all who contributed here to an excellent discussion. One small but important point regarding the effect of these commercial changes on the underlying provisioned services and resources.
As far as possible, you would want to leave these unchanged except for the specific areas where the offering change mandates this (e.g. increasing bandwidth, terminating a product that was in the old offering but not in the new, etc.). The end customer will not be happy if (for instance) his voice mailbox is reset as a result of the offering change.
So in the construction of the Product Order, and then the resulting Service Order, try to keep the action as
unchanged wherever possible, or
modify where necessary (but not
remove and then
add).
------------------------------
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: Oct 19, 2021 03:43
From: Santiago Lorente
Subject: Consequences of changing offer
Hi Liam,
I agree with my colleagues and specially with this comments
- "the API just allows you to GET product offerings - the onus is on your consumer implementation"
- "Change/replace offering is not a simple flow"
Then, a call to an API triggers an implementation of that interface. The logic behind the implementation provides the required outcomes.
In our case, the CSR/AE can directly determine the consequences of moving from one product to another directly in the CPQ. After a change order is created for a specific asset (name we use for installed product/service) the CPQ components shows the promotions associated with the asset. Then, CSR can access the details easily and see the consequences. However, in case the agent will proceed a message will be shown with any penalty that could be applied if it was previously configured/associated to the promotion for that asset.
An example is people getting an expensive price plan(100 Eur/month) through a promotion (50% off) for obtaining an expensive terminal like iphone 13. Then, they move to a less expensive plan (39 Eur/month) keeping the terminal.
Cheers.
------------------------------
Santiago Lorente
Salesforce
Original Message:
Sent: Oct 18, 2021 11:20
From: Matthieu Hattab
Subject: Consequences of changing offer
Hi,
this is a solution done in the past (without TMF apis) and I added TMF apis:
customer has offer A and want to change it to offer B.
very high level steps (other have already talked about service qualification eligibility etc)
- implement a component that will create a delta configuration. This component will:
- load product A (Product A = instantiation of product offering A) with TMF637
- load product offering B with TMF620
- instantiate offer B with a configurator API (that doesn't exist in TMF yet) in the CPQ component
- analyse differences between A and B
- etc
the delta could present:
- add-ons that won't change (they exist in both A and B)
- removed add-ons from A that don't exist in B
- added add-ons that don't exist in A but are mandatory in B ( because of a cardinality, product configuration rule)
- Update characteristics values from A that are different in B (because of configuration rules etc)
- early termination fees, penalty, whatever business rules you have in this domain
- charge differences (that really depends how pricing is modelled, a discount could be a separate product, or a system price override coming from a price policy)
Then you present all of it to the UI in a very understandable way, and ask customers to accept it.
if customers accept it, put everything in a shopping cart (TMF663) and present offer B to the customer so they can further customize offer B (add more optional add-ons, choose mandatory add-on that could not be salvaged from Offer A)
when customer is finally happy with the shopping cart, the order can be created with TMF622.
------------------------------
Matthieu Hattab
Altibox AS
Original Message:
Sent: Sep 29, 2021 01:54
From: Liam Salomonsson
Subject: Consequences of changing offer
Hi all,
I am trying to figure out what API to use and how to use it to determine what consequences moving from one product to another may have so it can be presented to the end user before they decide to make the change.
Here is a scenario so you can better understand:
Customer has got service x with us today and because of x they also have a promotion giving them another value added service for free. The customer wants to downgrade and move to service y but that would mean they are no longer eligible for the promotion they currently have and the value added service would be cancelled. I want to show the customer in the ordering flow that the value added service will be removed if they go ahead with the change.
What API should be used for this type of thing where i want to understand the cause and effect of moving from one service to another?
------------------------------
Liam Salomonsson
Telenor Sverige
------------------------------