Companies Architect New Ways to Cross Product Discount

Billing developers, intent on jumping into the emerging bundled services arena, approach the automation of discounting bundled services from different angles. The ability to offer discounts to wireless customers who sign up for several telecom services from a single carrier can give telcos a strategic edge in the battle to win customers.

“Different people have different approaches to do convergent billing and cross-product discounting,” says Stuart Hoffman, president and CEO with iSoft. “The end result is you want your existing software modules—your rating and discounting modules—to have applicability across a broader service space. So every vendor has its own strategy for turning heterogeneity to homogeneity.”

First step: Be convergent

But a carrier must first be able to obtain true bundling of services before systems for cross-product discounting (CPD) can be easily implemented, according to industry experts. “A lot of people are electronically stapling [services] at the back end,” says Telution CEO Ken Steffen. “If you don’t have the concept of a bundled bill, then you make it very difficult within your billing engine to even start doing bundled discounting. That’s a problem for most of the billing vendors, and you know, they put lipstick on a pig and keep trying to find creative ways around that.”

“The basis for providing cross-line discounting is to have convergent systems,” says Shlomo Baleli, president of software development at Amdocs. “We’re talking about true convergence, not just bill stapling at the back end, which means you have to have one integrated customer database, and one integrated environment that enables one to provide the CPD.”

It’s hard work without true bundling

Although some carriers without truly convergent billing systems can create CPD functionality, it’s cumbersome and time-consuming. “We’ve seen people effectively do it [without bundling], but the amount of work that has to happen and how specific it is to the products you’re tying together makes it a lot less flexible. It takes a significant amount of work and time to get that to market,” Steffen says.

A sampling of billing companies pursuing cross-product discounting reveal that each has a unique approach to creating automated discounting. And it isn’t easy.

What to do with large accounts?

Creating a CPD system to handle the multitudes of discounting possibilities can be mind-numbing. Carriers with national footprints must be able to match discounted bundled offerings to the competitive mood in various parts of the country. Carriers who offer CPD to large corporations with offices around the world must have systems sophisticated enough to track huge accounts with hierarchical discounting plans. Marketing departments constantly reinvent discount offerings, keeping billing developers on their toes. And then there’s the issue of taxation. How does one tax for discounted services? How does one apply tax rates to buckets of free wireless minutes? How does one tune the tax modules to make it reflect a 10 percent discount on cellular calls?

To tackle myriad rates, schedules and environments in which discounting functionality must operate, billing developers use a combination of network restructuring, software redesign and database manipulation.

ISoft creates data illusion

ISoft, which has a contract with Convergys, uses data integration to trick billing systems into believing different data streams originate from one source, Hoffman says. “We are able to pull in information from disparate sources and give the discounting engine the illusion that everything just came from the same place. We can get call records, credit card charge records—it doesn’t matter, as long as we can get the feeds that describe the services that were rendered, such as paging, phone calls, Internet usage over wireless. And they can all be in different formats.”

Convergent systems must employ and manipulate an array of data structures: wireless and wireline CDRs, Internet usage records, pricing plans, customer records, hierarchical records—all must be handled uniformly with their discount plans intact for each customer.

“The data integration foundation of our product pulls it all into memory so the discounting engine can operate on all these things,” Hoffman says. “What the software does is give the higher level of software—the discounting engine and the billing system—the illusion that everything is in just one monster database.”

Convergent systems need many fields

One difficulty with bundled and convergent systems is the number of data fields a billing system must contend with, he says. “One of the biggest characteristics in dealing with convergent services is that the data fields each service goes to is different. If somebody says, ‘I want you to bill for this service that has 28 fields and runs on Sybase and Unix and I want you to start doing some discounting,’ … we set up our data catalog to describe those 28 fields and bring it into our pricing engine. I’m not saying that solves the problem in its entirety. There’s more to it than just getting the information into the rating and discounting engine.”

Setting discounts on spreadsheet interface

ISoft uses a spreadsheet interface to manipulate its pricing rules, which Hoffman admits users at first may find a bit counterintuitive. But he predicts that once used to it, developers can easily create pricing plans and other financial programs: “You might have a tier discounting plan where some of the cells show the threshold for tiering, and the cells right next to them show the rates to apply based on those thresholds.”

The pricing plans are then saved in the back-end system in the form of internal scripting language which, Hoffman says, gets converted or parsed into code. “So when somebody cuts a bill and the calculation for their bill is based on a certain pricing rule, that pricing rule has been converted into code and commences to operate. Then it’s just operating with our back-office discounting and rating engine.”

ISoft’s system runs on several platforms, including Windows, Unix and MVs, and supports most major relational databases, Hoffman says.

Telution discounts using application suite

