Skip Headers
Oracle® Communications Billing and Revenue Management Setting Up Pricing and Rating
Release 7.5

E16711-09
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

1 About Creating a Price List

This chapter presents an overview of how you can create an Oracle Communications Billing and Revenue Management (BRM) price list to specify how to charge for your services.

Before reading this chapter, you should have a basic understanding of BRM concepts. See BRM Concepts.

About Price Lists

You create a price list to define how much to charge for your services. A price list consists of several components:

Plans

You use plans to offer your services to customers. For example, if your company provides Internet access and email, your plans might include:

  • A plan that offers wireless telephony.

  • A plan that offers only Internet access.

  • A plan that offers Internet access and email.

During account creation, your customers are presented with a list of plans (for example, ”Unlimited Internet Access” or ”500 free wireless minutes with unlimited roaming”).

Deals

A plan consists of one or more deals. You use deals to define different ways to charge for services. For example, you can offer two different deals for Internet access:

  • A deal that includes a setup fee.

  • A deal that has no setup fee.

Each deal is typically associated with a specific service. For example:

  • A plan that offers only Internet access includes only Internet access deals.

  • A plan that offers Internet access and email includes two deals, one for Internet access and one for email.

In addition, you can purchase more than one instance of the same deal and have it applied to a single account or service.

Products

A deal consists of one or more products. You use products to package and organize the rates that define how much to charge for your services.

Your products might include:

  • A setup fee.

  • A monthly subscription fee.

  • Usage fees for telephone calls.

    Usage fees can be rated in real time or in a batch rating pipeline.

  • An offer profile

    An offer profile is associated with a product or discount.

Offer Profiles

You use offer profiles in association with products and discounts to provide policy-driven provisioning of services. Each offer profile consists of the following data:

  • A unique name

  • An array of policy labels, with each policy label composed of rate tiers

Figure 1-1 shows how a simple price list is organized. In this example:

  • The Internet access plan includes the Basic Internet access deal.

  • The Email plan includes the Email deal.

  • The Internet access and email plan includes the Enhanced Internet access deal and the Email deal.

Figure 1-1 Simple Price List

Description of Figure 1-1 follows
Description of "Figure 1-1 Simple Price List"

In this figure, notice that you specify how much to charge for your services at the lowest level, in the rates that are included in products. Therefore, when you specify how much to charge for your services, you start by creating products and rates.

What Is Rating?

Rating is the process of measuring customer activity, determining how much to charge for it, and adding the charge to the customer's account balance.

For example, if Internet access is rated at $1 per hour:

  1. A customer has a 2-hour dialup session.

  2. BRM rates the session at $1 per hour.

  3. The customer's account balance increases by $2.

In a typical business, thousands of customers log in daily, generating millions of interactions that must be managed and charged for. BRM manages those interactions by creating and storing billable events.

About Billable Events

An event is a record in the BRM database of a customer or administrative action. For example:

  • When a customer logs in to a dialup session, BRM creates a session event, which stores data about the session, such as the start time and end time.

  • When a customer service representative (CSR) changes a customer's password, BRM creates an activity event, which stores information such as the identification of the CSR who made the password change.

When you set up your price list, you define which events you want to charge for. These events are called billable events. To determine how much to charge a customer for a billable event, BRM rates the event.

How BRM Rates a Billable Event

You can rate billable events in two ways:

  • Real-time rating monitors and rates service usage as it happens, such as Internet access. Real-time rating is performed by rating opcodes.

  • Batch rating rates events that have been recorded in files, such as telephony call detail records (CDRs). Batch rating is performed by Pipeline Manager or by Universal Event (UE) Loader. Most telco services use Pipeline Manager for batch rating.

About Real-Time Rating

Real-time rating is used for services such as dialup access and email. For example, to rate Internet access in real time:

  1. BRM determines the length of the session by comparing the start time and end time.

  2. BRM applies a charge to the amount of time. For example, if you specify to charge $1 per hour for Internet access, a 10-hour session costs $10. This charge is called the balance impact.

  3. BRM adds the total charge for the event to the customer's account balance.

Figure 1-2 shows how a billable event is captured, rated, and recorded in the BRM database:

Figure 1-2 Track Balances Tab

Description of Figure 1-2 follows
Description of "Figure 1-2 Track Balances Tab"

About Pipeline Batch Rating

Pipeline batch rating is typically used for rating telephony services, where large amounts of events are recorded in files. For example, to rate telephone calls:

  1. Pipeline Manager reads the data from CDRs to determine the time and duration of the calls.

  2. BRM applies a charge to the amount of time. For example, if you specify to charge 10 cents per minute, a 10-minute call costs $1. This charge is called the balance impact.

  3. BRM adds the total charge for the event to the customer's account balance.

    Note:

    You can also use UE Loader to load data from event log files as billable events and rate them using real-time rating. The event log files can include data from Web servers or other services that record events in files. When the events are loaded, BRM rates the events and updates the customers' account balances. For more information, see "About Rating Events Created by External Sources".

For more information, see "About pipeline rating" in BRM Configuring Pipeline Rating and Discounting.

About Different Types of Rates

Before you set up your price list, you must determine which types of rates to use:

  • Usage rates rate service usage, such as telephone calls or Internet dialup sessions.

  • Cycle rates rate recurring fees that are not generated by usage (for example, a monthly subscription fee). See "About Cycle Rates".

  • Purchase rates charge for nonrecurring fees, such as setup fees. Purchase events are created when a customer purchases a product.

  • For account and product cancellations, use cancel events. Cancel events occur only when a product is canceled. Cancel events are not affected by how much a customer uses a service.

    When you close an account, all the products in the account are canceled. Therefore, cancel events are generated for all the canceled products. You do not need to cancel the products first to generate cancel events.

    Important:

    You use pipeline rating only for rating usage events. You can use real-time rating to rate all types of events.

About External and Internal Events

An external billable event is a usage event created by the customer outside of the BRM system (for example, when a customer makes a telephone call).

An internal billable event is an event that is not generated by the customer, but is instead generated by the BRM system. For example, on the customer's billing day, BRM creates a monthly fee event. This event is rated by a cycle rate.

Different rates are used to rate external and internal events.

Figure 1-3 shows how BRM rates external and internal events. The external event was triggered by a dialup session. The internal event was triggered by running a billing utility.

Figure 1-3 External and Internal Event Rating Flow

Description of Figure 1-3 follows
Description of "Figure 1-3 External and Internal Event Rating Flow"

About Cycle Rates

To charge subscription fees, such as monthly payments for having an account, you create rates for cycle events.

There are three types of cycle events: cycle forward, cycle arrears, and cycle forward arrears.

About Cycle Forward Events

Cycle forward events charge a fee for future service. For example, when a customer pays the monthly cycle forward fee for a cell phone service, the customer pays for the coming month. With a yearly cycle forward fee, the customer pays for the entire year in advance.

Cycle forward events typically occur at the end of a billing cycle to charge the customer for the upcoming billing cycle, but you can define your own flexible cycles.

There are five cycle forward event types to support: monthly, bimonthly, quarterly, semiannual, and annual fees. Multi-month cycle forward events can occur on any date; they do not have to be synchronized to the start or end of a month.

Note:

You can also configure support for cycles of any length (for example, weekly or every five months).

About Cycle Arrears Events

Cycle arrears events occur at the end of the month to charge the customer for the past month. When a customer pays a cycle arrears fee, the customer pays for the month that has already occurred.

Note:

There are no multi-month cycle arrears fees.

In Figure 1-4, the customer owns two plans, each with a cycle fee. The bill created on April 1 includes:

  • A $10 cycle arrears fee for March

  • A $10 cycle forward fee for April

Figure 1-4 Cycle Arrears and Cycle Forward Fees

Description of Figure 1-4 follows
Description of "Figure 1-4 Cycle Arrears and Cycle Forward Fees"

About Cycle Forward Arrears Events

Cycle forward arrears events occur at the beginning of the month to charge customers for the upcoming month, but the cycle fees are not billed until the end of the month when billing is run. When a customer pays a cycle forward arrears fee, the customer pays for the month that has just passed.

Note:

There are no multi-month cycle arrears fees.

BRM adds cycle forward arrears fees to account balances as unbilled revenue at the beginning of the cycle. This enables you to recognize unbilled cycle arrears fees when you run G/L reports before the cycle ends. For more information, see "About collecting general ledger data" in BRM Collecting General Ledger Data.

Cycle forward arrears fees are stored in cycle forward arrears items. The cycle forward arrears event is assigned to the item that belongs to the next accounting cycle. This way, the fee is tracked in the account balance for the current cycle, but it is not billed until the end of the cycle as shown in Figure 1-5:

Figure 1-5 Cycle Forward Arrears Fee

Description of Figure 1-5 follows
Description of "Figure 1-5 Cycle Forward Arrears Fee"

About using delayed billing

Because cycle forward arrears fees are assigned to the item that belongs to the next cycle, you must use delayed billing even if you do not need a delayed billing period.

