Seamless Service Activation

Enhance customer experience with robust provisioning

A customer makes the decision to sign up for a new service; the customer then expects the service to be available. They pay; they receive the service. It seems a clear concept, yet it does not always happen so simply. Operators are still having problems with service activation and this impacts customer experience.

In this digital era, with any service a customer purchases, it is considered to be unacceptable to pay for a service then experience a delay in receiving it. Or it not being authorised when you know the payment card being used is valid and in credit. Or perhaps even the system goes down…’we are not able to process your request at this time’. These are all frustrations for the customer.

This does two things. Annoys the customer, blemishing the company image. And deters them from buying the service, which means missed revenue. Repeat occurrences could have long-term impact on the subscriber base, as some move to competitors for a better service.

Activation of services in a timely and efficient manner for customers is essential for any operator providing subscription-based TV. 

So what are the essentials when looking for a provisioning solution?

1. High performance - you need to be assured that whether your solution is being utilised for hundreds, thousands, or millions of subscribers, it does the job regardless of numbers.
2. Content protection - a small percentage of the consumer market prefer to avoid paying for TV content. Securing authorised access to content is critical to protect revenues and ensure continuity of service to paying customers.
3. Interoperability - working alongside existing systems to ensure seamless, fast and reliable delivery of services.

Delivery of services does not only build revenues for operators, it can ensure a customer stays loyal. The experience is just as critical at this stage as when customers first signed up. Ensuring activation of services is streamlined with a robust and powerful service activation solution will help operators build customer satisfaction.

This blog was written by Natasha Geldard, Marketing, CoralTree

Real Time Convergent Charging and Policy Management are a necessity!

Real Time Convergent Charging (RTCC) and Policy Management go hand in hand, with 95% of the CSP’s that responded to TM Forum’s recent Insights Research paper ‘RTCC and Policy Management’ [Link] saying that they cannot remain competitive without implementing it in some form.

The benefits of introducing RTCC can be great for the CSPs for a whole number of reasons such as improving customer experience, minimising or negate bill shock and providing a means to monetise the OTT market.

As customer experience quickly becomes the critical focus for operators, RTCC and policy management will allow operators to be much more creative and agile in how they interact with the customer and a lot quicker in the introducing new services and products

Bad Profits

Currently the two largest uses for RTCC and Policy Management are bill shock management and threshold management, which are great, but - even now - there are companies who use them in rather blunt ways. Capping or throttling customers who reach data caps, or charging ‘premium’ prices for going over limits. This creates ‘bad profits’ and does nothing to enhance the customer experience.

However some CSP’s have the idea, using these tools to build a bond with the customer and ultimately using it to drive revenue growth. When customers get close to limits they are warned they're close, and offered ‘extensions’ to their data or broadband usage for a set price, repeat ‘offenders’ can be marked for upsell opportunities offering them a better package at a higher price, but one that would be cheaper than the charges they would otherwise incur.

In the short term, this doesn't drive as much revenue as the charges, but, as should be obvious, a loyal customer is more profitable than a customer who leaves because they feel they've been ripped off.

As the marriage between RTCC and Policy Management becomes more complete (94% will implemented a RTCC & PM strategy within two years and 64% within the next year) operators and CSP’s will be able to produce more innovative offerings to their customers.

This will enable them to increase revenue through USPs – introducing flexible services that the customer can control such as Holiday mode, sharing data, moving portions of broadband download limits onto mobiles – especially as networks move towards 4G LTE. And on the topic of LTE, Policy management and RTCC will be necessary for the introduction of VoLTE to ensure bandwidth is properly managed.

Over The Top

Lots has been made of the need to monetize the OTT trend, and with a RTCC and Policy Management, CSP’s and operators can. 

A good number of them are offering free data when using apps like WhatsApp and Facebook, others are offering Netflix or sports services when they sign up (Virgin Media, Vodafone) whilst others are competing directly with their own offering (Sky’s NowTV, UPC’s Horizon) Policy management and RTCC is vital in letting operators omit these services from customer’s data use. 

