May 2010

"There is a way to do it better. Find it."

Thomas Edison

Companies are always trying to differentiate themselves from the rest of the pack by applying different strategies such as improving customer service, increasing the efficiency of their operations, or reducing their costs. Most of the time, however, these goals are competing against each other for scarce resources, and managers often need to decide to concentrate on one. A small company can effectively and simultaneously accomplish these goals for a fraction of the cost by implementing communications enabled business processes or solutions, which are a set of technology components that add real-time networking functionality to applications. One particular implementation of this framework is the one provided by Coral CEA. Coral CEA is a business ecosystem anchored around communications enabled applications (CEA) functionalities that are offered as building blocks, out-of-the-box components that link the capabilities and intelligence of networks platforms with the power of current applications to provide a new set of features and functionalities.

In this article, we show how a small company called Rezact, located in the ski resort town of Mont-Tremblant, Quebec, successfully implemented CEA capabilities within its own operations using Coral CEA services.

Business Model

Rezact started its operations in 2006 with the purpose of designing and implementing a new system that could handle the reservation of recreational activities. The business model on which Rezact operates involves three entities. First, there are customers staying at the resort for a brief period of time, usually a week or less. These customers are mostly comprised of families wishing to do something more during their stay in the resort besides skiing. Second, there are small companies (called operators), usually family-operated, that provide customers with a full range of recreational activities as diverse as spa and massage packages, dog sledding, horseback riding, helicopter tours, and rock climbing. The operators are spread throughout a relatively wide geographical area around the resort, and have historically faced the challenge of reaching potential customers and attracting them to their businesses. Third, to attract more customers, operators rely on resellers which sell activities to customers on behalf of the operators while charging them a commission for the service. Under this model, operators that would otherwise struggle to attract customers can reach a lucrative segment for a small commission.

Activity Box

To facilitate these interactions, Rezact created Activity Box, an online reservation system that manages reservations for various types of recreational activities like race tickets, horseback riding, spa services or even airplane tours. The system currently serves more than 35 operators managing over 250 activities that are sold by a network of 40 resellers. Since Activity Box was launched in December 2008, it has processed more than 20,000 reservations. The model for the entire system is shown in Figure 1.

Figure 1: Business Model

Activity Box acts as the connector that links customers staying in a region (in our case, Mont-Tremblant) with a group of operators that provide the activities customers are looking for. Each operator handles through the system its own set of resources to deliver the activities.

From this perspective, operators rely on Activity Box to offer the best possible service to their customers, improve their operations and increase their revenues. It was under that light that we turned our attention to CEA features to improve our processes.

How CEA Improved Activity Box

To improve processes, we searched for limitations or restrictions on the existing operational procedures, analyzed the cause or motivation for those restrictions, and then tried to find ways to reduce or remove them completely. One of those limitations was the way operators get notified of new reservations, which normally occurs by email or fax. Since operators may not check emails or faxes all the time, resellers are forced to create "stop selling periods" a few hours before the start time of the activity to avoid the risk of customers arriving to find out that the operator was not notified or did not have enough time to prepare for the activity. Blocking reservations, however, can effectively reduce everyone's profits. One way to decrease stop selling periods is to instruct reservation agents to phone the corresponding operators every time a new reservation is created that is close to the activity start time. Since a manual procedure always involves risks, CEA capabilities can streamline this process.

The first benefit obtained from utilizing CEA services was the ability to automatically place a call to the operators to inform them that a new reservation has been created. Once the call has been answered, the operator will hear a pre-recorded message informing them of the new reservation.

Another benefit was an improvement to customer service. For example, sometimes reservations get cancelled due to unforeseen reasons, like poor weather or a broken piece of equipment. When this happens, the customer needs to be immediately notified so they can decide whether to rebook or to receive a refund for the cancelled activity. Formerly, such notification was a manual procedure solely in the hands of the operator. With CEA services, a pre-recorded message can be automatically sent to the customers affected by the cancelled activity.

The third benefit was an increase of potential revenues to operators. In this case, a customer cancels a reservation and the operator needs to be notified. This is especially important when the cancellation event is triggered by the customer at the last moment in high season periods, when operators are most likely operating at the peak of their capacity. If they are promptly notified of the event, they can react accordingly and allocate the newly freed resource for arriving customers, thus increasing their revenues.

Implementation

Most CEA implementations, including the one offered by Coral CEA, rely on callable services that use some form of service-oriented architecture (SOA). One of the main features of SOA that needs to be considered when designing a solution is that service calls are usually synchronous, meaning that the client application needs to wait to receive a response from the server. This behaviour could adversely affect our application by creating contention on the Activity Box web server and reducing the future scalability of the system to be implemented within the normal activity reservation process. SOA calls to CEA services need to be decoupled from the web application itself so that performance and user interaction are not affected in any way.