When you use delayed billing, BRM tracks events in the current cycle that will be billed in the next accounting cycle. When the bill item for the next accounting cycle is created, BRM then assigns the tracked events to that bill item.

If you do not need a delayed billing period, you can set the value of the delayed period to 0.

For information about configuring delayed billing, see "Setting Up Delayed Billing" in BRM Configuring and Running Billing.

How BRM Creates Cycle Events

Cycle events are internal events created when you run the pin_bill_accts billing utility. For example, if the pin_bill_accts utility finds that an account's billing date is due, and the customer has signed up for a plan that includes a monthly cycle forward fee, BRM creates a Monthly Cycle Forward Event.

For information about accounting cycles, see "About accounting and billing cycles" in BRM Configuring and Running Billing.

Benefits of Using the Cycle Event Types

The advantage of using a cycle arrears event is that all of the usage and cycle fees for a particular month are included in the same bill.

The advantage of using a cycle forward event is that you collect payments sooner. Most implementations use cycle forward events.

The advantage of using a cycle forward arrears event is that all of the usage and cycle fees for a particular month are included in the same bill, and the cycle fee is recorded in the G/L when a G/L report is run before the fee is billed.

Allowing Cycle Fees to Be Prorated

Cycle events are not related to how much a customer uses a service. However, you can enable cycle charges to be prorated. Proration occurs in cycle fees in the following cases:

  • When a customer registers for an account and the account billing day is not the same day that the account was created. In this case, the customer is billed for the partial month that falls between registration and the first billing date as shown in Figure 1-6.

Figure 1-6 Prorating Cycle Fees

Description of Figure 1-6 follows
Description of "Figure 1-6 Prorating Cycle Fees"

In this example, a prorated cycle forward fee is charged on May 1, when the account is created to pay for account ownership from May 1 through May 15.

  • When a customer changes the billing date and a partial month is created as a result.

  • When a customer cancels a product before the end of the billing cycle.

You can specify if a cycle fee should be prorated, if the complete fee should be applied, or if no fee should be applied.

When you specify that a fee can be prorated, you specify which resources can be prorated. For example, you can prorate currency, but not free Internet access hours.

For details on proration, see "Calculating prorated cycle fees" in BRM Configuring and Running Billing.

Applying Multiple Rates to the Same Event

You can apply multiple rates to the same event by creating multiple rates within a rate plan. For example:

Ways to Rate Events

When you create your price list, you can use many different ways to define rates (for example, which data you measure, how to measure the data (duration or occurrence), and time of day).

About Ratable Usage Metrics

You can rate an event based on any data captured in the event. For example, you can measure and rate how long a session is or measure and rate the number of bytes downloaded. The event data that you use to rate an event is called the ratable usage metric, or RUM. Common RUMs are:

  • Duration. You rate based on how long a usage event was.

  • Occurrence. You rate based on how many events occurred, independent of their duration.

You set up RUMs for pipeline batch rating and real-time rating. For information, see the following:

About Applying Multiple RUMs to Rate an Event

By default, BRM rates an event by using a single RUM that is specified in the product's usage map. You can also set up your products to rate an event based on multiple RUMs.

For example, you can set up a product to rate fax events based on the following RUMs:

  • The number of bytes transmitted

  • The number of pages transmitted

  • The duration of the fax session

For more information, see "Real-Time Rating Based on Multiple RUMs".

About Rating Based on Date and Time

You can use different rates depending on the date and time that the event occurred. For example, you can apply one rate on weekdays and another rate on weekends.

Figure 1-7 shows how the same event can be rated differently based on when it occurred:

Figure 1-7 Rating Based on Date and Time

Description of Figure 1-7 follows
Description of "Figure 1-7 Rating Based on Date and Time"

You can use pipeline batch rating and real-time rating to rate events based on date and time. For information, see the following:

About Resources

When you create rates, you can specify different resources to use for the balance impact. A resource is an asset of economic value, such as US dollars and free Internet access hours.

  • You must create currency resources for the system currency and the account currency that you support. For example, if you have Canadian customers, you must create the Canadian dollar resource.

  • You must create non-currency resources if your rates include non-currency balance impacts such as free minutes or Internet access hours. For example, when you provide free Internet hours, you need a resource to create balance impacts for the access hours.

You set up resources for pipeline batch rating and real-time rating. For information, see the following:

About Rounding Resources

You round resources for various reasons (for example, to increase the accuracy of rating and discounting, display rounded amounts on bills, and show the correct decimal value for different types of currencies such as dollars and yen).

BRM enables you to round resources based on the type of resource or currency, the type of event such as purchase, usage, and discount events, and the process that performs the rounding such as rating, discounting, and billing. These options enable you to set up rounding in specific ways. For example, you can round up to a precision of six decimal places for rating usage events, round down for discounting those usage events, and round to the nearest two decimal places when billing the usage.

You set up rounding rules for pipeline batch rating and real-time rating. For information, see "About Resource Rounding".

About Setting Rules for Resource Consumption

You can specify the order in which resource sub-balances are consumed. For example, if a customer has several groups of free minutes that expire at different times, you use consumption rules to indicate which minutes to use first, based on the validity period start time and end time.

You set up consumption rules for pipeline batch rating and real-time rating. For information, see "Specifying the Order in Which Resource Sub-Balances Are Consumed".

About Rating Based on Event Attributes

With attribute-based rating, you can specify different event attributes to consider for rating. For example:

  • Telephony events include two event attributes that record the call origin and destination. If you offer a telephony service, you can rate call events according to call origin and destination.

  • Telephony events also include an event attribute that records the type of call (for example, a call made with a calling card). You can use this attribute to rate calls made with a calling card differently from other calls.

You can use pipeline batch rating and real-time rating to rate events based on event attributes. For information, see the following:

About Rating Based on Event or Resource Quantity

You can rate events based on the quantity that has already been rated. For example:

  • 10 cents per minute for the first 30 minutes of usage.

  • 6 cents per minute for the next 60 minutes of usage.

  • 4 cents per minute for usage over 90 minutes.

You can use pipeline batch rating and real-time rating to rate events based on event or resource quantity. For information, see the following:

About Products

When you create your price list, you organize rates into products. A product is the basic unit of your price list. Each product defines a set of events, usually associated with a service, and the balance impacts that are applied when those events occur.

Specifying Rates in Products

When you create a product, you specify basic information about the product, such as the name and description. You also specify the following rating information:

  • The events to rate (for example, monthly cycle forward or IP Dialup events). You can rate more than one type of event in a product.

    Note:

    A single product cannot include multiple cycle events that have the same frequency and type of balance impact, such as a cycle fee. For example, if you add a monthly cycle forward event to a product, you cannot also add a monthly cycle arrears or monthly cycle forward arrears event to the same product. Instead, Oracle recommends that you create separate products for each cycle forward event.
  • The service that the product applies to. For example, to create a product for rating an IP Dialup service, you use /service/ip.

  • For each event, the ratable usage metric (RUM). For example:

    • For cycle forward events, rate by occurrence.

    • For dialup events, rate by duration.

  • For each event, the resource used for the balance impact. For example:

    • To charge money, the resource might be US Dollars.

    • To give free hours, the resource might be Dialup hours.

  • The balance impact of each event (for example, $1 per hour).

For example, a product for rating an IP Dialup service might include the rating information shown in Table 1-1:

Table 1-1 Rating Information for Dialup Service

Event: Monthly Cycle Forward Event Event: IP Dialup Event
  • RUM: Occurrence

  • Resource: US Dollars

  • Balance impact: $20 per occurrence

  • RUM: Duration

  • Resource: US Dollars

  • Balance impact: $1 per hour


In addition to the rating information shown in this example, you can supply additional information, such as how to calculate taxes, the dates and times that a rate is valid, how to rate based on quantity, and if a rate is discountable.

You can create products in many different ways to accommodate many pricing scenarios.

Using products to rate different services

When you offer multiple services, you typically create products for each service. Table 1-2 shows an example:

Table 1-2 Products and Services

IP Access Product Email Product Fax Product

$10 purchase fee

No purchase fee

$10 purchase fee

$10 monthly charge

$5 monthly charge

$5 monthly charge

$1 per hour usage fee

$5 per month for an extra mailbox

No usage fee


You can create products for different services in a single plan, but a product cannot be used to rate more than one service.

Using products to charge different amounts for the same service

You can use products to charge for the same service in different ways. You can do this by rating combinations of internal and external events. Table 1-3 shows an example:

Table 1-3 Rating Combinations

Standard Product Low Usage Product Unlimited Usage Product

$20 purchase fee

$10 purchase fee

$20 purchase fee

$10 monthly charge

$5 monthly charge

$20 monthly charge

$1 per hour usage fee

$2 per hour usage fee

No usage fee


Associating products with Offer Profiles