The nature of the relationship with OTT players is only really beginning to be explored, but it can be as simple as free data, it could be as one Indian MSO does, offering bundles of access to YouTube, Facebook and other OTT services instead of, or in line with data allowances.

Or CSP’s could really be involved with developing the relationship, making it a truly two way relationship that benefits both, working with Google’s Project Loon or Facebook's Internet.org to bring internet (and telecoms) to remote places with the knowledge, infrastructure and software they already have in abundance. OTT’s get more customers, CSP’s get more customers.

However the future unfolds, one thing appears to be a common theme throughout it all, the need for Real Time Convergent Charging and Policy Management, preferably together, to drive new revenue growth. 


This article was written by Craig Maxwell-Brown. Business Development Associate for CoralTree Systems Limited. Views are not necessarily the companies views.

Do we understand the meaning of convergence?

The communications industry is rife with vendors promoting their convergent systems. Technology aligned, all working smoothly, hand in hand. But is this so commonly used word, convergent, merely a buzzword?

Converge is defined as to ‘come together from different directions so as eventually meet.’ So do the systems that are implement into communications providers operations really converge with the existing systems in place? Or is the truth that they simply run in parallel?

I don’t think we should trivialise the importance of convergence here. Creating the competitive differentiation that a converged system allows is in every operator’s best interest. Convergence enables a joined up approach to customer service, more efficient call handling, and minimising billing and order errors.

But very few operators’ systems are really convergent. Many are ‘window dressed’. New systems on top of old, trying to disguise the disorganisation underneath. But the systems only work in parallel and are not often integrated. This can be beneficial in the short-term and helps speed up processes, but as more technologies and services are added complications will become apparent.

The long-term objective should be to converge all BSS systems. This will limit the support needs and issues faced by IT teams, as well as providing a wealth of knowledge to marketing and customer support teams, so service can be enhanced.

Systems must ‘come together from different directions so as eventually meet’ in order to stay competitive in this dynamic communications industry.

To read more about operator convergent strategy, read CoralTree’s latest Insight report: “Convergent strategy or conflicting goals?” by visiting our website: www.coraltreesystems.com/insights-papers

This blog was written by Natasha Geldard, Head of Marketing, CoralTree

CTO vs. CFO – focusing on company prosperity

The goals of the communications providers’ CTO and CFO are driving further apart. Both are committed to do what’s best for long-term business prosperity, but their strategies are far from converged.

In this face-paced sector communications operators have to innovate, to offer the latest services and packages to customers, in order to stay competitive. The CTO is under constant pressure from the business to ensure that the systems are in place for dynamic packages to be marketed, fulfilled, and billed. With many BSS systems dated, this requires investment to upgrade to next generation support systems.

In contrast, the CFO focuses on ensuring profitability and demands in fiscal year returns for any large investments made. The CFO role is to demonstrate to owners, shareholders, or the market, that the business is doing well. In simple terms, growing and making more money than it is spending.

Yet some CFOs are acknowledging this strategic problem. Industry news title, Global Telecoms Business published in an article that interviewed top global telecommunications CFOs in February 2014. Tom Fitzpatrick, CFO of satellite operator Iridium, was quoted saying: “The short-term earnings bias of Wall Street in the evaluation of results proves difficult in that many compelling long-term initiatives are not undertaken in the face of this short-term bias.”.

Many BSS out-of-date

The issue is that many BSS systems in place are so dated that they are unable to cope with next generation technologies and services. Quick fixes will not last for long and will not be able to keep up with the fast pace of change. In the long run, this will cost the operator more money than upfront investment in a long-term solution.

To stay competitive, it is crucial for the CTO and CFO strategies to be converged. Alignment must be made to support the business with advanced IT, creating long-term efficiency and cost-savings.

To read more about operator convergent strategy, read CoralTree’s latest Insight report: “Convergent strategy or conflicting goals?” by visiting our website: www.coraltreesystems.com/insights-papers

This blog was written by Natasha Geldard, Head of Marketing, CoralTree

Big (Little) Data and Customer Experience - CEM Blog Part Four

