Customer Facing Services and the Granularity

 Product Management  Comments Off on Customer Facing Services and the Granularity
Jun 222010

According to TMForum, Customer Facing Service is a service that is represented as product offerings. This is quite explanatory. Another definition could be: Customer Facing Service (CFS) is any service that resides in the product/service catalog and interacts with the customer. A voice mail, site-to-site VPN, GSM voice, SMS etc. are all kinds of CFSs. The design of Customer Facing Services can be challenging. Inefficient designs may lead to other problems in business processes that manage these CFSs. Since our main goal is to reach to a more manageable, more automated and more flexible environment, our CFSs should be aligned with this strategy.

In this article, I will try to focus on the granularity (level of detail) of the CFSs. How granular our CFSs should be? This depends but if you want to implement “everything as a service” concept in your product/service design, you should have “very” granular services. When creating the most granular service, we should ask ourselves, “is this the least detailed sellable unit?” and “can I bind this, as standalone, to a product and bill separately?” Please note that, CFSs can be combined with other CFSs under one Product; there is no one-to-one relationship.

Ok. Let’s work on some examples now. Granular services concepts can be applied to datacenters. I have been in the design of such datacenter and two of the services we have worked were Bandwidth and Power. (Off course there were dozens of others but this two will be enough to explain the concept.)
Are these sellable and perceived by the customer? Do they, individually, represent the least detailed sellable unit? Yes. So, they are granular CFS candidates. What we can do next is to bundle these two CFSs under a Product Specification and offer it to the Market under different Product Offerings. Please note that, I still have the option to put one of these services under a different Product Specification and sell as standalone. The power of granularity comes into scene in here. Your Product Management and Marketing groups will have the option to create lots of combinations of these services to be offered which will increase our competitiveness.

The granular CFS should be sellable as standalone but this does not mean that you must sell them. For example, Power could be sold separately, but does it make sense for a datacenter? No. In theory, it could be sold but in real life you must bundle it with other granular services such as bandwidth, security, maintenance etc. and the best place to bundle related services could be the Product level. (You can also do this on the product offering level but that’s not the topic of today)

Suppose, our service provider does not have any intention to sell these services separately and launches one service named Co-Location Service. This co-location service has a monthly rate. Over bandwidth and power usages are rated and applied to the same service. Co-Location service is sold under the Co-Location Product. This is also a valid scenario but it increases complexity and decreases flexibility. Rather going this way, we could have 2 CFSs under the Co-Location Product.

Another example could be GSM Voice Call. Voice call is a granular CFS. I have seen some examples on the web saying that “receiving a voice call” is a CFS. I don’t think so. Voice call is a granular CFS which has attributes (is call receiving active, Suspended, Roaming Activated etc.) These attributes are not sellable as standalone. If they were, if you were subscribing for receiving calls, this would be a CFS but I have not seen any service like this. In the roaming scenarios for example, receiving calls are also billed. But, this is not a service that the customer buys! This is a separate rating scheme that is applied to the service under this specific condition. As I said before, the service attributes would be bind to one/more update flows (service activation flows). These flows (or operations you could say) could be exposed as different web services (but not different CFSs).

Choosing the granular services will also help you to decrease your troubleshooting time. We said that CFSs are the services that are “perceived” by the customer. But this perception is heavily impacted by your service design. Let me explain this. Suppose I am selling a product called Co-location, and in my product specification I am also saying that this product is composed of one service which is Co-Location. Whenever the customer perceives any problem, he/she will blame the co-location service, since this is the only service he/she is receiving. He/she will create a trouble ticket for this outage giving the detail “I am having a problem with my co-location service”. This is not very informative. Most of the times, it will be the service provider’s job to localize the problem. However, if the service was designed as two separate CFSs (bandwidth and power) rather than one, the customer “may” come and open a ticket on the bandwidth service with the detail “I am having packet loss problem on my line”. Your MTTRs will definitely fall.

Choosing the granular approach in your service design will bring flexibility. The service activation flows will be more manageable and troubleshooting will be easier. Choosing the CFS details is not the only task but it is a starting point before we move to the Product design area.

Jun 092010

Prepaid Billing systems, (which can also be called charging systems in day-to-day talks), run the billing process for the prepaid customer accounts.

They heavily use the online charging mechanism rather than offline charging that we typically see in the postpaid billing systems. Online charging systems rate the usage on-the-fly and charge the user account immediately.

Prepaid billing environment is composed of several different systems. And the most important one is the charging system. Prepaid Charging systems are integrated with the switches (MSC, PSTN), SMSC, MMSC, GGSN, Interconnect and other VAS applications. Those service infrastructure equipments are configured to ask an authorization from the charging manager before proceeding to give a service.

Charging systems communicate with (or employs) several other systems to charge the customer usage. One of them is the rating system which calculates the cost of the usage. Rating systems maintain the tariffs, discounts and campaign related information.

Charging systems ask rating systems the cost (in terms of dollars, credits etc) of the usage (volume, time or event based) and then try to apply it to the customer account balance. They do this by communicating with a balance manager. Balance manager systems manage the customer account balance.

There are 2 mechanisms that charging managers use in order to debit from the account balance:

First mechanism is the “direct debit” mechanism. In this approach, balance manager directly debits a pre-defined amount. For example, a debit is applied each 30 seconds (For those 30 seconds.) If you terminate the session at 25th second, the remaining 5 seconds are rated and refunded back to the account.

The second mechanism is the “unit reservation” mechanism. Here, rather directly debiting from the account, you reserve some of the balance. When the call is complete (or SMS, MMS has reached it destination) the reserved amount is committed.

Voucher management is also an important function that needs to be mentioned about. Voucher managers manage the lifecycle of the voucher that are used to credit the customer account balances. Therefore, voucher managers have a direct interface with the balance managers. (and possibly with other systems such as CRM, Fraud managers etc.)

Charging platforms also employ IVR functionalities. These are usefull to inform the user about the current balance, crediting the balance and notifying the user before any call drop due to insufficient balance.

(If the charging system cannot do the charging, due to some reasons, it outputs a CDR file including the session details. This CDR is post processed and applied to the account balance.)

Charging manager, balance manager, rating manager, voucher management and IVR can be sold separately or combined in a single “prepaid billing” platform.

Operators around the world started consolidating their prepaid and postpaid billing platforms. This is called convergent billing. This approach reduces the complexities, license/hardware costs and operational expenses. I’ll try to comment on convergent billing in another post.