The Coral CEA platform chosen for this project provides several services, including payment gateways and conference capabilities. For our purposes, we were only interested in the communication entry points provided by two application programming interfaces (APIs): i) the Third Party Call Control V3 (TPCv3) API, which allows the creation of communication links between two or more endpoints; and ii) the Audio Call API, which allows an application to play a pre-recorded message to participants on an existing call, as well as to monitor the status of the audio message requested. As expected, these two Coral CEA services only supported synchronous calls.

To solve this issue, we created an agent that served as an intermediary between Activity Box and the Coral CEA server. Every time an event that requires CEA capabilities is detected, Activity Box saves into a common database CEAQueue table the request for an outgoing call, including the name of the audio file associated with the event. The agent, implemented as a Windows service, continuously queries this table to detect any new requests. When a new request is found, the agent submits the request to the APIs and keeps polling the Coral CEA server to obtain an updated status of the request. Each status change is updated back into the CEAQueue table so the client application can be kept informed of the status of any call. The general model of this design is shown in Figure 2.

Figure 2: Agent Design

By decoupling Activity Box from CEA interactions, we eliminate the synchronous problem and provide a safety net to the application in case something goes wrong with the API call. We also reduce the modifications to the client application to just an extra SQL-like instruction to insert the request into the CEAQueue table, keeping the user and business layers free of changes. To provide updated calling status information to the users, Activity Box only needs to query the local table without having to continuously make remote calls to Coral CEA APIs.

With this design we can easily provide CEA functionalities to other applications within our organization as long as they use the shared table. One of the most interesting advantages of centralizing CEA communications is that all interactions with the APIs are completely transparent and developers in the company do not need to know how to make SOA calls, only how to insert a new record in a table.

Some other advantages of this approach include:

  • the agent encapsulates the internal mechanisms needed to interact with any CEA provider and exposes them as parameters that can be changed on a configuration file without affecting client applications

  • if the requested call did not go through due to technical reasons other than the customer hanging up, the agent can try requesting the call for several times, leaving a reasonable amount of time between attempts. Both the number of attempts as well as the elapsed time between attempts are configurable parameters

  • the agent can be configured to place calls between certain periods to prevent the application from calling customers late at night

  • call prioritization can be programmed so certain call notifications, such as urgent cancellations, are requested first

  • it is possible to programmatically set the maximum number of concurrent requests to be placed to the underlying communication platform. This is useful when the number of physical telephone lines is greater than one, allowing simultaneous calls

  • the history of call requests is kept in a centralized location that can be accessed by several applications

Since all the complexity associated with the communication with the CEA service is handled by the agent, the modifications required to Activity Box were reduced to a minimum. First, we needed to modify the database routines that process the creation of a new reservation as well as the cancellation of an existing reservation to insert the required values into the CEAQueue table. The values include the type of event, the name and telephone number of the receiver of the call, the reservation number associated with the call, and its priority. The second modification provides a way for the user to verify how the call went through, by adding visible buttons and links in the application that display the results of those calls, as shown in Figure 3.

Figure 3: Modifications Made to Activity Box

Recommendations

Based on our particular experience implementing CEA features within Activity Box, we can list the following recommendations:

  1. Any interaction with CEA services should be treated independently and outside of the regular process or event that triggers the call, to prevent scenarios where there is a limited number of available lines or when the application needs to wait for a response. One way to decouple client applications from CEA services is through the utilization of a Windows service that places call requests and periodically polls the CEA server to update the status of a call or an audio message.

  2. When implementing CEA features, in particular those offered by Coral CEA, companies should roughly estimate one month of development time, an estimation that obviously depends on the size of the application.

  3. Client applications planning to utilize CEA services should try to forecast, for a given period of time, the expected number of events that could trigger CEA requests. The number of simultaneous calls that can be put through by Coral CEA depends largely on the capacity of the deployed infrastructure and the number of telephone lines assigned.

Conclusions

According to our own experience, it is relatively easy for commercial applications to implement CEA features using Coral CEA APIs. A key factor for a successful implementation of CEA services is to keep the client application as isolated as possible from any interaction with the exposed CEA APIs. We have found that once the key elements to communicate with CEA services are in place and a buffer mechanism is used, the remaining effort is solely determined by the interactions between client applications and a common table. This can be done by using the agent proposed here, but other mechanisms could be found according to particular needs and scenarios.

Coral CEA, as a keystone entity and a platform leader offering affordable CEA capabilities, is a diamond in a natural state. It has the key technological elements needed to create a successful business ecosystem, but it requires developers to do some polishing to create ready-to-market applications. It is by leveraging CEA capabilities that a small company can easily improve customer service, increase the efficiency of operations, and reduce costs, just exactly what it needs to differentiate itself from the rest of the pack.

 

Share this article:

Cite this article:

Rate This Content: 
1 votes have been cast, with an average score of 4 stars

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.