Open APIs

Expand all | Collapse all

Consequences of changing offer

  • 1.  Consequences of changing offer

    TM Forum Member
    Posted 22 days ago

    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

  • 2.  RE: Consequences of changing offer

    TM Forum Member
    Posted 22 days ago
    Hi Liam
    The product catalog API TMF620 could show at a catalog level what are the consequences for changing/replacing an offer. But the API just allows you to GET product offerings - the onus is on your consumer implementation to actually analyze the different offering structures and work out the impact. Similarly for the Promotion API TMF671 - you get the catalog but you have to analyze that.
    Change/replace offering is not a simple flow - in our Amdocs ordering software we have invested a lot of effort in analyzing the various use cases and side-effects. I'm sure that other vendors in the same space will tell a similar story.
    Hope it helps

    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.

  • 3.  RE: Consequences of changing offer

    TM Forum Member
    Posted 22 days ago

    Hi Liam,

    As a reference to how we do it;

    • We use product offer qualification for eligibility of the change (e.g. what can I change to, from my current inventory)
    • Promotion to qualify the promotions that might apply (e.g. which promotions qualify after).
    • Recommendation to guide the customer or agent additionally (e.g. let's say your current subscription had a streaming service included in the (bundled) offer, the offer you change (downgrade) to will no longer have it included, so you might want to take a paid addon to keep the streaming).
    • We track the entire transaction on shopping-cart to do price calculations on top of that and show the deltas after the user done changing offers relative to inventory. We also extended cart to handle e.g. penalties in case items in inventory are under contract of which term hasn't passed.

    Hope it helps. Didn't really find a more elaborate E2E sequence in TMF documentation. So just an example on how we did this. Required some extensions to the schemas left and right to keep the FE or BFF devoid of any business logic.

    We use the same for all flavors of change. Move, upgrade, downgrade, add addons etc.


    Pieter Pabst
    Tech Mahindra Limited

  • 4.  RE: Consequences of changing offer

    TM Forum Member
    Posted 21 days ago
    Hi Liam,

    I consider the process you want to do as Package Change Order (PCO).
    Your ultimate goal should be to create a Product Order. You can use the TMF622-Product Ordering API here.

    You can add the new products (activation set) and old products (deactivation set) together to the ProductOrderItem list while creating an order.
    You have to give correct OrderItemActionType. You should use 'delete' or 'modify' action type for old products and 'add' action type for new ones.
    The customer sees which services/products are terminated or created with the OrderItemActionType.

    Steps to do:
    1. The old bundle (or product) to be changed will be selected. (If there is only one active bundle, it can be selected automatically)
    2. Eligible offers are listed, taking into account the selected old bundle (or offers). (You have to set your own rules here. TMF679 can help)
    3. You can define another value added service provided as a product without price. With this free product you can follow lifecycle of service. Customer will see this service in terminated product set during the Product Order (logically PCO).
    4. It is the same as in ProductOrder whether a promotion will be applied for the new package that comes with PCO. (You can add additional rules)
    5. The old promotion and services acquired through the old promotion will probably end with the terminated products.
    6. In downgrade/upgrade operations, commitment and penalty calculations should be taken into account.
    Hope it helps

    Mustafa Yusufoglu
    i2i Systems

  • 5.  RE: Consequences of changing offer

    TM Forum Member
    Posted 3 days ago
    Edited by Matthieu Hattab 3 days ago

    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

  • 6.  RE: Consequences of changing offer

    TM Forum Member
    Posted 3 days ago
    Hi Liam,
        I agree with my colleagues and specially with this comments
    1. "the API just allows you to GET product offerings - the onus is on your consumer implementation"
    2. "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.


    Santiago Lorente