Development

AdhearsionCon registration opens, Web telephony developers take note

I know what you’re saying: Adhear-what?

AdhearsionCon. Now open for registration.

Developing telephony apps these days has never been easier. Programmers have a variety of languages to choose from, several frameworks and APIs to refer to, and none of them cost much (or at all). Better yet, the inevitable convergence of telephony and Web has brought us innovative mashups and, in my view more importantly, a new generation of telephony and voice app developers. These developers are well-versed in Perl, PHP, Python, Ruby, etc., savvy with third-party APIs, and immensely comfortable with Web technologies.

You may have heard of Twilio, Tropo, Teleku, QuickFuse, and the like. You definitely know about Skype, Asterisk, and Google Voice. And perhaps a bit curious about SIP. Not many folks have heard of Adhearsion (myself included), but it’s definitely something worth digging into.

For starters, Adhearsion is a framework written in Ruby to help developers code voice apps for the open source PBX, Asterisk. Why Ruby? Why Asterisk? (Check the FAQ, jack.)

It’s also open sourced and backed by one of the biggest names in cloud-based voice app development, Voxeo.

I would encourage any developer — Web or voice or anything else — to check it out, especially if you’re in the Bay Area. After all, I believe the world is a better place with you knowing how to bend open source telephony to your will.

Skype opens the development floodgates

Get ready for Skype to become even more ubiquitous.

Today Skype lets loose its SkypeKit SDK for developers to incorporate Skype-tastic features into consumer devices and desktop applications. In essence, any Internet-connected device can now become VoIP-enabled via Skype. Right now the SDK is available for Linux with Windows/Mac coming later. The SILK audio codec is part of the SDK and definitely something to lure developers into creating HD audio apps.

This couldn’t come at a better time. Consumer electronic devices are fast becoming networked and an important part of our lives that we wonder why we cannot communicate using these devices. We don’t really care for the traditional phone hardware anymore in today’s IP world. If my digital photo frame is Internet-enabled, why can’t I use it to call people too? It sits in the living room or at my desk — convenient and popular locations to conduct calls.

I’m excited to see what developers come up with to Skype-enable our electronics!

Teleku joins Tropo and Twilio in competitive Web telephony

The Web telephony space welcomes another competitor today: Teleku (a project of GetVocal, Inc.). For all you Web developers in search of telephony APIs, rejoice! for you have another set of programming goodies to choose from.

Why Teleku over competitors Tropo and Twilio? According to this TechCrunch piece:

So how does Teleku differ from Twilio? It’s a matter of flexibility, according to founder (and sole employee) Chris Matthieu. He says that when you use Twilio, it’s an all-in-one deal: you write your code in Twilo’s easy-to-use syntax called TwiML, which is then sent to Twilio’s telephony services in the cloud that are hosted on AWS. That’s great (and may be even preferable to some people), but with Twilio you can’t port your application to a cheaper service should one become available.

With Teleku, you can write your code using TwiML, or you can use Teleku’s own simplified telephony scripting language, called PhoneML. Your code is then sent to Teleku’s servers, which translate it into industry standard (but harder to write) VoiceXML. Matthieu says you can use that code on any of a variety of established telephony providers, including Voxeo and Plum Voice, and it will also work with enterprise systems that rely on VoiceXML.

Matthieu says this gives Teleku users a few advantages: first, they can swap between various providers if they find a better rate. And he also says that Voxeo and other telecom services have better optimized their servers than AWS has to work with voice traffic, and that they offer a few features that Twilio doesn’t yet, like speech recognition.

Finally, Teleku offers a wizard for building web-enabled telephony services for people who don’t have any coding experience at all. This allows you to select actions from a dropdown menu, like “Play”, “Speak”, and “Transfer” (you then fill in text dialogs to instruct the application what to say or what number to transfer to). You can drag and drop these actions depending on what order you’d like to execute each action. Watch the video below for a complete demo of the wizard.

Sounds like a good combination of features and user experience. VoiceXML is certainly the industry standard and would be a plus to developers who’d want portable applications. The behind-the-curtain star is certainly Voxeo, for providing the platform and speech recognition feature. But no doubt Matthieu did a tremendous job in designing PhoneML and the user-friendly online tool for making it work seamlessly.

And judging by the fact that founder/developer Matthieu tweeted last at 2:30am and got TechCrunched, he’s probably having a very busy day…

Rethinking IVR development

Previously I’d written about the lack of software development methodology in creating contact center applications such as self-service IVRs and routing logic. Since a lot of IVR developers are self-taught, without formal software engineering background, or forced by circumstance to take on the task, I believe a good way to approach this is to start from the very basics of software development. Set aside methodology for a moment and just simply contemplate on what an application is.

Like a Story

Who doesn’t love a good story? An introduction that hooks your attention, progresses to a climax that prevents you from setting down the book, and finally a conclusion that satisfies your curious appetite.

An application also has a beginning, middle, and ending. The beginning is taking some sort of data as input, the middle is to process that input, and the ending is the result of the execution. So in your mind just think of the app you’re creating as a simple outline for a story, with a beginning, middle, and ending. From that you will add a variety of elements to the outline, expand plots, and finish a complete story.

MVC

No, I’m not referring to “most valuable customer.” MVC is the famous Model-View-Controller design pattern, first conceived way back in 1979 by the brainiacs of Xerox PARC. You may already know that Xerox PARC was credited with the invention of the mouse, GUI (graphical user interface), and Ethernet. But equally important was its contributions to software development, like object-oriented programming (OOP), the Smalltalk programming language, and of course, MVC (from Wikipedia):

