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.