To provide policy-driven provisioning of services, you associate products with offer profiles. For example, if you create an offer profile called Data Pro Unlimited, you use that name as the provisioning tag for your product. The resource tracking is made possible when you configure the resource id for the resource named in the offer profile (for example, 100009 for Megabytes Used) as the resource counter in the product.

Associating products with accounts

You can create products that associate rates with accounts. For example, you can create a product that includes monthly charges for an account independent of the services that a customer owns as shown in Table 1-4:

Table 1-4 Associating Products and Accounts

Account Product IP Access Product Email Product

No purchase fee

$10 purchase fee

$10 purchase fee

$10 monthly charge

No monthly charge

No monthly charge

$5 cancel fee

$1 per hour usage fee

No usage fee


Using products to handle complex rating

You can rate a single event in different ways in the same product. Table 1-5 shows an example:

Table 1-5 Complex Rating with Products

Simple Product Complex Product

$10 purchase fee

Purchase fees:

  • $10 purchase fee if purchased after December 2007

  • $5 purchase fee if purchased after October 2007

  • No purchase fee if purchased before or during October 2007

$1 per hour usage fee

Usage fees:

  • $1 per hour on weekends

  • $2 per hour on weekdays

  • First 20 weekend hours free

  • First 10 weekday hours free


Specifying Minimum Event Quantities for Rate Plans

You can specify a minimum event quantity to rate. For example, suppose the minimum quantity for the IP access rate is 120 seconds (2 minutes). IP access events of less than 120 seconds are rated as if they were 120 seconds long.

Specifying How to Round Event Quantities

You can specify how to round fractional event quantities. For example, if you round Internet access to the nearest second, and a customer connects to the Internet for 2 minutes and 39.76 seconds, the event is rated at 2 minutes and 40 seconds. Event quantities are always rounded up.

You can take advantage of event quantity rounding to charge for consistent blocks of time (for example, 5 cents for each 10 seconds of an IP telephony call).

Note:

Event quantity rounding is different from resource rounding. With resource rounding, you round the amount to charge. With event quantity rounding, you round the amount of usage. See "Setting Up Resources for Real-Time Rating".

About Organizing Rates in a Product

You organize rates in a product in a hierarchical structure as shown in Figure 1-8:

Figure 1-8 Organizing Rates in a Product

Description of Figure 1-8 follows
Description of "Figure 1-8 Organizing Rates in a Product"

This structure enables you to create multiple components at each level; for example, you can rate multiple events in a single product and create multiple rates for each event.

About the Event Map

The event map specifies the events that are being rated in the product. For example:

  • Monthly Cycle Forward Event

  • IP Dialup Event

See "Mapping Event Types to Services".

About Rate Plans

You use rate plans to define how much to charge for an event. There are two separate but related kinds of rate plans. In the simplest terms, real-time rate plans are used for real-time rating and pipeline rate plans are used for batch rating.

Important:

If you use Pipeline Manager to rate events, you must use the same rate plan names in your price list and in the pipeline pricing configuration.

About Product Ownership

During account creation, the customer chooses a plan. A plan is a package of deals, each of which in turn is a package of products. Therefore, what the customer actually owns is not a plan, but a set of products.

If you create different products for the same service, different customers might use the same service, but pay different charges, based on the products that they own.

For example, you might have two customer accounts that use the same service, but have different products as shown in Table 1-6:

Table 1-6 Products and Accounts

Account 1 Account 2

IP product 1:

  • Service: IP Dialup

  • Cycle forward event: $20

  • Usage events: $2

IP product 2:

  • Service: IP Dialup

  • Cycle forward event: $10

  • Usage events: $1


When BRM rates events for these customers, the charges for Account 1 are different from the charges for Account 2, even though the services and the events being rated are the same type.

Note:

When you manage a customer's account, you manage their products. For example, you can change the product status or customize the product's pricing. When you create your price list, it is important to consider how the products will be managed after they have been purchased.

Specifying Which Services Are Rated by a Product

To define which services are rated by a product, you specify whether a product is associated with an account or with a single service.

  • Account. This product applies only to an account. For example, you could charge a monthly fee just for having an account, regardless of the services. Even if all services are inactivated, the monthly charge would still be applied. You can also use an account-level product for an account sign-up fee.

    You might create account-level products if you offer several services that customers do not own for any length of time (for example, access to Web simulcasts). In that case, a customer might own the following products:

    • Account-level product: $20 monthly fee

    • IP Dialup service product: $10 per occurrence

  • Single service. Usually, you associate a product with a service (for example, IP Dialup or Email). When you do this, the rates in the product are applied to that service only. It is easier to manage a price list when each product has a purchase level associated with a single service.

    When a product applies only to a single service, the product is inactivated when the service is inactivated, and charges for the service stop.

    You can associate as many products with the same service as you want.

    Note:

    Products must be associated with the same service as the deals that contain them. For example, if your product allows /service/ip, any deals containing that product must also be valid for /service/ip.

About Specifying the Events to Rate in a Product

You might need to charge different types of fees for a service, such as subscription fees and usage fees. When you create a product for a service, you define the types of fees to charge by specifying which events to rate. The group of events rated by a single product is called an event map.

For example, to charge purchase, subscription, and usage fees for a service, a product's event map includes:

  • Product Purchase Fee Event

  • Monthly Cycle Forward Event

  • IP Dialup Event

You do not have to include all types of events in a single product. A product only requires only one event in the event map, so you could create individual products for each type of event that you want to rate.

How you choose which events are rated in a product depends in large part on the services you offer, but it also depends on how you manage your business and your customers. For example, you might change your pricing often, provide sponsored services, or provide numerous types of discounts. Before you finalize your price plan, run some discounting and customer management scenarios to determine if your products are organized in a way that supports your business. For more information, see the following topics:

Specifying Product Types

There are three types of products: item, subscription, and system.

  • Item products contain rates that are applied only once (for example, a purchase fee). The only event type you can use for an item product is the purchase event.

  • Subscription products contain rates that are applied on an ongoing basis (for example, usage charges and monthly charges).

  • System products contain rates that can be applied to all products in your price list. For example, you could create products to charge for IP usage with various limitations for various customers. You could then create a system product to charge a default usage rate of $0.10 per minute for all your customers when those other products are not valid.

You specify product types when you use Pricing Center to create a product as shown in Figure 1-9:

Figure 1-9 Product Type in Pricing Center

Description of Figure 1-9 follows
Description of "Figure 1-9 Product Type in Pricing Center"

Specifying General Product Information

To create a product, you specify a product name and description. In addition, you specify information about provisioning, taxes, priority, and time- and quantity-based validity ranges.

Defining How Many Products a Customer Can Purchase

You can define the following quantity attributes:

  • You can specify whether a customer can purchase part of a product for a reduced price. For example, if an IP fax product provides 100 pages faxed for $50, you can allow customers to purchase 50 pages for $25.

  • You can define the minimum and maximum numbers of products that can be purchased. For example, if a product includes an item such as a t-shirt, you might want to limit the number of t-shirts that can be purchased simultaneously.

  • You can define the minimum and maximum numbers of products that can be owned at any given time. For example, if a product provides an email service, you might want to limit the number of email login names that a single customer can own.

Restricting When a Product Is Available

You can specify that a product is always valid, valid from a future date forward, valid until a future date, or valid for some definite period in the future as shown in Figure 1-10.

Figure 1-10 Restricting Product Availability

Description of Figure 1-10 follows
Description of "Figure 1-10 Restricting Product Availability"

For example, if you accept the default value, as shown above, your product is available immediately and always.

You can also specify:

Specifying Product Priority

When more than one product applies to an event, BRM considers products in the order of product priority. You set product priority when you create a product.

For information on enabling product priority while applying cycle fee, see "Enabling Product Priority While Applying Cycle Fee" in BRM Configuring and Running Billing.

Rating Based on Product Provisioning

Product provisioning enables you to define how a service is configured and to rate each configuration accordingly. To activate provisioning, you select a provisioning tag.

For more information, see "About Using Product-Level Provisioning to Configure Services".

Providing Deal-Level Discounts

You use deals to specify discount amounts. You use balance impacts to specify that the resource in the appropriate balance impact is discountable.

Note:

These discounts apply only to events rated by real-time rating. You can create sophisticated discounts that apply to both events rated by real-time rating and events rated by the batch pipeline.

For example, you might have a product that rates two cycle events. For one event you give free hours and for the other you charge a monthly fee. You must create a deal that discounts the monthly fee. However, when you provide a discount in a deal, the discount applies to all cycle forward fees; you cannot choose which cycle fee to discount. To discount only the monthly fee, you make the resource for the monthly fee discountable and the resource used to give free hours non-discountable.

The results of a discount can be calculated two ways. By default, the discount is applied to the product of the rate and quantity:

[(rate * quantity) – discount]

If you prefer, you can apply the discount to the rate itself:

[(rate – discount) * quantity]

See "Setting Optional Rating Flags" for instructions about setting this option.

About Deals

