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.

Spitting in the Soup: Part Two - On the hook.

Spitting in the Soup - part 2 - On the Hook

As a small boy, growing up in rural Nottinghamshire, a highlight of my week would be a trip to the local newsagents to buy another six-penny pack of American Civil War cards. Each wax-papered pack would contain about five random cards from a series of maybe 200 in total, plus a nominal one inch square of bright pink bubble gum. 

Amongst our gang of local village boys, by far the most treasured card was one depicting a poor Confederate soldier helplessly impaled through his torso on a huge angled wooden stake. He had a ghastly agonised expression on his face and blood seeping from an enormous chest wound. By any standards it was a horrific sight, unless of course you were aged seven. Nowadays, I often think back to that picture when I encounter those CIOs of telecom operators who are struggling to come to terms with their own uncomfortable predicaments. Not so much "on the hook" as "on the spike".

To understand the CIO's predicament, I should explain that a telecom BSS solution plays a similar role within a large telecoms organisation to that of the vital organs in the human body - say the heart, liver, and lungs. So, unfortunately when dealing with some vendors, once that BSS solution has been installed and implemented (of itself a major challenge), the operator is effectively "on the hook" to that BSS vendor, and as helpless as that poor Confederate soldier. Up until final implementation and cut-over from any previous system, there may still be a small window of opportunity to escape from the vendor's clutches (see Spitting in the Soup part 1). 

Painful but true

Once the new system has "gone live", and the project celebration party bunting has been taken down, the operator gradually becomes aware of some pretty unsettling home truths:

• The vendor's A team, whose experience and skills were so valuable during the implementation project will gradually drift away to other higher priority (for the vendor) projects/clients, being replaced by inexperienced youngsters, whose industry training the operator seems to be unwittingly paying for.

• The exciting vendor strategic road-map that was so key in convincing the sceptics on the system selection committee to originally choose that particular path from the various available options, drops from sight as though it had never actually existed. Any attempt to engage the vendor in a discussion about it is met with either a blank expression or hysterical laughter.

• As the operator introduces new products and lines of business with corresponding new system requirements, the cost of such incremental system changes goes through the roof, and software is delivered late and with numerous bugs. Support levels deteriorate continuously. There is no other source for the software changes or software support, so the operator has literally nowhere to go. 

• The vendor acquires another BSS business, and announces that the newly acquired company's application software will form the centre-piece of its exciting (for them maybe) new roadmap. The solution that the operator has just spent millions implementing is effectively relegated to legacy status with massively reduced R&D funding.

Sadly for our industry, these kind of post-implementation disappointments have become the rule rather than the exception in recent years. In most "normal" economic market models, vendors delivering poor levels of software, service, and value for money would quickly be driven out and replaced by vendors with better offerings. 

We don't have much choice with who we pick... 

Unfortunately, in the BSS market two powerful forces combine to create a stifling inertia that prevents the development of an efficient market. Firstly there are the enormous barriers to entry that face potential entrants into the BSS industry. BSS applications have increased massively in their complexity as operators have launched new lines of business, with so-called triple-play and quad-play operators now offering complex bundles of telecoms services. 

The expertise required to design and develop such applications is such that there are probably no more than a handful of businesses worldwide attempting to create new applications for the industry, despite analysts estimating the annual market size as being in excess of 15 billion dollars. (Gartner 2011 IRCM Magic Quadrant)    

Secondly, the costs of switching BSS solution are so high, and the negative business impact of switching so great - requiring the business to freeze itself for a year or more, that operators generally have little option, but to grin and bear it.  

So what is our disillusioned and disappointed CIO to do in such circumstances? The real secret of survival for CIOs is to ensure that such scenarios simply do not arise in the first place, with the key issue being that of vendor selection. In fact I would go so far as to say the secret of success here is in not just finding the right vendor, but in finding a vendor with the right people. Ultimately it is the vendor's service delivery team that you will be hugely reliant on, not their corporate image, stock exchange listing, plush executive offices, or extravagant entertaining.

So what is a CIO to do?

So to finish, here are a couple of free tips for anyone thinking of entering the minefield that is buying a new BSS:

Make sure that you meet the vendor staff who will be responsible for implementing your system. Get hold of their CVs and get references from their previous client projects. Make a careful note of their names (the good ones), and ensure that the project staffing list forms part of your implementation contract. Make this a show-stopping contractual point, and do NOT back down.

Negotiate tough, but fair service levels that are clear and measurable. Insist on contract terms that will require the vendor to meet the estimated cost of you having to replace their system in the event that service levels are repeatedly breached, or as an alternative, that will trigger the automatic release of the application source code from escrow. You don't really want to have to exercise either of these options, but they should both help to keep the vendor in line. 

In my next article, I will explore why "small IS beautiful" as far as BSS vendors is concerned, and why there are so few of us around.

Cable Congress Q&A with one of the Sales and Marketing team.

Last week (11 - 13 March) CoralTree started its exhibition season with Cable Congress in Amsterdam. It is actually, the first time we have ever had an exhibition stand and it proved a very informative look into the industry. 

Our 'Pod'.

As it was our first time at Cable Congress and first shot at exhibiting, we thought we'd get a rundown of events, as well as some thoughts on the topics raised in the conference from a member of our Sales and Marketing Team, Craig Maxwell-Brown.

Q: Craig, seamless customer service was high on the agenda at the show, what do you think this means for operators and customers alike? 


Craig: It means that the customer has a consistent service with one operator, no matter what device or service they are using. For example, they watch TV on their mobile using their wifi, but carry on watching that show, with the same provider, when they leave the house, using their LTE service. 

For the customer all their needs are provided in a simple way and billed for by one provider. For the operator it provides greater customer stickiness and increased take-up of new services. This all helps to increase ARPU at a time when the industry is seeing it strained. In order to successfully monetise, operators must ensure they have the systems that can provide tailored and unique offerings.

Q: One of the key issues raised at the show was the need for cable operators to expand into mobile. What were highlighted as the main challenges for this transition?


Craig: Well, this was a very vocalised point at this year's conference. It very much links back to the previous point about providing customers with that seamless service. It is a must for operators, so they can remain competitive as the lines between telecommunications and cable becomes more blurred, but moving into this space certainly has its challenges.

A key IT consideration is the ability of their BSS systems to handle the complexities that mobile offerings bring. But investment is crucial. Providing quad-play bundles and packages will be vital for operators to differentiate themselves and to retain customers as telecomms operators look to compete in the video market.

Q: Are there any other topics/talks that really stood out for you at the show?

Craig: There was an excellent talk by Jordan Casey, a 14 year-old Irish lad who is running two companies. He has a great attitude towards work, and his studies, and it was inspiring to hear the unique challenges that he faces as a young entrepreneur.

Q: How would you summarise Cable Congress for both you and CoralTree?

Craig: It was useful insight for CoralTree. The issues raised in the conference confirmed that our development spend into our BSS portfolio daVinci is correct and will also help to shape where we focus our efforts on in the future. We were pleased to confirm that we have a competitive solution that can help operators combat issues and take advantage of market opportunities.

Q: Finally, a more light hearted question - what are your thoughts on Amsterdam as a city and a venue?

Craig: bikes, bikes, and more bikes! Amsterdam is a fantastic city, with great beer and that brilliant continental atmosphere - which really finds its way into the show. I'd have no qualms about going back there again!



CoralTree's next show will be TM Forum Live in June 2014. You can read more about CoralTree and CoralTree's daVinci BSS here: http://www.coraltreesystems.com/products