Telution LLC of Chicago created Communication Exchange, a group of component-based applications designed to create an infrastructure to tie together convergent services and manipulate the ordering, pricing and discounting of them. “We focus on integrated communications providers, those people who provide bundles of services, for providers of local and long distance, wireless, and data and Internet services,” Steffen says. “We’ve built this product architecture that sits at the bottom of the billing system and it helps us define the product, how to bundle it, how to price it, how to provision it, and how to collect configuration information on it. That’s the basis of our bundling and discounting strategy.”

Telution’s system first creates rules for each product individually, then bundles them together to create a pricing plan for that structure, allowing carriers to apply discounting at the product level or at the bundled level. “What we’ll do is come up with a bottom line number for local and for long distance with appropriate taxing, for cable, Internet. Then we’ll go back to the bundled level and find the appropriate discounting structure,” he says.

“For instance,” Steffen says, “we’ve got one company that has local, long distance, cable and Internet, and if you buy their local service, they’ll give you 15 percent off a comparable price of an ILEC; if you buy local and long distance, they’ll take 20 percent off your local; if you buy cable with the package, they’ll take 25 percent off your local usage. It’s a percentage off the local portion of the bill, not the entire bill.”

But it can single out services for discounts, too. “The way our rating engine is set up, it’s a ‘pluggable’ architecture. You can plug in different kinds of pricing plans and pricing schemes into it. You can plug in different rated event sources, so it can record minutes of long-distance usage, Internet bandwidth, cable, pay-per-view.”

Event data transformed

The data from those sources are then transformed from each service’s specific format into Telution’s internal, proprietary format and plugged into a set of discounting modules that let carriers set up discounting packages. “When we enter a new market like wireless, we’ll create an industry kit, a set of software components that plug into a platform that says, ‘These are the rated event sources I need. I need to be able to collect these rated events from the different mediation devices for wireless, or WAP, or digital media, whatever the next service is needed for a platform,’ ” Steffen says.

Telution also designed its system to operate under different database configurations. It uses cost components that can be broken up in different levels of scalability. “We’ve taken a unified information model—across customer care, billing and order management,” he says. “The customer care component is a good example. If I have a call center with 200 seats, I might have one set of application servers that’s going to a database. If I want to go and add another 200 seats to it, I can take another application server that will satisfy the requirements of the second 200. I can horizontally scale it—the application can go to a database, and the database itself can be replicated or partitioned or clustered.

“Partitioning and having these network pieces in between allows the customer to have three or four different rating engines. The applications may be doing all the same type of rating, or they may be doing different services. It’s the same thing with the collection and invoicing servers.”

On a lower scale, Steffen says, the rating,, invoicing, billing and collection engines can run on a laptop.

Amdocs goes for hardware configuration

Amdocs’ approach is to create a product catalog on a database apart from the database where the customer information is stored. “It’s a separate database that includes all the products of the company, and it includes different kinds of association rules between the products so you know what you have,” Baleli says. “For example, you have the basic products, and then on top of those products you create discount packages. A marketing offer might include one wireless service and one wireline phone to your home, in addition to one voice mail, which is shared by both. You need to define these three components separately, and then you have [to build] one offer where you associate it with one pricing plan. This is not difficult to do, providing … the system will be able later on to translate all of those rules in the product catalog and transfer them to the business logic within the software.” The product catalog database is integrated with the customer information residing on another database, so discount plans can be matched to each consumer.

Designed to avoid hard-coding

The Ensemble setup is designed to make it easy for CSRs to manage customer discounts for various services, Baleli contends. “How are you going to negotiate with your customer when he calls and wants to buy something? You need to have all of those rules somewhere. It should be part of your order catalog. Otherwise, whenever you want the marketing department to create a new service, you need to have somebody go in and fix the system and do some hard coding to support the new offering. You need to have a very sophisticated product catalog driving the applications, a system to take care of the different aspects of that product, including the [results of] the negotiations of the product suite.”

Amdocs’ approach contradicts the usual business practices of traditional RBOCs, Baleli says. “You have in many cases a vertical system to take care of one line of business, which means they have to have a separate system to handle a single phone line, a different system to take care of data services, and a system to take care of wireless services, and so on.”

Amdocs strives to create a single stream of data covering all service offerings. “When services are coming from different mediation [systems] with different networks, it’s one stream. It’s not separate lines of businesses,” Baleli says. Amdocs is now implementing its Ensemble billing system to let Rogers Cantel bundle wireless and paging services for cross-product discounting in the next few months.

Discounting requirements get tricky

Though billers are learning to bring sophisticated pricing schemes to customers, carriers that use those systems bump into even more sophisticated problems when applying business rules to large corporate accounts or across national footprints. And that old demon, multiple taxing jurisdictions, also weighs heavily on cross-product discounting efforts.