A deal is a set of products. Deals are typically used for the following purposes:

  • To package a set of related products.

  • To provide discounts on products for promotional purposes.

  • To define start and end dates for a product. The start and end dates that a deal provides must be within the valid start and end dates of the product.

  • To allow customers to purchase more than one of the same product with only one transaction.

  • To enable on-demand billing.

For example, you can offer two different deals for Internet access:

  • A deal that includes a $15 setup fee.

  • A deal that has no setup fee.

Each deal is typically associated with a specific service. For example:

  • A plan that offers only Internet access includes only Internet access deals.

  • A plan that offers Internet access and email includes two deals, one for Internet access and one for email.

  • A plan that offers email and IP fax service includes two deals, one for email and one for IP fax.

One deal can contain any number of products, and two different deals can contain the same product. Therefore, packaging products in deals adds flexibility to your pricing structure without requiring you to create additional products. Figure 1-11 shows a sample offering consisting of related plans, deals and products.

As with products, you can define the valid dates for deal availability, and the purchase level of the deal.

Figure 1-11 Deal Relationships to Plans and Products

Description of Figure 1-11 follows
Description of "Figure 1-11 Deal Relationships to Plans and Products"

About the Best Pricing Configuration

Best pricing is a pricing configuration that consists of a base deal and a set of alternate deals that are used to compare charges with the base deal to arrive at the lowest rate for the customer. For more information, see "About Base Deals" and "About Alternate Deals".

Because a deal is associated with a service, best pricing calculation is performed at the service level. You can calculate best pricing for multiple services by grouping services into subscription groups. For more information, see "How BRM calculates the best price for subscription groups" in BRM Configuring and Running Billing.

Note:

If the best pricing deal is purchased at the account level, best pricing calculation includes all the events from all the service instances of the account. The products and discounts from all services are included in rating.

About Base Deals

A base deal is the deal that is used to rate events as they occur. For each base deal, you can set up a set of alternate deals for a best pricing configuration.

At billing time, the charges calculated using the base deal are compared with the charges of each alternate deal to arrive at the best price.

Important:

You can configure only one base deal in each best pricing configuration.

About Alternate Deals

An alternate deal is a deal that is used to rate the events at billing time for comparing the resulting charges with the charges calculated using the base deal. BRM performs a calc-only rerating operation using the alternate deals at billing time. You can also calculate the best price at any time during the billing cycle by calling the PCM_OP_SUBSCRIPTION_CALC_BEST_PRICING opcode in calc-only mode or by using Customer Center. You can then charge your customer the lowest price calculated using the deal that costs the least.

Important:

The number of alternate deals in your configuration affects performance of the best pricing calculation.

For more information, see "Offering the best price to your customers" in BRM Configuring and Running Billing.

For each alternate deal, you can specify:

  • A minimum amount that is charged for the deal whether the services are used or not. For example, the minimum amount can be the sum of the cycle fees applicable for the deal.

  • A set of conditions that must be met for the alternate deal to qualify for best pricing calculation.

    Note:

    The minimum charge and the conditions limit the number of alternate deals that are considered for the best pricing calculation and thereby improve the performance of the best pricing calculation.

An alternate deal can have additional charges that are not in the base deal, and the rates in the alternate deal override the rates in the base deal.

An Example of Best Pricing Calculation

Consider an account that has used a total of 700 minutes and 10 Short Message Service (SMS) messages in the month and has the best pricing configuration shown in Table 1-7:

Table 1-7 Best Pricing Calculation Example

Base Deal Alternate Deal

Minutes usage charge = $0.05

Minutes usage charge = $0.03

SMS usage = $0.10

Free SMS usage

NA

Cycle fees = $10


The charges calculated are shown in Table 1-8:

Table 1-8 Calculating Charges

Usage Type Base Deal Charges Alternate Deal Charges

Minutes

700 x 0.05 = $35.00

700 x 0.03 = $21.00

SMS

10 x 0.10 = $1.00

0

Cycle fee

0

$10

Total

35 + 1 + 0 = $36

21 + 0 +10 = $31


In this example, the alternate deal charges are lower than the base deal charges, so the alternate deal is the best deal and is used for rating and billing the customer.

Purchasing Deals after an Account Is Created

When a customer registers for an account, the customer purchases deals contained in a plan. However, once an account is created, the customer can purchase add-on deals that are not included in a plan, but the deal must be associated with the same service.

Providing Discounts with Deals

You use deals to provide discounts on products. You can provide separate discounts for each type of rate. For example, if the product contains a cycle rate (for a monthly fee) and a usage rate, you can discount either or both rates.

For each rate category in each product, you can specify a percentage to discount and the dates the discount applies to.

Note:

  • You can specify if rates are discountable. See "Providing Deal-Level Discounts".

  • You can provide fractional discounts up to two decimal places (for example, 10.25%, but not 10.255%).

Prohibiting, Allowing, and Requiring Deal Modification

You can also give discounts to products in Customer Center (for example, fixed or percentage discounts on monthly fees). When you create a deal, you can specify whether to prohibit, allow, or require deal modification.

For example, to set a price based on individual customer input, you can specify that a deal must be modified.

About Product and Discount Validity Periods

Products and discounts have the following validity periods:

  • The validity period that defines when a product or discount is generally available for purchase. You define this validity period when creating products and discounts. See "Restricting When a Product Is Available".

  • The validity periods that define when the product and discount are effective for the accounts that purchase them and when the product's fees begin to accrue in the account balance and to be discounted. You define these validity periods when adding products and discounts to deals. See "Setting the Effective Periods of Products and Discounts".

Setting the Effective Periods of Products and Discounts

You specify the effective period of products and discounts by defining when the purchase, cycle, and usage periods start and end:

  • The purchase period defines when the product or discount is activated and the customer can begin to use the product's service or benefit from the discount. The product's purchase start time is also the earliest time that the product's fees can begin to accumulate in the account balance.

  • The cycle period defines when the cycle fees are charged or discounted.

  • The usage period defines when the usage fees are charged or discounted.

The cycle and usage periods must fall within the purchase period.

You can set the purchase, cycle, and usage periods to start:

  • Immediately: The effective period starts as soon as the customer purchases the product or discount.

  • On first usage: The effective period starts when the product or discount is first used. The product fees are not charged until the customer uses a service in the product for the first time: for example, by making a phone call. For more information, see "About Effective Periods That Start on First Usage".

  • Relative to the product or discount purchase time: The purchase time is the time when a product or discount is added to the account.

    • When the purchase period has a relative start time, the purchase fee is charged when the product is purchased, but the customer cannot use the product's service or benefit from the discount until the relative period ends.

    • When a product's cycle or usage period has a relative start time, the cycle or usage fees are not charged (or rated) until the relative period ends, even if the service has been activated. This option enables you to waive subscription or usage fees for a period.

    • When a discount's cycle or usage period has a relative start time, the discount is not applied to cycle or usage fees until the relative period ends.

You can set the purchase, cycle, and usage periods to end:

  • Never: Once activated, the product or discount is effective indefinitely. The product's fees can be charged or discounted indefinitely.

  • Relative to the start time: The start time is when the product or discount is activated.

    • When the purchase period ends relative to the purchase start time, the product or discount is effective for the relative period specified. After the relative period ends, the customer can no longer use the product's service or benefit from the discount.

    • When a product's cycle or usage period has a relative end time, the cycle or usage fees are no longer charged when the relative period ends.

    • When a discount's cycle or usage period has a relative end time, the cycle or usage fees are no longer discounted when the relative period ends.

About Effective Periods That Start on First Usage

Setting products and discounts to start when they are first used enables you to delay charging customers for the services they purchase until they start using those services or to delay activating discounts until they can be applied to customers' usage. This is useful when you offer limited-time services or discounts that expire relative to when they are activated.

Note:

Products that start on first usage must include usage fees. If you set a product that has no usage fee to start on first usage, the product will never be activated.

You can also set up individual resources granted by products and discounts to start when the resource balances are first consumed. For more information, see "About Balance Impacts That Become Valid on First Usage".

The effective period start time is set to the start time of the event that first uses the service or triggers the discount. The end time is set based on the end time that you configure for the product or discount.

About activating first-usage discounts

Discounts that start on first usage can be activated when the customer first uses a service, when the first cycle fee is applied, or when the account's bill is generated, depending on which fees are discounted and when the discount is triggered. For example, a first-usage discount on SMS messaging is activated when the customer sends the first SMS message, a first-usage discount on cycle fees is activated when the first cycle fee is applied, and a first-usage billing-time discount is activated when the first bill is generated for the account.

A discount on a particular service may not be activated when a customer first uses that service. For example, if long-distance calls are discountable for a telephony service, a customer may make multiple local calls, which do not trigger the discount's effective period, before making a long-distance call.

There are some cases in which a discount's balance impact is negated by a second discount. If this occurs, the first discount's validity period is still set.

For example, a customer purchases a plan that includes discount A and discount B:

  • Discount A is configured to start when first used, gives 10% off of all calls, and has a higher priority, so it is applied first.

  • Discount B is configured to start immediately and makes all birthday calls free.

