paint-brush
B2B Software Pricing - Understanding the Driversby@amiya12
399 reads
399 reads

B2B Software Pricing - Understanding the Drivers

by ArtSeptember 19th, 2022
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

Overall pricing for telco B2B software is primarily driven by ***Customer Segment*** (mobile/ISP/fixed line/DSP) and ***Customer Profile*** (Size, Region, Average Sales Price, Sales Cycle, Greenfield, Swap, Modernization). We consider our product pricing to be composed of 3 elements: Software, Services, and Hardware/Infra (3PP HW and SW) In this document, we will examine the drivers which affect the pricing of each of these elements.

Company Mentioned

Mention Thumbnail
featured image - B2B Software Pricing - Understanding the Drivers
Art HackerNoon profile picture


In this article, we will examine the B2B software pricing for telecom customers however many of these concepts could be applicable to other verticals as well. Overall pricing for telco B2B software is primarily driven by Customer Segment (mobile/ISP/fixed line/DSP) and Customer Profile(Size, Region, Average Sales Price, Sales Cycle, Greenfield, Swap, Modernization). We consider our product pricing to be typically composed of 3 elements: Software, Services, and Hardware/Infra (3PP HW and SW). In this document, we will examine the drivers which affect the pricing of each of these elements.

1. Software - software pricing

Software pricing is derived from items sold.(what is sold, how many are sold). Software Pricing is usually shown under 3 headings: Base Platform, Licenses, and Customization. Below, we will examine drivers which affect the pricing of each of these elements.

1.1 Base Platform

Identify if the solution caters to mobile service only or ISP or Fixed line or a customer offering all the services (mobile/internet/fixed line/IPTV). Consider that budget (and Value Propositions) for different Customer Segments (and Customer Profiles) may vary hence we may need to adjust Base Platform Pricing accordingly. Also, consider that Base Platform pricing is independent of subscriber count and as such will consider the primary service which is being offered in case of customers offering multiple services (triple-play or quad-play customers). (Refer for Base Platform pricing).

1.2 License (OOTB)

In this instance, we are considering that software licensing for all modules in our solution is calculated basis of subscriber count. Hence, we should try and arrive at a total subscriber count for licensing our software. In the case of a mix of subscriber types, we can select one type as the main type ( Postpaid). All other types( prepaid) can be converted to the main type using a conversion ratio (1:1,2:1,3:1). ( Refer for License pricing).

1.2.1 Subscriber Base (Mix)

  • Main Type ( Postpaid)
  • Conversion to main type ( prepaid to postpaid conversion): Take a 3:1 conversion ratio for prepaid to post-paid conversion.

1.2.2 Modules

D*esign per subscriber price for each module. *Extremely important to identify if correct modules are being provided for our solution.

1.3 Customization

One important driver for customization is project scope.

1.3.1 Feature Customization

  • Per Module Additional Effort (as per scope) - design per module customization price. For each module, there will be customization efforts to deliver the solution for a particular customer. (Refer for Customization pricing)
  • Custom Feature/Change Request Development (out-of-scope items)
    • Role-Based Man-Day rates - design rates for different skill sets. Each **role such as PM, Developer, QA, etc.. may have different rates.
    • Blended Man-Day rates - design single rate.
  • Support for additional Technology/Networks (5G/Tetra etc.. can be in-scope additional networks or out-of-scope) - design price for each new technology integration. In case the customer decides to deploy say 5G, our existing solution will undergo changes to support new technology. (Refer for Customization pricing)

1.3.2 Deployment (copies)

  • Primary Site - (included).
  • Additional Sites - design price for each additional site irrespective of ACTIVE or PASSIVE.

2. Services - services pricing

Services pricing is derived from manpower deployment(where, how many, and for how long). Services pricing is usually shown under 4 headings: Implementation, Warranty, AMC, and MS/Operations.

2.1 Implementation

Implementation price refers to our costs for deploying our solution end-to-end. Hence key drivers here will be - resource count, the number of days resources are engaged for the project ( project plan duration), and the location of the project.

2.1.1 Location - (where)

Geographical location is a key driver for services. Costs of living may vary between countries. Can design a tier-based system for classifying the majority of the countries and only lower tiers can be taken up the case by case for discussion.

  • On-Site
    • Standard - Lower services pricing.
    • Others - Higher services pricing. Countries that have higher costs of living and other expenses.
  • Remote - will typically have lower services pricing unless special restrictions for remote operations are to be complied with.

2.1.2 Resource Count - (how many)

what type of resources can also be considered?

2.1.3 Project Duration - (for how long)

2.2 Warranty

Warranty can be offered as free or paid. Duration can vary from zero months to one year, 2 years or 3 years. Longer warranty periods such as 2 years and 3 years are almost always paid in nature. Also, we can have a standard practice of no warranty and AMC can begin from go-live.

2.3 AMC - (Annual Maintenance Charges)

  • SLA - (Service Level Agreements)
    • Standard - lower AMC percentage. Please note we can have one standard SLA for its customers.
    • Complex - higher AMC percentage. This is due to an increase in resource count to support special SLAs.
  • Upgrade
    • w/o upgrade - higher AMC percentage. can charge services for upgrades.
    • with an upgrade - lower AMC percentage but upgrade after 2 years for a fixed percentage of license fees. Can charge services for upgrades.

2.4 MS/Operations

Not covered here.

3. Hardware/Infra

Our standard practice here can be to design standard BOQ ( Bill of Quantities) for pre-defined subscriber bases( customer profiles).

3.1 Physical hardware

Design subscriber base slabs and standard hardware profiles for each slab.

3.2 VM-based BoQ

Design subscriber base slabs and standard VM profiles for each slab.

3.3 Micro-services-based BoQ

Below is a simple template for optimizing micro-service BoQ based on the various drivers.