Wednesday, April 20, 2011

IVR design and implementation fundamendals

IVR technology has been a part of our everyday lives for several years now. We are all familiar with phrases like “To do this, please press 5” or “Please type your PIN number”. Most of us have also been lost in the endless and “labyrinth – style” menus offered by these IVRs. It doesn’t have to be like that!

There are ways to ensure that IVR delivers quality self – service. To do that, it is important to follow some guidelines when designing the IVR application itself. Investing is complementary technologies is also of paramount importance to creating an intuitive voice interface. We will explore these principles and technologies in more detail in this post.

IVR application design principles and complementary technologies

  • Keep menus simple. Complex menus are greatly annoying for the user. When designing the application flow, the number of available options presented at each stage should be kept to the minimum possible (more than 4-5 different options are too much). The options themselves must also be clearly descriptive of what can be found in the sub-menus selected. This is very important since, due to the nature of voice user interfaces, navigation mistakes on IVR are more “costly” compared to visual interfaces such as web.
  • Provide easy navigation for both the new and the experienced system user. New users, that do not know anything about the specific application, need more information on what the system is about and what functionality each option offers. Encompass this information on each menu, when needed, but make sure to include the barge-in(*) functionality so that experienced users can bypass listening to these prompts repeatedly. Experienced users should also be given the option to jump directly through multiple levels. This can be easily achieved using speech recognition technologies.
  • Use the latest speech recognition technologies to provide natural speech recognition. It is more expensive than simple keyword recognition and far more expensive than DTMF, but it makes navigating through voice menus substantially easier and a lot more intuitive. Use speech recognition in conjunction with DTMF when possible. It is a lot easier for the user to type his 12-digit pin than having to repeat it 3-4 times until the speech recognition engine understands it correctly. Using each technological feature on the correct situation is one of the most important parts of voice interface designing.
  • Allow users to exit the application and transfer to live agent on any parts of the application. Inform them about this functionality at the beginning of the menus. Speech – enabled IVR systems often cause problems for various reasons such as accent variations or noise, so this exit option is very important.
  • Use professionally recorded prompts consistently through the voice application. Text to speech, while having seen large improvement during the past few years, is still not in the position to compete with human recorded prompts in terms of quality and thus it remains still the cheap / temporary solution.
  • Ensure that each piece of information is only collected once from the users. Have the IVR complement the live agents gracefully. This can be done by investing in CTI technologies which use the information gathered through the IVR and present them to agents, should the call be transferred.
  • If there are queues to talk to agents, inform the users about it and also communicate them the average expected waiting time in the queue. An additional feature that can be implemented if the contact center includes outbound capabilities is auto – callback. The IVR user can state that he wants to be called back as soon as an agent is available.  The customer types in (or speaks) a phone number that they wish to be called at and then hangs up. The system can then put a token representing the customer in the queue, and when the customer’s turn arrives, an outbound call is initiated and connected directly to an agent, with the CTI information already on the agent’s screen.
  • Reduce the information input to an absolute minimum. This can be done by integrating the IVR and CTI with a database of user profiles (which can be either the company’s CRM or, more often, a dedicated database synchronized with CRM). Collect the database primary key via the IVR (which is usually the user’s name and/or some PIN) and then query the database to retrieve more information about the specific user.
(*)     “Barge-in” : Refers to the ability given to an IVR user to bypass a spoken prompt and immediately enter their response to the answer (either via DTMF or through speech). As soon as the user presses a button or starts speaking, the IVR interrupts the prompt utterance and goes to the next stage to read the input. Barge – in is extremely helpful in eliminating annoying repetitive messages, especially for experienced users of the system.


Monday, April 11, 2011

SS7 protocol technical overview

     In the previous post we have seen what SS7 can do and what types of services that we use everyday are based on it. We will turn now a bit more technical and see in a nutshell how SS7 works (more details can be found in various tutorials over the web). In many of its aspects, the SS7 architecture is similar to the OSI network layer architecture.