If a customer makes a first-usage call on his birthday and is charged $5.00 for the call, discount A is applied first, which reduces the balance by $.50, and discount A's validity period is set. Then discount B backs out all charges. In this case, the validity period of discount A remains set.

About setting first-usage validity during pipeline rating

If you use Pipeline Manager to rate usage, configure these pipelines to set the effective periods of products and discounts when they are first used:

About Product and Discount Status at Purchase

When you add a product or discount to a deal, you also specify whether the product or discount is active or inactive at the time of purchase. Additionally, for products or discounts with inactive status, you must also specify a reason code that further describes the reason for the inactive status.

You define reason codes in the reasons.locale file. For more information, see "About the reasons.locale file" in BRM Configuring and Collecting Payments.

Assigning Services to Deals

You define the services that a deal applies to by assigning a purchase level to a deal. The purchase level can be any of the following:

  • A single service. Usually, you set a deal's purchase level to a single service. The products in the deal and the rates they contain can only be applied to that service. This makes it easier to create plans: you have more flexibility in putting together a combination of deals when each deal applies to a specific service. Also, when a CSR adds a service to an account, it is easy to find the correct deals to offer when the deals are associated with individual services.

  • All accounts/no services. When you set the purchase level to all accounts/no services, you create an account-level deal. Each account can have only one account-level deal. The account-level deal typically includes account-level products (for example, a product that specifies the monthly charge for owning an account, regardless of the services).

Using Deals to Bill Customers on Demand

On-demand billing enables you to bill a customer immediately for a purchase, even if the customer's billing cycle has not ended.

When you create a deal, you can flag it for on-demand billing. When a customer purchases a deal that is flagged for on-demand billing, a bill is generated immediately for the purchase fees associated with the deal.

Note:

On-demand billing works with purchase fees only, not with cycle, usage, or cancel fees.

For more information about on-demand billing, see "About on-demand billing" in BRM Configuring and Running Billing.

About Deal Dependencies

You can define dependencies between deals in Pricing Center that set up the following relationships:

  • Prerequisites. Specifies that an account must own a particular deal to be able to purchase an additional deal.

    Note:

    A prerequisite can contain deals of different services. For example, to own a GPRS deal, an account must own a GSM deal.

    Note:

    A prerequisite deal cannot contain item products. When you create a plan with alternate deals, and if the base deal contains an item product, the purchase fails.
  • Plan requirements. Specifies whether deals are optional or required for plans. Required deals must be purchased when a plan is purchased, whereas optional deals can be added at any time.

  • Mutual exclusivity. Sets up a mutually exclusive relationship between two deals so if an account owns one deal, it cannot own the other.

  • Allowed transitions. Specifies which deals or plans can serve as replacements for others.

    Transitions specify the deals that customers can switch to and remain fully provisioned. While transitioning from one deal to another, your customers retain their devices, such as phone numbers and services.

    Customers owning deals associated with a primary service may transition to other deals associated with that primary service. The list of deals displayed as available for transition are all associated with a specific primary service.

Strategies for Creating Deals

You typically use deals for providing discounts. This enables you to create fewer products and to create a baseline of standard products that you can manipulate with deals.

For example, you could create several products, each with different rates. Or, you could create a single product and change the rates by providing discounts in deals.

Also, to make your deals easier to handle in Customer Center, you should associate each deal with a single service. A common exception is a deal that applies to all accounts, which you associate with accounts instead of a service.

When you create a deal, you can specify whether to prohibit, allow, or require deal modification. In addition, when you create a plan with options, you can specify whether the deals contained in the plan are required or optional when the plan is purchased.

Using Deals across Time Zones

When a deal is created, the start and end dates are set to the current date at midnight GMT (Greenwich Mean Time). For example, if a user in the US creates a deal at any time on January 15th, the system stores it as January 15th, midnight GMT. If the BRM server is located in London, its time is set to GMT/London time, which is 5 hours later than the US-based user's computer. If the US-based user opens a deal using Modify Product, the deal's start time is posted as 5 hours earlier than January 15th/midnight, or 7:00 PM on January 14th. The start date is then recorded as January 14th, rather than January 15th.

To avoid a time discrepancy, add the following string to the Infranet.properties file:

infranet.user.timezone = time_zone
  

where time_zone is the appropriate time zone, such as Europe/London or America/Los_Angeles.

About Plans

You use plans to offer your services to customers. For example, if your company sells Internet access, email, and IP fax service, your plans might include:

  • A plan that sells only Internet access.

  • A plan that sells Internet access and email.

  • A plan that sells email and IP fax service.

Figure 1-12 shows how you can include deals, and the services they apply to, in a variety of plans.

Figure 1-12 Plan Relationships to Deals and Products

Description of Figure 1-12 follows
Description of "Figure 1-12 Plan Relationships to Deals and Products"

Usually, plans include services. By including services in plans, a customer creates a service login name and password during registration. The only time you might not include a service in a plan is if the plan contains only account-level products and deals. In that case, you register a customer, and assume that services are added later.

One plan can contain any number of deals, and two different plans can share the same deal. By grouping deals into plans, you simplify the choices presented to customers.

Note:

Plans always include deals. The only exception is the CSR plan.

About Applying Credit Limits to Resources

You use plans to apply credit limits to resources.

A credit limit is the maximum amount of a resource, such as currency or hours, that can accumulate in an account balance before the customer is prevented from logging in or using a service. For example, you might set a credit limit of $100 for an Internet access plan.

Note:

The default credit limit for currency resource is NULL and non-currency resource is 0. The default currency resource must have a positive value and the non-currency resource must have a negative value.

Credit limits are defined in the plans that customers purchase. Credit limits must also be defined in the input flist when the customer account is created.

  • If the credit limit is not defined in the input flist, the credit limit defaults to NULL even if the credit limit is defined in the plan.

  • If the credit limit defined in the plan differs from the credit limit in the input flist, the credit limit in the input flist is used.

You use Customer Center to change the credit limit.

Though the credit limits are defined in the plans that customers purchase, the same credit limits must be must be defined in the input flist when the customer account is created. The following scenarios apply:

About Credit Thresholds and Credit Floors

You set credit thresholds to notify customers when they are approaching the credit limit of a resource. Credit thresholds are defined in plans.

The credit threshold specifies the balance total that triggers an alert to the customer. You can specify the threshold in two ways:

  • As a fixed value, such as $100 or 30 minutes.

  • As a percentage of the credit limit, such as 90%. For example, if the credit limit is $100 and the threshold is 90%, the threshold amount is reached when the customer has a balance of $90; that is, when the customer has used 90% of the resource.

The credit floor is the starting point for the credit thresholds and is the lowest number that the resource value can be; that is, the number that represents no use of the resource. For currency resources, the credit floor is 0.

For non-currency resources, such as prepaid hours, you can use a negative number for the credit floor. For example, if you give 100 prepaid hours and you set the credit limit to 0; when the credit limit is reached, the customer has no hours remaining and cannot use the service. To notify the customer when there are only 10 hours left, you set the credit threshold and floor as follows:

  • Set the credit floor to -100. This is the number that indicates none of the resource has been used.

  • Set the credit threshold to 90%.

The threshold is reached at 90% of -100 hours; that is, when the customer has 10 prepaid hours left.

Note:

You can adjust a customer's credit limit.

The credit threshold is triggered both when the balance increases and when it decreases.

You can enable BRM to provide credit threshold breach notifications as in-session notifications appended to the responses it sends to network connectivity applications. BRM sends these notifications in its responses to the authorization and reauthorization requests that BRM receives from these applications during prepaid sessions. For more information on in-session notifications in prepaid sessions, see "Providing In-Session Notifications for Network Connectivity Applications" in BRM Telco Integration.

You can customize BRM to perform different actions in each case. For example, if the credit threshold is crossed when the balance is increasing, service could be turned off. When the threshold is crossed when the balance is decreasing, service could be restored.

Credit Limit and Floor Options

There are two optional settings that affect the way credit limits and floors are handled during rating:

  • You can choose to turn off the checking of credit floors. Credit floor checking sometimes causes certain events to be skipped during rating.

  • You can choose whether to impose a zero credit limit if there is a balance impact to a resource in an account where the balance element for that resource is missing. If you choose to use a zero credit limit, the balance for that resource cannot exceed zero. If you choose not to use the credit limit, the balance can be any amount.

You set these options by changing entries in the Connection Manager (CM) configuration file (BRM_Home/sys/cm/pin.conf). See "Setting Optional Rating Flags" for details.

Tracking Resources by Service

Accounts can have multiple balance groups. By default, accounts are created with one balance group. You can add additional balance groups to track resources for specific services when you create your plans in Pricing Center.

For example, to track resources for a $50.00 prepaid wireless service, you create a balance group for the service in the plan and specify a credit limit of $0.00. You specify $0.00 because prepaid services have a credit balance, represented by a negative number, in this case, -$50.00. As customers use the service, the balance is debited until it reaches $0.00.