It has been a little while since the last blog article on Customer Experience Management, so if you're in need of a quick refresher then please follow these links

Part One: Putting yourself in the customers shoes
Part Two: Customer experience and the call centre
Part Three: Going Social

All clued up? excellent.

Big data is proving to be a very important and ever growing part of a business. The ability to collect more and more data from an increasing range of sources provides some very potent opportunities for business. However for businesses to really achieve that ‘write home about’ customer experience, you need ‘little data’.

Big data, better operations

Now, by its very nature, big data gives an extremely broad look at all our customers and what they're up to. It allows us to spot trends in customer behaviour and habits as a whole – both good and bad. CSPs can use this to great advantage, identifying behaviour patterns, trends and pain points for customers and work out solutions that build customer advocacy.

Let us use an example to make it more realistic. An increasing number of people are using OTT services like Netflix and Lovefilm. Not only are more of your customers using them, but they're using them more frequently and these data heavy services can impact the network.

Rob Rich, MD of Insights at TM Forum, says the operators are “using network and customer data to learn the habits of their most valuable customers.” They are using network data to determine where the most strain is being put on the network, so “by comparing the two, they can drive support for future network investments that will improve network performance and boost customer satisfaction.” [source]

This is a perfect example of what big data can do. By looking at the whole picture, companies can find patterns, trends and pain points across a wide section of customers, which can only ever be a good thing.

So what about small data? 

Small data is where unique gains can be made that boosts customer experience and satisfaction. Little data lets us spot opportunities and enables personalised customer interactions. It can be achieved with the data that a CSR should be able to readily access via their CRM.

The key is how easy it is for a customer service agent to access that information and how closely it is linked a 360 degree view of the customer. The customer service agent must be able to view recent customer interactions and all information needs to be clearly accessible, quickly.

Imagine a scenario where you don't have to re-tell the story you've already told to several people because the customer service agent already knows that last week your phone line conked out. The engineer was meant to turn up this morning, but canceled, and that no one has yet replied to your question via social media. It would be blissful, wouldn't it?

Or maybe recognising that a customer is routinely hitting data or download limits. Or that they've been late payers recently, but offering solutions, such as putting a hold on premium services, would be beneficial for the customer for a few months.

All these 'above and beyond' measures build customer loyalty. We know that loyal customers are worth up to 10x their first purchase. [source]

Companies have some, if not all this information available to them already. They have done for a long time. The key to Little Data is making sure you take advantage of it!

Big data and little data are both important strategic considerations for service providers. Ensure the network is performing to its optimum ability and build customer loyalty. Data, big or small, is the gold to each operators armour.

CoralTree’s off to TM Forum Live! – What do we expect?

In just two weeks time we'll be setting up in Nice for TM Forum Live! 2014. Anticipation builds, as it is the first time for CoralTree at TM Forum Live! In fact, the first time we have had a ‘proper’ stand at an exhibition. So what do we expect…?

Renowned for its sharing of best practice, networking and attracting some of the leading operators, I have high hopes for some interesting conversations. The conference agenda itself looks exciting. I am particularly looking forward to the revenue management focus on Thursday.

‘Better, faster, cheaper: How BSS/OSS consolidation can accelerate time to market, reduce costs and maximize revenue’ caught my eye. In my opinion BSS has to move with the times. With new technologies and services needing support from the BSS function, it is essential that next generation systems be adopted.

Convergence of billing and customer care systems into simple workflows is key to ensuring satisfied, loyal customers and agents. Come and see us on booth 52, to see how daVinci enables exactly that.

You can even have a beer with us whilst we discuss. And remember not to miss the ‘happy hour’ on Tuesday, 17:30-19:00 in the expo!

Better go and pack…see you in Nice!

Natasha Geldard

Marketing Consultant for CoralTree Systems ltd.

Creating Java Web Services Using JAX-WS, JAXB and Spring

I've recently been working a lot with Java web services, most of these were greenfield projects where we were able to choose the architecture. I decided to use JAX-WS to create the web services but was unsure initially of the best way to go about this. In general there are two approaches to writing web services (contract first or code first).