The model is the domain-specific representation of the data upon which the application operates. Domain logic adds meaning to raw data (for example, calculating whether today is the user’s birthday, or the totals, taxes, and shipping charges for shopping cart items). When a model changes its state, it notifies its associated views so they can refresh.

Many applications use a persistent storage mechanism such as a database to store data. MVC does not specifically mention the data access layer because it is understood to be underneath or encapsulated by the model. Models are not data access objects; however, in very simple apps that have little domain logic there is no real distinction to be made. Also, the ActiveRecord is an accepted design pattern which merges domain logic and data access code – a model which knows how to persist itself.

The view renders the model into a form suitable for interaction, typically a user interface element. Multiple views can exist for a single model for different purposes.

The controller receives input and initiates a response by making calls on model objects.

This is a very popular pattern when it comes to web app development. Next time you’re doing some online shopping think about all the facets of the experience and what has to come together to make it all work.

Now close your eyes and imagine how it would work without visual elements and only using your ears. In other words, think of your IVR app as a web app, but without the browser and only caters to blind users.

Keep It Simple, Stupid!

Be conscious of the KISS principle, in designing the presentation (i.e. IVR menus and voice prompts) and in coding the business logic. Remember, your users are blind and their browser is a numeric keypad.

Learn to love abstraction. Break up big problems into smaller chunks, perfecting a chunk at a time. Refactor your code in order to simplify it, not only to you the developer, but also to others who may need to read it one day. That means grouping similar logic into functions or subroutines. Always comment your code and update documentation.

Write your app as if writing a story. Carefully craft the main characters, build upon subplots, be concise and clear, etc.

I used to write IVR apps with a sequential mindset, meaning that I’ll string up menu after menu. It made for hairy looking apps and difficult to navigate through the code when needing to make changes.

Then I learned from someone to code it like a state machine (or a wheel). Analyze the call flow to find logical abstractions. Create a label for each abstraction (e.g. Greeting, AskForCustNum, ProcessCustNum, etc.). In the code keep a variable to update the labels as you develop the whole call flow in the IVR as a gigantic loop. Here’s what I mean in pseudo-code:

// Initialize the state machine

SET state_label = ‘Greeting’

WHILE state_label NOT-EQUAL-TO ‘End’

IF state_label IS ‘Greeting’ THEN      // Greeting menu

{ play greeting prompt }

SET state_label = ‘AskForCustNum’

IF state_label IS ‘AskForCustNum’ THEN       // Get customer number menu and input

{ ask for customer number; get customer input }

SET state_label IS ‘ProcessCustNum’

.

.

.

IF state_label = ‘End’ THEN       // End of call flow

{ play thank you prompt }

EXIT WHILE

Obviously IVRs aren’t programmed like this anymore, so this would require some translation to whatever IVR development tool you’re using. But notice that this will flatten out the menu tree to make the app more readable, plus changes to the call flow can be made easily by just modifying the variable state_label accordingly. For example, in order to bypass the greeting all you have to do is initialize state_label to ‘AskForCustNum’ or whatever new entry point you want — there’s no need to move blocks around or reconnect any lines.

Conclusion

In any IVR development project it makes sense to step back a bit and soak in the broader picture before diving head first into the programming aspects. Write code as if writing prose, and always keep simplicity and abstraction in mind to ensure that not only you will enjoy the development process, but also others in the future.

Social Media and Speech Recognition are so yesterday – get ready for Personality Mapping

Just when you thought your contact center is on top of it all by adopting the latest IVR and CRM systems which supports social media and advanced speech recognition, here comes the new frontier in transforming the contact center: Personality Mapping. That’s right, finding the ideal agent to service the customer. It sounds straight forward and brutally simple, but it’s not a feasible feat until recently with the advancements in artificial intelligence (AI) and neural networks:

Finding the optimal match between caller and agent is a rich and evolving process based on caller and agent characteristics.  Until a few years ago, there was not enough computing power available to perform the millions of calculations required to match callers and agents using enough data attributes of each to produce optimum pairings with consistent results.  Today the computing power exists and is aided by artificial intelligence and neural networks that are capable of matching callers and agents based upon personality attributes in 40 milliseconds

The benefits to the contact center are obvious:

What kind of results can such a technology deliver?  Technology that can take in data on the agent, caller, and agent performance history can dramatically increase conversions in a sales environment.  It can increase first call resolution and customer satisfaction while decreasing average handle time (AHT).  Matching callers to agents based on the probability that an agent can generate a rapport with the caller also leads to higher agent satisfaction scores, an improved work environment, greater retention, and decreased agent burnout.

But for this to work well, the organization must have good data — current and historical, and as much as possible. Thanks to today’s storage technology and cost of it, this shouldn’t be a big problem for most companies. The hard part is ensuring data readability and integrity.

Personality Mapping isn’t just an evolution in contact center technology but it will also impact the center’s staffing and human resource policies. Suddenly you would not want to hire just anybody to take calls — now you’d want to administer a personality test to the candidate as well. With the massive data collected about your customers, you’d know what type of personality and demographics from an agent to best fit the organization to provide the best service to customers. What about affecting workforce management? The customer-agent matching engine may skew call distribution numbers to favor a certain group with particular attributes. Will the routing rules have to be changed? Most likely, to accommodate Personality Mapping. What about agent compensation? Without updates to the routing rules, an agent lacking certain favorable attributes to match with more customers may end up with a less than stellar report card, even though it’s probably not his (or her) fault.

This is an interesting and far-reaching technical development in the contact center, and I cannot wait to use such a system and read more case studies about it.