If you do not create additional balance groups, resources for every service a customer purchases share the same balance group. This means that resources such as free minutes are shared among all services. By creating a balance group for each service, you can control the allocation and consumption of resources for each service instance.

When customers purchase plans, the associated balance groups are added to the customers' accounts. Customers' account balances are then displayed in Customer Center for each service or set of services stored in a balance group.

CSRs can also specify credit limits for the services in a balance group when they create customer accounts. For example, customers might want to limit the monthly amount they spend on phone calls. CSRs set credit limits in Customer Center.

Grouping Services by Subscription

You can group services by subscription (for example, a set of services associated with a wireless connection). You group subscription services to track balances and bill customers for individual subscriptions rather than for the accounts.

An account can contain multiple subscriptions. To group subscription services, you define the service that represents the subscription, then associate it with the services that customers actually use. For example, you might use a telco service to represent the subscription and associate it with telephony and messaging services. When customers purchase the telco subscription and use the associated services, the service fees are tracked and stored at the subscription level.

For more information, see "Managing customers' subscription-level services" in BRM Managing Customers.

Creating CSR Plans

In addition to providing services to your customers, plans provide services to CSRs.

To create a CSR plan:

  1. Use Pricing Center to create a plan that has the following attributes:

    • Use the admin_client service. This service provides access to Customer Center users.

    • Include no deals.

  2. Add the CSR plan to the CSR - new plan list.

CSR plans serve two purposes:

  • They control access to Customer Center.

  • They allow customer management events to be recorded, including information about the CSR who generated the event. This information can be helpful when researching customer complaints.

Using Plans to Bill Customers on Demand

On-demand billing enables you to bill a customer immediately for a purchase, even if the customer's billing cycle has not ended.

When you create a plan, you can flag it for on-demand billing. When a customer purchases a plan that is flagged for on-demand billing, a bill is generated immediately for the purchase fees associated with the plan.

Note:

On-demand billing works with purchase fees only, not with cycle, usage, or cancel fees.

For more information about on-demand billing, see "About on-demand billing" in BRM Configuring and Running Billing.

Strategies for Creating Plans

When your customers register for accounts, they are presented with a list of your plans. Similarly, CSRs see a list of plans when creating accounts. Therefore, you should be careful about your plan names and descriptions.

Important:

A plan name can include a maximum of 255 characters. A plan description can include a maximum of 1023 characters.

You might consider using optional deals when creating plans. This enables you to include all relevant deals in one plan, without requiring customers to purchase all of them. Optional deals are available for purchase at registration time or any time afterward. For example, say a company offers a GSM service plan that includes a standard GSM deal, voice mail deal, and a text messaging deal. CSRs are required to purchase the base GSM deal for the service and have the option of adding the voice mail deal and text message deal for the customer at a later time. Adding optional deals to plans also filters the deal list in Customer Center, so that only the deals within the plan are available when CSRs add on deals to a current account.

Another strategy is to consider creating plans that form a logical upgrade path. For example, one plan might offer a per page rate for IP Fax service, while the higher-grade plan offers unlimited IP Fax service.

A third strategy is to create plan-to-plan upgrades, downgrades, or generation changes. This enables you to easily transition customers from one plan to the next by defining rules that govern how plans can be purchased.

Transitioning between Plans

You can perform three types of transitions between plans: upgrade, downgrade, and generation change. You define the plans that can be transitioned when creating plans in Pricing Center.

For generation change, you can transition customers between 2G (second generation) and 3G (third generation) wireless plans and services. Plans are called 2G or 3G depending on whether they have a second- or third-generation service as their primary service type.

Note:

For service-level extended rating attributes (ERAs), be aware that ERA profile information is not automatically transferred between plans during plan transition or generation change. If the two plans have some common provisioning tags, the ERA profile information can be reconfigured in the new plan.

For more information about defining generation change transitions, see "Defining a generation change for plans" in BRM Managing Customers.

About Plan Lists

A plan list is a group of plans, usually offered to a single type of customer. You use plan lists to group rate plans based on customer types, such as the customer's age and address. For example, you might have the following plan lists:

  • A plan list that includes plans for customers above a certain age.

  • A plan list that includes plans for customers in a particular location (for example, Canadian customers).

  • A plan list that includes promotional discounts that you offer for a limited time.

Grouping plans into plan lists enables you to:

  • Offer plans to customers based on customer type. For example, in Pricing Center you can define a Gold - Senior plan list with two plans, GS1 and GS2. Based on the age group of the user, you can use the Gold - Senior plan list to limit the offerings to your customers through your customer management application to GS1 and GS2.

    Note:

    You must maintain mapping between your plan lists and your customer types.
  • Control the rollover of free resources. For example, you can control rollovers with a rule specifying that when a customer changes plans, free resources can be rolled over only if plans are within the same plan list.

The name and type together identify a unique plan list. The name and type are case sensitive. For example, Gold - Senior and gold - senior are two different plan lists. You can assign any name and type to the plan lists.

You can create any number of plan lists for your database, and each plan list can contain any number of plans. Two different plan lists can contain the same plan.

The plan list does not have to include all of your plans. You can create plans and not include them in a plan list until you need them. Or, you can offer one set of plans to one group of potential customers, and another set of plans to another group.

BRM includes two types of plan lists:

  • Use new plan lists to register new customers.

  • Use add-on plan lists to add services to existing accounts.

You can also add your custom plan list based on the customer type.

The plan lists you create are displayed in Customer Center. If you use your own custom application, use the PCM_OP_CUST_POL_GET_PLANS policy opcode to retrieve and display plan lists.

About the Default and CSR Plan Lists

BRM includes special plan lists that you can use to determine where the plans are displayed. For example, you might want some plans to be displayed only in Customer Center.

  • Plans in the CSR - new and CSR - addon plan lists are displayed only in Customer Center.

Note:

The webclient name is the default but can be changed. See "Specifying which plan list to display" in BRM Managing Customers.
  • Plans contained in the default-new and default-addon plan lists are used in Customer Center if the CSR plan list is not available.

About Offer Profiles

Offer profiles are made up of one or more policy labels each of which defines a gradation in the quality of service (QoS) based on usage amounts for a resource.

For example, you can have an offer profile called "Platinum" for a data service and define its resource as Megabytes Used. You can define a policy labeled Fair Usage, which has three levels, Low QoS, Medium QoS, and High QoS, with each level containing a usage range valid for that quality of service.

Price List Example

In the sample price list shown in Figure 1-13, three services are offered: Internet access, email, and IP fax service. All rate plans used in this price list are real-time rate plans.

Figure 1-13 Sample Price List

Description of Figure 1-13 follows
Description of "Figure 1-13 Sample Price List"

Note the following points about how this price list is organized:

  • There are two products that define different monthly fees for Internet access. These products are used by different deals.

  • Two of the plans include two deals, the other two plans include only one deal each.

For information about the sample plans, see "Understanding the Sample Pricing Plans".

About Setting Up a Price List

Setting up a price list typically requires the following steps:

  1. Marketing and finance personnel define which services your company offers, and how much to charge for them. For example, they define how much to charge each month, how much to charge for online usage, and how much to charge to sign up for a plan.

  2. Operations personnel review the pricing model to determine if any new services must be created to support the price list. In addition, they determine if any new resources, services, events, general ledger (G/L) IDs, or tax codes must be created. See "Prerequisites for Creating a Price List".

  3. An operations person plans the price list (for example, to determine how many plans and deals to create and to determine the products that make up the plans). This plan is typically reviewed by marketing and finance personnel to confirm that it implements the company's pricing model. See "Planning Your Price List".

  4. An operations person uses Pricing Center to create the price list. Because products are the basic unit of the price list, they are created first. See "About Using Pricing Center".

  5. An operations person tests the price list. See "Testing Your Price List".

Prerequisites for Creating a Price List