Contract first
Contract first requires a wsdl to be written first and then JAX-WS can be used to generate matching code. This approach has its place if you already have a wsdl but they're not the easiest of things to work with and maintenance quickly becomes messy.

Code first
Code first is much easier as you simply write the code using a handful of basic annotations and let JAX-WS generate the wsdl for you at run time. The downside to this approach is that you have to write the code before you have a wsdl or schema available. This may not be an issue but if you need to write a specification first then it's handy to have some kind of schema to define how the inputs and outputs are going to look.

Also, in some cases you may be able to express more in a schema than you can with just Java code. For instance you might want to set a restriction in the schema (like a string max length), or perhaps you want a particular nested structure of elements. You could do this yourself with JAXB annotations but it's easier to write a schema and generate the required classes.

Combined approach using JAXB
I asked this as a question on stackoverflow and one of the answers provided inspiration for a kind of best of both worlds approach. This has now been implemented for several different projects and overall it's been a pleasure to work with. The basic idea is that development follow something like the following process.

• Write a basic schema that defines the request and response types (this can be included in specifications and is easier to maintain than a full wsdl)
• Use JAXB/XJC to generate the request and response types
• Write a JAX-WS endpoint using the generated types as inputs and outputs
• Let JAX-WS generate the full wsdl at runtime

Spring integration
In addition to this I wanted to use spring for managing services, dependency injection and loading properties files. This requires setting up JAX-WS slightly differently so that spring can load the endpoints and inject dependencies. If you don't do this then you'll end up with a JAX-WS version of the endpoint with none of its dependencies injected while spring will have its own instance complete with injected dependencies but not handling any requests.

Maven build and dependencies
I'm using maven to manage the build and dependencies. You don't have to use maven but it really does make life much easier. These are the required dependencies you'll need in your pom.xml file.