When it comes to large accounts, tracking which discount scheme is going where can be difficult. “If you move now to corporate accounts, then you make it much more complex,” Baleli says. “You may have multiple locations, different departments and pricing issues. Let’s say [the corporation] has one domestic office and one international office, and you’d like to have all of the calls to the international office being charged to the proper office, and the domestic calls sent to another. There are other issues, such as the recurring charges being charged to the head office and usage being charged to the different people in that office.”

Two views, different results

Another reason carriers get confused on where discounts apply: The network developers see at which offices the calls originate and terminate, and consider that the customer location. Meanwhile, the billing department sees the customer according to the billing address. The two often don’t match. So, which user, from which office, gets which discount?

“With discounts, you might have another hierarchy because of competition,” Baleli says. “You might have to give one discount on the West Coast and another discount on the East Coast, and you can be in contradiction with the billing hierarchy. One should not be in the position where they can only look in one billing hierarchy.”

Corporate accounts also muddy the waters when it comes to monitoring service level agreements, he says. “Let’s say you have a corporate account committed to buying a certain amount of services, and you are committed to give a certain amount in discounts. A carrier sometimes cannot really measure to see whether the customer has already met the appropriate commitment, but they give the discount anyway.”

“It’s too much when everything is going so fast, all the new services,” Baleli says. “Unless you have a good information system, it’s really tough.”

The human factor of cross-discounting

When it comes to accounts receivable, what if a customer pays only part of his bundled bill? How does that affect discounting?

“Partial payments tend to be a big deal. What you need are some rules—everything is rule-driven,” Hoffman says. “You need the rules to apply those payments to the different systems. And it gets dicey. You have to assign where the money goes to each bucket. The high-priority services suck up all the payments to the point they’re paid, or to the point where they’re sufficiently paid so you don’t cut off service.

“It’s the same with discounting. Let’s say you get a $150 discount: How does that money get mapped back to the different services, so that if you’re adding a layer on top of an existing vertical biller, how do you then keep them in sync? So, it’s allocation of moneys to different buckets,” he says.

Headache: Taxing cross-discounts

Ah, yes. You can’t forget the tax man, who still gets his due, even when a carrier gives away minutes.

Telecom services, included enhanced services, are taxed when sold separately, and that doesn’t change when they’re offered in a discounted package.

“When you start to offer them in a bundle, the challenge becomes having effective tax rates for things you do free in there,” Steffen says. “We have a carrier who’s doing local, long-distance and enhanced services. When you start to go through the billing of that, … you end up with the local piece taxed in a certain way, and long distance is taxed a specific way. There are different jurisdictions associated with long distance, and some of the enhanced services are taxed in different ways. If I give you 200 minutes of free long distance in this bundle I’m charging $50 for, how much of that [money] should be associated with that long distance? How much of it should be associated with the local portion of that bundle, and how much should be associated with the enhanced services portion of that bundle?”

The answer is rather simple. You have to tax the 200 minutes at the appropriate rate and give Caesar his due. But if the customer uses 210 minutes, “then you’ve got to take the 200 minutes and tax those at the effective tax rate and not show them on the bill, and take the extra 10 minutes and tax those accordingly and show them on the bill,” Steffen says.

Hoffman has another view. “Taxing is clearly an issue, because it may be you have to tax calls at the discounted rate, and that can be a back-and-forth process,” he says. “Let’s say you have a 10 percent discount across the board, and somebody has a 10-minute call that has to be rated. Maybe you want the vertical biller to rate it as a 9-minute call; then you run into a challenge, because you not only want to rate it, you want to tax it as a 9-minute call and then create a total based on that.

“So you want the enhancement layer to do the discounting first, and somehow indicate that the call is discounted in terms of minutes or whatever, and then have the existing vertical biller do the rate. I’m not saying that’s how you’d want to do it, it’s a complex case.”

Complex. Yes. In fact, it keeps the system hopping. “You get pretty much one of every kind of thing in taxing,” Hoffman says. “It’s going to put more pressure on the taxing modules. It might be easier to write your own code.”

Therefore, tax rates are an important component when carriers create discount programs; giving too good a price can cost the carrier in taxes and cut into the profit margin. So tax rates should be carefully figured into the discount offering so the carrier won’t lose money on its offering.

It’s going to get more complex

As billing and telecom professionals know, cross-product discounting is going to become more complex. Although many of the bundled services are usage-based, many components continue to be flat-rated, especially the Internet. Once IP detail records are standardized and IP data traffic is increasingly priced on volume, cross-product discounting engines will grow in complexity. And who knows what other kinds of enhanced services will pop up, like voice mail over the Internet, or just plain VoIP did in recent years. Will data traffic be billed in bytes, by transaction, or based on the content of a packet?

“There are other technologies still to mature,” says Amdocs’ Baleli.