Before you create a price list, you must complete the following tasks:

  • Create services and events

    BRM includes Internet access and email services by default, but you might need to modify them or add new services before you create your price list. You must also configure a list of events to track for each service. If you create new services, you may need to create new events to track them.

  • Create resources

    Rate plans require resources. Use the Resource Editor in Pricing Center to add or modify resources. For more information, see "About Resources".

  • Define currency conversion rates

    Using more than one currency requires that you define currency conversion rates.

  • Create G/L IDs

    You use G/L IDs to collect general ledger information from the BRM database and export it to your accounting application. You must decide how to track the revenue for each type of rate and create the appropriate G/L IDs.

  • Define tax codes and tax suppliers

    To calculate taxes by using Taxware, you must define tax codes and tax suppliers.

  • Set up Offer Profiles

    To ensure that resource tracking for policy-driven provisioning of services, use the offer profile name as the provisioning tag in the product or discount. Set the resource used in the offer profile as the resource counter in the product or discount

  • Define product-level provisioning categories

    If you use product-level provisioning, you must define provisioning tags. See "About Using Product-Level Provisioning to Configure Services" and "Working with Provisioning Tags".

  • Define ratable usage metrics (RUMs) for events

    You use RUMs to identify the event attributes to rate for each event. RUM definitions are stored in the BRM database. You use a text editor and a utility to define RUMs. For more information, see "About Ratable Usage Metrics".

  • Map event types to services

    When you create a product, you select a service and events you want to rate that are related to that service. Because all event types are not valid for all services, you map event types to services. Creating this map prevents you from selecting an event that does not occur for a given service. See "Mapping Event Types to Services".

  • Define zones

    For real-time rating, you use zones to create a single value to represent a group of values. You use the representative value in a rate plan selector. See "About Using Zones to Group Event Attributes".

    For information on zones in batch pipeline rating, see "Setting Up Zones for Batch Pipeline Rating".

  • Define impact categories

    For real-time rating, you use impact categories to specify that a particular group of balance impacts within a rate should be used. If you plan to use attribute value grouping during rating, you must define some impact categories. See "Using Event Attributes to Rate Events in Real Time".

    For pipeline rating impact category information, see "About Impact Categories".

  • Define pipeline data

    If you use pipeline rating, you must define several types of data and pricing components. See "Setting Up Pipeline Price List Data" and "Data Required to Create Rate Plans".

Planning Your Price List

When you plan your price list, you determine how much to charge for your services, for example:

  • Which types of fees to use for a service, such as a flat monthly fee, hourly usage fees, or both.

  • The rates to charge for monthly fees, hourly usage, set up, and so forth.

  • Discounts such as those based on time of day, date of purchase, or volume usage.

  • How to handle multiple currencies.

  • Special pricing options such as sponsored rates.

    Tip:

    Because price lists are built by setting up relationships among plans, deals, and products, it is helpful to draw a diagram of your price list before you create it in Pricing Center. For an example, see "Price List Example".

About Using Pricing Center

You use Pricing Center to create and modify your price list.

Note:

Offer profiles cannot be created or modified using Pricing Center. Use the loadpricelist utility or the PCM_OP_OFFER_PROFILE_SET_OFFER_PROFILE opcode.

With Pricing Center, you can perform the following tasks:

  • Create and modify products, deals, plans, and plan lists.

  • Create and modify rate plans for products. You can create rate plans for real-time rating and for pipeline batch rating.

  • Define complex rate plans for your services based on valid time periods, event quantities, and rate priorities.

  • Set credit limits and discounts.

  • Reuse deals, plans, products, and rate plans so you do not need to re-create them every time.

  • Update your pricing model without stopping and restarting your BRM system.

  • Save a pricing document to a binary file and open the file at a later date. This enables multiple people to work on different pricing objects that will be committed to the same database.

Who Uses Pricing Center?

Generally, the services you offer and how you charge for them are defined by your marketing and finance personnel. The price list is typically created by operations personnel using Pricing Center. You should outline, in detail, your entire pricing structure before you use Pricing Center to implement it.

Example of Using Pricing Center

When you are ready to use Pricing Center to create a price list, the price list should be planned, and all necessary components, such as resources, G/L IDs, and RUMs should be in place. (See "Prerequisites for Creating a Price List" and "Planning Your Price List".)

You perform the following steps to create a price list by using Pricing Center:

  1. Start by using the Product Creation wizard to create the products. The wizard steps you through the general product parameters, such as the name and description of the product, the service it applies to, and the start and end dates.

  2. When you finish, Pricing Center displays the product attributes that you selected. You can change them at any time.

  3. After the general product properties are defined, you define the rate plans that specify how much to charge. In the example illustrated in Figure 1-14, the product includes an IP connection fee, a monthly fee, and a purchase fee, so you create rate plans for those events:

    Figure 1-14 Product Example

    Description of Figure 1-14 follows
    Description of "Figure 1-14 Product Example"

  4. For real-time rate plans, you apply balance impacts to each rate plan. Figure 1-15 shows the balance impacts for a purchase fee:

    Figure 1-15 Balance Impact Example

    Description of Figure 1-15 follows
    Description of "Figure 1-15 Balance Impact Example"

  5. When the product is finished, you create a deal and add the product as shown in Figure 1-16:

    Figure 1-16 Adding Product to Deal Example

    Description of Figure 1-16 follows
    Description of "Figure 1-16 Adding Product to Deal Example"

  6. Then you tailor the product settings specifically for the deal.

    To discount real-time rates, you can include a discount in the deal. Figure 1-17 shows a deal that provides a 50% discount for the first month cycle fee.

    Figure 1-17 Discount Example

    Description of Figure 1-17 follows
    Description of "Figure 1-17 Discount Example"

  7. After defining deal-specific values for the products, you create a plan and add the deal to the plan. In the plan, you set the credit limit. In Figure 1-18, the credit limit is $200.

    Figure 1-18 Plan Attributes Example

    Description of Figure 1-18 follows
    Description of "Figure 1-18 Plan Attributes Example"

  8. After creating the plan, you add it to one or more plan lists. In Figure 1-19, the plan is added to the CSR - new plan list. This plan list is displayed in Customer Center.

    Figure 1-19 Plan List Attributes Example

    Description of Figure 1-19 follows
    Description of "Figure 1-19 Plan List Attributes Example"

  9. After adding the plan to the plan list, choose File - Commit to commit the price list to the database.

    You test the price list by creating accounts that use your new plan, generating activity, and running billing to ensure that the account a balances are impacted correctly. See "Testing Your Price List".

Making Changes to Your Price List

You can make changes to your price list at any time. For example, if you offer a new service, you can create new plans and deals to charge for that service.

You can also change rates for existing products, add products to existing deals, and so forth.

Deleting Products

You cannot delete a product from the price list if it is owned by any account. To delete a product, cancel it in all accounts.

Logging Changes to Price Lists

To get notified when price lists change, BRM can create messages in the cm.pinlog file when price lists are updated. For information about cm.pinlog and other log files, see "Using logs to monitor components" in BRM System Administrator's Guide.

To log price list changes, set the fm_rate log_refresh_product entry in the Connection Manager (CM) pin.conf to 1. If this entry is absent or set to 0, BRM does not log changes to the price lists.

Note:

Products which are used while rating events are cached by rating. The cache is refreshed when a product is modified based on the CM pin.conf entry refresh_product_interval. This entry specifies the time after which the cache needs to be refreshed. If this entry is not specified, the default refresh interval is one hour. When the cache is refreshed and log_refresh_product is enabled, a debug message is created in the cm.pinlog file indicating the product POID that was refreshed.

To log price list changes:

  1. Open the CM configuration file (BRM_Home/sys/cm/pin.conf).

  2. Set the value for the fm_rate log_refresh_product entry to 1.

    - fm_rate log_refresh_product   1
      
    
  3. Save the file.

  4. Stop and restart the CM.

Ensuring Price List Consistency

For implementations covering a large geographic area, you might need regional price lists, each with variations in the pricing structure. In that case, you should maintain consistency in the names of price list elements.

For example, use a common name for non-currency resources, such as access hours. It is easier to keep track of global usage when a resource has the same name on every regional price list. You should also have common names for usage rates.

Keep in mind that rates are applied independently of the products that include them. If multiple developers create products independently that can be purchased by the same customers, ensure that the rates in those products charge the same amounts and do not have conflicting priorities.

Troubleshooting a Price List

Pricing Center checks the validity of your price list. If you cannot save your price list, check for the following errors:

  • Time conflicts. For example, you might set the start date for a rate to March 1 and then set the start date for a deal that contains the rate to February 1st. This means that on February 1st, a deal is available for purchase that contains a rate that is not valid for another month.

  • Nonvalid credit limits and credit floors. A credit limit must be equal to or greater than 0. A credit floor must be less than or equal to the credit limit.

    Important:

    Pricing Center does not include or validate pipeline rating data when you save a price list.

Displaying Price List Elements

You can show a detailed outline of all the elements in a price list, including plans, deals, products, rate plans, and rates by running the PriceList report. For more information, see "Price List report" in BRM Reports.

Note:

Offer profiles cannot be displayed using Pricing Center.

Creating a Price List with the XML Pricing Interface

You can use the XML Pricing Interface instead of using Pricing Center to create your price list. See "Using the XML Pricing Interface to Create a Price List".

Common Price List Solutions

The following topics describe how to implement these common price list solutions:

Providing Free Hours

To provide 10 free hours every month, you need three rate plans:

  • A cycle forward rate plan that credits 10 free hours every month.

  • A usage rate plan with two rate tiers: one that charges hours as the resource until the free hours are gone and one that charges dollars as the resource.

  • A fold rate plan that deletes unused hours if the customer does not use all 10 free hours.