<dependency>
         <groupId>com.sun.xml.ws</groupId>
         <artifactId>jaxws-rt</artifactId>
         <version>2.2.7</version>
       </dependency>

       <!-- Spring DI -->
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-core</artifactId>
            <version>${spring-version}</version>
            <exclusions>
            <exclusion>
             <groupId>commons-logging</groupId>
             <artifactId>commons-logging</artifactId>
            </exclusion>
         </exclusions>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-context</artifactId>
            <version>${spring-version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-beans</artifactId>
            <version>${spring-version}</version>
        </dependency>
        <dependency>
            <groupId>org.springframework</groupId>
            <artifactId>spring-web</artifactId>
            <version>${spring-version}</version>
        </dependency>

        <!-- JAX-WS/Spring integration -->
       <dependency>
   <groupId>org.jvnet.jax-ws-commons.spring</groupId>
   <artifactId>jaxws-spring</artifactId>
   <version>1.8</version>
            <exclusions>
            <exclusion>
             <groupId>org.springframework</groupId>
             <artifactId>spring</artifactId>
            </exclusion>
         </exclusions>
  </dependency>

In the build section of the pom you'll also need to configure the JAXB plugin to auto-generate code from your schemas. The way it's setup here it will look for any schema in the directory /src/main/resources/xsd and then generate code and put it in a source folder called /target/generated-sources/src/main/java. If you're using eclipse you'll want to right click this folder and take the option Build path > Use as source folder. If you don't do this you'll still be able to run a build using maven but you'll probably see compile errors in eclipse.

<build>
        <plugins>
            <!-- Generate JAXB Java source files from an XSD file -->
            <plugin>
             <groupId>org.codehaus.mojo</groupId>
                <artifactId>jaxb2-maven-plugin</artifactId>
                <version>1.5</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>xjc</goal>
                        </goals>
                    </execution>
                </executions>
                <configuration>
                    <!-- Don't set package name here as we want different packages for each schema.
                         Instead we set in each schema separately. -->
                    <!-- <packageName></packageName>  -->
                    <outputDirectory>${basedir}/target/generated-sources/src/main/java</outputDirectory>
                    <schemaDirectory>${basedir}/src/main/resources/xsd</schemaDirectory>
                </configuration>
            </plugin>
        </plugins>
  </build>

Web app config files
Next we need to add some configuration files to setup our web application. First is the web.xml deployment descriptor. Here we define the standard spring listener to load our spring configuration and we also setup a servlet to listen for our web service requests. Rather than use the JAX-WS servlet we've used a spring wrapper which will later allow us to use dependency injection in our endpoint classes.

<?xml version="1.0" encoding="UTF-8"?>
<web-app version="2.5" xmlns="http://java.sun.com/xml/ns/javaee"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd">

  <display-name>TestServices</display-name>

  <!-- Load spring configuration -->
  <context-param>
 <param-name>contextConfigLocation</param-name>
 <param-value>/WEB-INF/application-context.xml</param-value>
  </context-param>
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
  </listener>

  <!-- Servlet to handle all jax-ws requests -->
  <servlet>
    <servlet-name>jaxws-servlet</servlet-name>
    <servlet-class>com.sun.xml.ws.transport.http.servlet.WSSpringServlet</servlet-class>
    <load-on-startup>1</load-on-startup>
  </servlet>

  <servlet-mapping>
    <servlet-name>jaxws-servlet</servlet-name>
    <url-pattern>/service/*</url-pattern>
  </servlet-mapping>

  <!-- There didn't ought to be any sessions created but it's good practice to define a
  timeout as it varies for different containers. -->
  <session-config>
    <session-timeout>40</session-timeout>
  </session-config>

</web-app>

The spring config is minimal in this basic example. It's just turning on classpath scanning for the package in our test project and enabling auto-wiring of scanned dependencies. We also need to setup which urls map to which endpoint classes but this has been moved to a separate file which we import at the bottom.

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="http://www.springframework.org/schema/beans
       http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
       http://www.springframework.org/schema/context
       http://www.springframework.org/schema/context/spring-context-3.2.xsd
       " >

    <context:component-scan base-package="com.testservices"/>
    <context:annotation-config/>

  <!-- Define the jaxws endpoint -->
  <import resource="jaxws-context.xml"/>

</beans>

Usually with JAX-WS you need a config file called sun-jaxws.xml where you define which urls map to which endpoints. In this case we're using a spring JAX-WS servlet so instead we add our mappings here. This simple mapping is saying all web service requests to /service/test1 will go to the spring bean with an ID of test1Services. We shall see this bean shortly.

<?xml version="1.0" encoding="UTF-8"?>
<beans  xmlns="http://www.springframework.org/schema/beans"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xmlns:ws="http://jax-ws.dev.java.net/spring/core"
  xmlns:wss="http://jax-ws.dev.java.net/spring/servlet"
  xsi:schemaLocation="http://www.springframework.org/schema/beans
   http://www.springframework.org/schema/beans/spring-beans-3.2.xsd
   http://jax-ws.dev.java.net/spring/core
   http://jax-ws.dev.java.net/spring/core.xsd
   http://jax-ws.dev.java.net/spring/servlet
   http://jax-ws.dev.java.net/spring/servlet.xsd">  

  <!-- Define our jaxws endpoint (replaces sun-jaxws.xml) -->
    <wss:binding url="/service/test1">
        <wss:service>
            <ws:service bean="#test1Services" />
        </wss:service>
    </wss:binding>   

</beans>

Schema to define request/response types
In this simple example we could get away with one simple schema but in a real world example you'll probably end up with many. The way I've been organizing this is to have a base shared schema which defines common types. For example you might want all requests to include a username, password and environment and maybe the response should always have a boolean element to indicate success. Then you can write a schema for each endpoint defining the request and response types for all operations on that wsdl.

Here is the example base schema shared.xsd.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
   jaxb:version="2.0"
   targetNamespace="http://shared.testservices.com/"
   xmlns:tns="http://shared.testservices.com/"
   elementFormDefault="qualified">

  <!-- Settings for the JAXB code generation -->
  <xs:annotation>
    <xs:appinfo>
      <!-- Set the package name for the generated classes -->
      <jaxb:schemaBindings>
        <jaxb:package name="com.testservices.generated.shared" />
      </jaxb:schemaBindings>
    </xs:appinfo>
  </xs:annotation>   

  <!-- Begin Types/Classes to be generated -->
  <xs:group name="baseRequest">
    <xs:sequence>
      <xs:element name="user" type="xs:string"/>
      <xs:element name="apikey" type="xs:string"/>
    </xs:sequence>
  </xs:group>    

  <xs:group name="baseResponse">
    <xs:sequence>
      <xs:element name="success" type="xs:boolean"/>
    </xs:sequence>
  </xs:group>   

</xs:schema>

This schema then imports the shared types and defines a simple request and response type for our example web service. Note that we can define which package the generated code belongs to by using the jaxb namespace extensions. There are a number of other customizations you can do like mapping xml types to Java types.

<?xml version="1.0" encoding="UTF-8"?>
<xs:schema  xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:sh="http://shared.testservices.com/"
   xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
   jaxb:version="2.0"
   targetNamespace="http://test1.testservices.com/"
   xmlns:tns="http://test1.testservices.com/"
   elementFormDefault="qualified">

  <!-- Settings for the JAXB code generation -->
  <xs:annotation>
    <xs:appinfo>
      <!-- Set the package name for the generated classes -->
      <jaxb:schemaBindings>
        <jaxb:package name="com.testservices.generated.test1" />
      </jaxb:schemaBindings>
    </xs:appinfo>
  </xs:annotation>

  <xs:import namespace="http://shared.testservices.com/" schemaLocation="shared.xsd" />

  <xs:complexType name="test1Request">
    <xs:sequence>
      <xs:group ref="sh:baseRequest"/>
      <xs:element name="id" type="xs:int" />
    </xs:sequence>
  </xs:complexType>

  <xs:complexType name="test1Response">
    <xs:sequence>
      <xs:group ref="sh:baseResponse"/>
      <xs:element name="field1" type="xs:string" />
      <xs:element name="field2" type="xs:string" />
    </xs:sequence>
  </xs:complexType>

</xs:schema>

Finally add the endpoint interface/class
Having saved those schemas there should now be a generated class called Test1Request and another called Test1Response. We're now ready to start piecing things together. The final stage is to define the JAX-WS handler and add a web method that uses these classes as inputs and outputs.

@WebService
public interface Test1
{
 Test1Response test1(Test1Request request);
}

So we have a very simple interface which we annotate with the JAX-WS @WebService annotation. There is one method which uses our generated classes. When this code is deployed JAX-WS will do the legwork and generate the WSDL with this one method on it. We just need to implement this interface now.

@Component("test1Services")
@WebService(endpointInterface = "com.testservices.endpoint.Test1")
public class Test1Impl implements Test1
{

 ObjectFactory fact = new ObjectFactory();

 @Override
 public Test1Response test1(Test1Request request)
 {
  System.out.println("User: " + request.getUser());
  System.out.println("ID: " + request.getId());

  Test1Response response = fact.createTest1Response();

  response.setSuccess(true);
  response.setField1("Value 1");
  response.setField2("Value 2");

  return response;
 }

}

The implementation uses the JAXB object factory, which was generated for us, to create a response object. We then hardcode some values just to see if it works. In practice you'll be able to inject a spring service here and go off and do whatever business logic is required. The class has been annotated as a spring component called test1Services. It's important that this matches the bean name given in the spring config file for JAX-WS. The @WebService annotation names the interface that we've implemented.

You should now be able to fire up your test server and see this running. If you go to http://localhost:PORT/ProjectName/service/test1 you should see a page confirming the web service has been deployed with a link to the wsdl (just append ?wsdl).

Ben Thurley,
Senior Software Engineer at CoralTree Systems Ltd 

You can view Ben's wordpress blog, with more articles, here

Ben has worked for CoralTree for over 5 years. In that time, his expertise and knowledge in new coding techniques and methods have helped us develop even better solutions for our customers.

The views expressed in this article are not necessarily the views of CoralTree Systems Ltd.