Signaling points and their types

     SS7 nodes are called signaling points (SP) and they are usually identified by an integer called point code (PC).  The international SS7 network uses its own unique PC numbering and each national network and each operator use their own numbering schemes internally.  There are three different types of SPs in an SS7 network, categorized based on their functionality:

     A Service Control Point (SCP) is an interface between SS7 networks and databases. A Service Switching Point (SSP) is a voice switch with integrated SS7 functionality. And a Signal Transfer Point (STP) is responsible for transferring information between other SPs. Many SPs in the network typically play multiple roles (for example an SSP can also support STP functionality).

Signaling links and their types

     Signaling points are connected to each other with signaling links, over which signaling information is exchanged. More than two links (up to a maximum of 16) can be used to connect two signaling points, both for increased capacity as well as redundancy. These links bundled together are called combined linksets.  There are several types of logical links that can be used in SS7 networks, categorized depending on their functionality and what types of SPs they connect (the physical link remains the same for all these cases). These are A(access)- links, C(crossover)- links, B(bridge)- links, D-(diagonal) links E(extended)- links and F(fully associated)- links.

Routing

     Routing between nodes is configured statically. Each SP maintains a routing table with all the available information needed for routing. The group of routes that can be used to reach a particular destination is called routeset.

The SS7 protocol stack

     SS7 is a work in progress since the early 1970s. During this period, a stack of protocols was developed to provide the functionality required. The architecture of these protocols is layered and it is pretty much analogous to the OSI 7-layer model which is used on data networks. The lower layer protocols are common for all SS7 implementations. The higher level of the stack differentiates depending on the applications to be used by the SS7 infrastructure. The schematic below shows the most commonly used protocols in the SS7 stack:




Thursday, April 7, 2011

SS7: Advanced telephony signaling provides limitless capabilities

There are two types of signaling protocols in the telephony ecosystem. Channel Associated Signaling (CAS) is used to describe signaling protocols that use one dedicated signaling channel for each voice channel in a 1 to 1 analogy, according to fixed and pre-determined rules. Most telecommunication protocols to date use CAS to transfer information about call setup and control. The other type of signaling protocols uses Common Channel Signaling (CCS), where the signaling capacity for multiple channels is being integrated in one specific channel, called the signaling channel.  The only CCS protocols developed and used so far are the Signaling Systems 6 and 7 (SS6 and SS7) with the latter having seen widespread usage during the past decades.

Over time, SS7 has evolved to address all the limitations of CAS protocols, such as:

-          Very fast call setup times.
-          Flexibility.
-          Capacity to evolve and incorporate new features.
-          More cost effective than CAS.
-          Vastly superior call control capabilities.

On the other hand, the major drawback of SS7 compared to the traditional CAS systems is that the signaling channel is a single point of failure in the ecosystem.

SS7 is the enabling protocol for most of the telephony services we all use today and take for granted. Among other things, telephony systems based on SS7 offer:

-          Toll free numbering that are widely used for marketing campaigns and customer support services.
-          Single directory number  (a company can have a single incoming number and then redirect the incoming calls to the appropriate extension within its private telephony network, using signaling information).
-          Cellular network mobility management and roaming services.
-          Local Number portability (which allows us to retain our phone number when switching carrier).
-          Custom Local Area Signaling Services (CLASS) which include:
o   Call block from pre-specified numbers.
o   Distinctive ringing for groups of callers.
o   Call completion to busy subscriber.
-          SMS.
-          EMS (enhanced functionality added to SMS service).

Furthermore, SS7 is a key protocol in the effort for telecommunications and internet convergence. It allows hybrid network services to be deployed such as:

-          Internet Call Waiting: displays a message in user’s computer screen when they use the same line for telephony and internet, and an incoming call arrives. The user can then redirect the call to voice mail, accept the call or reject it. This application is extremely useful for dialup connections.
-          Click to dial applications (i.e. click a number on a webpage to place a call automatically).
-          Unified web and telephony services. This has evolved to an industry in itself, unified communications.
-          WLAN hotspot billing.
-          Location – based games.

           We can see from the above examples that SS7 infrastructures are used to serve everyone in developed countries in their day – to – day activities, even though it is transparent to the end customer.  It is also a key enabler of various value added services that provide the telecommunication carriers with additional revenue sources. In a subsequent post we will explore how SS7 works in more detail and examine its layers.