For example:

  • Cycle forward rate plan: Credit 10 hours per month

  • Balance impact: -10 hours every month

  • Usage rate plan:

    • Rate tier 1: Charge hours. This tier is valid until the hours in the customer's account reaches 0.

    • Balance impact: 1 hour for every hour online

    • Rate tier 2: Charge dollars. This tier is valid when rate tier 1 can no longer be applied.

    • Balance impact: 1 dollar for every hour online.

  • Fold rate plan: Delete unused hours (see "Deleting Unused Free Hours").

Figure 1-20 shows how the free hours are used first:

Figure 1-20 Free Hours Example

Description of Figure 1-20 follows
Description of "Figure 1-20 Free Hours Example"

Deleting Unused Free Hours

When you credit free hours every month, you probably do not want your customers carrying over unused free hours from one month to the next.

To delete unused free hours, create a cycle fold rate plan that subtracts one hour for every free hour in the customer's balance at the end of the month. After the rate plan removes the left-over free hours, a cycle-forward rate plan applies the monthly credit of free hours.

Figure 1-21 shows the balance impact in Pricing Center. The resource is hours and the balance impact is -1, which removes one hour for every hour in the account balance.

Figure 1-21 Balance Impact that Deletes Unused Hours

Description of Figure 1-21 follows
Description of "Figure 1-21 Balance Impact that Deletes Unused Hours"

Charging for Canceling a Product

To charge a fee for canceling a product, you include a cancel rate plan in your product.

To create a cancel rate plan that is applied only when closing an account, create a product that has only a cancel rate plan. You can cancel other products without charging a cancel fee, but when the account is closed, the product with the cancel rate plan is canceled, which generates the cancel fee.

Charging a Discounted Purchase Fee Based on Date of Purchase

To charge a discounted purchase fee based on the date of purchase, you need two rate tiers:

  • A high-priority rate tier that is valid only in a specified date range. This rate tier charges the discounted purchase fee.

  • A low-priority rate tier that is always valid. This rate tier charges the normal purchase fee.

For example:

  • Rate tier 1: Discounted purchase fee

  • Priority: high

  • Balance impact: 7.5 US dollars

  • Absolute duration end time: 12:00 a.m. on 12/31/99

  • Rate tier 2: Normal purchase fee

  • Priority: low

  • Balance impact: 15 US dollars

Creating a ”Third-Month Free” Rate

To give a customer the third month of a cycle forward fee free, you must create a cycle forward rate plan with two rate tiers:

  • Create a high-priority rate tier that uses relative duration to start three months after the product is purchased and has a balance impact of 0.

  • Create a low-priority rate tier for the normal cycle forward fee.

For example:

  • Rate tier 1: Free month

  • Balance impact: 0 US dollars

  • Relative duration start time: 55 days

  • Relative duration end time: 65 days

    The relative duration start date is 55 days after purchase to ensure that the rate tier is valid before the third billing cycle starts, which, depending on the length of the month, could start within 59 days of the product purchase.

    The relative duration end date is 65 days after purchase to ensure that the rate tier is not valid in the fourth billing cycle.

  • Rate tier 2: Normal cycle fee

  • Balance impact: 19.95 US dollars

Creating Discounts Based on Usage

To define a rate plan based on volume usage, use multiple quantity discount brackets.

The following example uses two quantity discount brackets; one to charge .02 US dollars for each of the first 100 email messages and another .01 US dollars for each subsequent message.

Which quantity discount bracket is selected depends on the total quantity rated by both brackets.

  • Quantity Discount Bracket 1: Balance impacts for first 100 email messages

  • Minimum quantity: none

  • Maximum quantity: 100

  • Balance impact resource: US dollars

  • Scaled impact: .02 US dollars

  • Quantity Discount Bracket 2: Balance impacts for email messages after the first 100

  • Minimum quantity: 100

  • Maximum quantity: none

  • Balance impact resource: US dollars

  • Scaled impact: .01 US dollars

Creating Products for Administrative Events

To create products for administrative events, you must first define usage rates, as explained in "About Charging for Administrative Events".

When you create the products:

  • If the event that you're rating is not tied to any service, use the All Accounts/No Services purchase level.

  • If the event applies to all customers at all times, use the default product to define the rate.

Advanced Rating Features

For information about advanced rating features, see:

Charging Cycle Forward Fees in Advance

You can set up cycle forward rates to charge cycle forward fees in advance. This enables you to charge all or a portion of the next cycle fee in the current bill.

When you define your event map in Pricing Center, you can specify how far in advance to bill in days, weeks, or months, as shown in Figure 1-22:

Figure 1-22 Advance Billing Example

Description of Figure 1-22 follows
Description of "Figure 1-22 Advance Billing Example"

As part of setting up billing in advance, you must enable proration. Use Pricing Center to enable proration and take the other steps necessary to set up billing in advance.

Example: Charging Cycle Forward Fees in Advance for Monthly Cycle Fees

Suppose billing is monthly and in advance billing is set for 15 days.

When billing occurs on February 1, it charges cycle fee from February 1 to March 1 and additional 15 days to March 15.

When billing occurs on March 1, it charges cycle fee from March 15 to March 31 and additional 15 days to April 15.

When billing occur s on April 1, it charges cycle fee from April 15 to May 15, and so on.

Example: Charging Cycle Forward Fees in Advance for Quarterly Cycle Fees

Suppose billing is monthly and in advance billing is set for one month.

When billing occurs on February 1, it charges cycle fees from February 1 to May 1 and additional one month to June 1.

When billing occurs on March 1 and April 1, no cycle fees are charged.

When billing occurs on May 1, it charges cycle fees from June 1 to August 1 and additional one month to September 1.

When billing occurs on June 1 and July 1, no cycle fees are charged.

When billing occurs on August 1, it charges cycle fees from September 1 to December 1, and so on.

About Charging for Administrative Events

You can charge for administrative events, such as changing a password. To do so requires programming. See "About Charging for Custom Events and Attributes".

About Using Product-Level Provisioning to Configure Services

You can use product-level provisioning to define how a service is configured and to rate each configuration differently.

For example, if you have a product that provides an IP service, you can define two service configurations based on the bandwidth of the IP connection. You would create two products, one for each service configuration (for example, Fast Fax and Regular Fax).

To create products that configure services, you assign provisioning tags to the products. For example, to create a Fast Fax product, you would create a Fast_Fax provisioning tag that sets a higher bandwidth for the customer's connection. When a customer purchases the product that includes the Fast_Fax provisioning tag, the fax service is provisioned with the higher bandwidth.

When creating products in Pricing Center, you choose the provisioning tag that identifies the service configuration:

Graphic is described in surrounding text.

The advantage to configuring services by using products is that you do not need to define different services to handle different service configurations.

You can also use provisioning tags to create extended rating attributes, which enable you to offer special rates and promotions.

To create provisioning tags, see "Working with Provisioning Tags".

About Remittance

Use the remittance feature to share the revenue you receive with third parties. You can direct BRM to calculate the amount of remittance in various ways: for example, you can pay a percentage of subscriber fees or a flat amount per new subscriber to third parties such as resellers or service providers.

You must create remittance products to use the remittance feature. For more information, see "Remitting funds to third parties" in BRM Configuring and Running Billing.

About Custom Event Analysis

Custom event analysis enables you to perform rating based on:

  • Custom attributes of events or non-event attributes, such as an account attribute or a profile attribute.

  • Guidelines that are more complex than the defaults, such as rating based on percentage values or expressions containing a greater than or less than operator.

Setting up custom event analysis requires modifying or creating a policy opcode and editing and loading several configuration files. For more information, see "About Charging for Custom Events and Attributes".

Setting Optional Rating Flags

You can turn a number of optional rating features on and off by changing entries in the Connection Manager (CM) configuration file (BRM_Home/sys/cm/pin.conf):

  • Changing the way fixed discount amounts are calculated. See "Providing Deal-Level Discounts".

  • Turning credit floor checking on and off. See "Credit Limit and Floor Options".

  • Determining whether to apply a credit limit when an account does not include a balance for a particular resource. See "Credit Limit and Floor Options".

  • Determining whether folds for canceled (inactive) products should be rated.

  • Determining whether the PIN_FLD_EXTENDED_INFO substruct field should be returned with the rating results. This field can be used to transport reusable information among transactions. For more information, see the input flist specification for PCM_OP_RATE_EVENT.

To use these features:

  1. Open the Connection Manager (CM) pin.conf file in BRM_Home/sys/cm.

  2. Change the value of the extra_rate_flags entry.

    Each feature has a different hexadecimal value shown in Table 1-9:

    Table 1-9 Optional Rating Features and Values

    Optional Rating Feature Value Effect

    Fixed discount option

    0x01

    If present, discounts are calculated using this formula:

    [(rate – discount) * quantity]

    If absent, discounts are calculated using this formula:

    [(rate* quantity) – discount]

    Credit floor checking

    0x02

    If present, credit floor checking is disabled.

    If absent, credit floor check is enabled.

    Return extend information

    0x10

    If present, extended information is returned with the rating result.

    If absent, extended information is not returned.


    To use more than one option, add the values for each option and use the sum value.

You do not need to restart the CM to enable this entry.