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.

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!

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…

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.

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.

Asterisk, A (Lone?) Success Story

Unfortunately, there aren’t many successful open source telephony stories. Digium by far is the most notable. Huntsville, Alabama-based Digium, having roots in the Linux business, came out with the highly successful Asterisk open source PBX. One study done in January 2009 found Asterisk to have 18% of the North American PBX market, a statistic that any open source proponent should be proud of in light of the established competition from the likes of Avaya, Nortel, and Cisco.

Just six years ago in an interview with Rich Tehrani of TMCnet, Digium was already enjoying great success and beating Big Telephony:

…

RT: Describe the company’s growth.
Greg Vance (Digium): We’re growing very fast, in fact we grew 300 percent over this time last year.

…

RT: Are there any other serious open source PBX companies that keep you awake at night?
GV: NO.

…

RT: What has been the reaction of Avaya and Cisco to all of this talk of an open-source PBX?
GV: We haven’t had any reaction from them. I think we are under their radar at the moment. However, the users are very enthusiastic. We have many who want to eliminate their Cisco equipment or interoperate with Asterisk. When they look at the price of these systems versus Asterisk, it’s a no brainer. We know that both Avaya and Cisco have Asterisk running in their lab, but we have not had contact with either company in a formal way.

…

But with customers demanding more open technologies and lower TCO, the traditional telephony vendors also had to innovate and adopt open standards in their product portfolio. That’s why today all of them offer SIP and VXML compliant products, too. The evolution was inevitable and crucial for the company’s survival in today’s Internet-centric and open access world. And it was an open source company which paved the way…

Threat to Open Source Companies

With Big Telephony embracing open standards, a threat looms for the smaller players, especially those who have open sourced their products. Granted, many of these open source companies also implement a “freemium” sales model where customers can get additional product features and/or services by paying a fee, but it’s still a tough sell especially to large corporations when Big Telephony can offer the same features with the backing of hundreds (if not thousands) of 24x7x365 tech support resources and other incentives.

Not only that, but Big Telephony has the funds to acquire technologies it doesn’t have in order to quickly bring into its fold new products and services to ride the market trend.

For example, Microsoft acquired Tellme to get a better speech recognition engine. Nortel got Periphonics for the voice platform solution. Cisco bought Audium for the voice application development tools. Genesys (an Alcatel-Lucent company) scooped up Telera and VoiceGenie for their voice platform and tools.

In other words, Big Telephony can throw money to get on the open standards bandwagon. Smaller companies, on the other hand, have to build their own bandwagon with blood and sweat.

Even Digium realizes it cannot solely depend on selling Asterisk. It also sells training, support, hardware (interface cards and Asterisk Appliances), and software (add-ons, codecs, etc.). Additionally, it sponsors trade show events like AstriCon, which is important because a good defense against this threat from Big Telephony is to grow your community of not just customers, but developers and other open source evangelists. I believe that the reason Asterisk continues to garner attention and fans is not only because of a good product, but because they are attentive to the user and developer community. Digium provides some resources to support Asterisk and also listens to what the community has to say.

Kansas City, Missouri-based OpenMethods is the developer of the OpenVXML service creation environment (SCE) and main contributor to the open source Eclipse Voice Tools Project (VTP). It is the only open source, platform independent voice app SCE that I know of. Its product is available freely for download and interested VTP developers can easily create plug-ins and enhancements. The OpenVXML runtime engine can communicate to the major VXML-compliant voice platforms from Genesys, Avaya, VoiceObjects, etc. — a great SCE tool to deploy apps across multiple voice platforms in an enterprise. However, much like Digium it too cannot simply survive by just offering a flagship product. OpenMethods also offers professional services in app development and Genesys CTI consulting, as well as a close partnership with RightNow Technologies to offer the only Gvalidated Adapter for RightNow CRM.

Just the other day somebody alerted me of an open source CTI solution, WYBECOM’s TALK. It’s something I’ve never even heard of, and I’ve been in this business for ten years. Obviously, Asterisk being the #1 open source PBX also has its own CTI solution, but that didn’t stop WYBECOM from coming up with their own. Another testament to how open source offers several alternatives and options for users and developers.

David vs. Goliath

At times the future may seem gloomy for open source telephony and tools companies, but I take comfort knowing that the Internet is in itself a sprawling open network. As long as the Internet exists, there will be daring open source entrepreneurs and flourishing open source communities. The Internet is also about interoperability and open standards — something that Big Telephony has started to understand but still hasn’t culturally adjusted well to it yet. It is still in the mindset of selling hardware and licenses and locking in customers.

Open source players in this business need to build a robust community, relevant partnerships, and innovative features to fend off the Big Telephony armada. Being smaller means having the advantage of flexibility and agility, and support of loyal open source fans. However, if they lose focus and stray too far from their open source roots, then they abandon the only thing that distinguishes them from Big Telephony. When that happens it will be David vs. Goliath, except David has no sling and stones.

Disclosure: I was an employee of OpenMethods.

Perception

More often than not, contact center projects are run without regard to any sort of methodology, especially software development methodology, when programming tasks are involved. It is unfortunate and I believe a contributing factor to a high failure rate of contact center projects.

One of the hurdles to overcome is perception. It seems that there’s a perception gap between the understanding of traditional software development versus, say, IVR app development. Traditional software development utilizes common tools and IDEs to enable the developer become more effective in writing code, be it C++, Java, or whatever. These tools normally come with comprehensive debugging and simulation features to facilitate the development life cycle. The developer can quickly find out and demonstrate whether or not his (or her) code works per customer requirements.

Contact center app development, on the other hand, is regarded as some sort of magical stew with telecom, IT systems, and developer know-how all mixed in. But it really is similar to traditional software development except with more constraints: the tools are likely to be proprietary, debugging and stimulation features are lacking, and testing usually requires a coordinated effort between telecom, IT systems, data networking, and more. So the catch is to effectively manage the development life cycle with acknowledgment of these constraints and to work within them.

Design

Most importantly, don’t skip the app design phase — no matter how tight the project time line is. The requirements document (yes, it’s recommended to have that too) should be the Old Testament, and the design document is the New Testament. Together they are the project’s Bible. Seriously, I have seen my share of project management ignore a good, documented design, and what happens? The project may be off to a decent start with the developer coding away, perhaps proudly demonstrating some rapid prototyped app to everyone’s delight. Then sometime in the middle or tail end of the project a major flaw is uncovered or updated customer requirements warrant a new design — and all hell breaks lose. At this point the project team will take either one of these routes: 1) Go back to the drawing board and really spend time to finally document and update the design; or 2) Go into panic mode, apply band-aids to gaping wounds and use fingers to plug holes in the dam.

More often than not, it’s option 2 that gets chosen because it has the illusion to be the path of least resistance. To a panicked and undisciplined developer, option 2 will result in spaghetti code. Lots of duplication, hard-to-understand functions, hard-coded values — the works. That IVR or routing app, once affectionately called a cute little furry critter, all of a sudden grows into a hairy monster who hasn’t showered in years. Instead of correcting the critical mistake when there was still enough time and resources, now it becomes a software development lifeless cycle in a death spiral. Get the picture?

Development

I’d also recommend a development phase with a more collaborative and peer-friendly methodology (a la Extreme Programming). Instead of a solo developer, engage two of them. Not only is this good practice in times of unpredictable situations (illness, family emergency, etc.) where a second developer resource is readily available to take over, but also having peer reviews or peer programming significantly reduces defects and shortens testing times.

I can attest to the effectiveness of a peer programming methodology even in a contact center project. A coworker and I were developing an IVR app together, and after coming up with the design we split the work into functional chunks, and sometimes even sat in each other’s cubicle watching over the other person code. We were able to quickly implement algorithms, point out each other’s mistakes, bounce off ideas, and even take over when the other person had to step away. As a developer it was a great collaborative and satisfying experience. We delivered the IVR app ahead of the deadline and with minimum defects.

Okay, I can see you PM types frowning, But there’s no budget to acquire two developers! In that case, instead of just a pure business analyst resource, acquire one who’s also an experienced developer (most developers can handle BA tasks well). Or let’s hope that you (the PM) can also wear a developer hat. Yes, that’s how much I believe in this aspect of software development, even in contact center applications. Two developer brains are definitely better than one. And if you really must have only one developer, you will appreciate the time spent in the design phase to produce a quality design document. (God forbid the lone developer leaves the project, right?)

Testing

When it comes testing time, make sure all documents are in order. Test against the documented requirements first, then turn testers lose to detect any exception conditions. The best testers will be those who fat-finger a lot but are detail oriented. If it’s a DTMF IVR app, make sure to go through all the menus and key combination. If it’s a speech app, make sure testing is performed with landlines, cell phones, loud voices, quiet voices — you get the idea. If it’s testing routing and agent screen-pop, make sure to simulate what a rookie (or absent-minded) agent might do. I’ve had heard horror stories of systems going live — after a successful system test and user acceptance test — only to fail miserably in the real world for various reasons. Reasons which could’ve been predicted and implemented during testing.

Your thoughts?

Do you think there’s a place for software development methodology in a contact center project? And what are your own experiences?

Fast forward to 2010 and TMCnet has an interview with Grant Shirk, Director of Industry Solutions at Tellme Business Solutions, who shares some information on what the future holds for Tellme. Some tidbits of particular interest to me:

In addition to the emergence of distributed computing platforms for speech recognition, we expect to see more IVR services moving into the network as businesses seek the performance improvements and lower costs that on-demand platforms can provide. Virtualization of queuing and routing is a logical next step that can drive higher agent utilization within the contact center and reduce the cost and necessity of standalone CTI services. Tellme expects this virtualization to also improve the customer experience by getting callers to the right agent at the right time (avoiding unnecessary transfers) and enabling the growth of innovative services like virtual hold and scheduled call backs.

It appears that all divisions within Microsoft are aligning to its Azure cloud platform, from Office to SQL Server to Tellme speech recognition. But is Microsoft playing catch-up? Google has had its cloud-based Apps forever. Voxeo and several other IVR vendors lead in cloud-based IVRs. And unfortunately for Tellme, virtual hold and scheduled call backs are old, old news…

But there’s hope:

Together with Ford Motor Company and Kia, Microsoft and the Tellme platform pioneered the use of network-based speech to drive in-car experiences with the Ford SYNC product, and Kia with UVO (your voice), both profiled at CES and SpeechTEK 2009. The Ford SYNC service accesses the Tellme platform to provide drivers with hands-free access to local business search, driving directions, and other information. We expect to see more manufacturers moving toward a network-based model in the near future.

In addition, speech is quickly becoming an integral part of the mobile device interface. A great example that showcases the power of speech and language processing technologies is the recently launched Bing Mobile client. To provide mobile users the best possible speech performance for these advanced tasks, the speech features need to take advantage of network-based (rather than embedded) recognition capabilities.

Now this is what I think Microsoft Tellme will be the leader of the pack. Ford SYNC is one of the features that distinguishes Ford automobiles from its competitors. Considering how Ford has come back to be profitable again, perhaps it also has Microsoft to thank. Although some geeks have joked that they’d rather not encounter the BSOD in their cars, SYNC is clearly something that car manufacturers believe in, and we should not be surprised to see such in-car voice-activated driver assistance platforms to be ubiquitous in the near future.

The future seems bright:

Tellme continues to drive momentum and significant interest in the adoption of the Microsoft speech engine. In 2009, we answered over 1.3 billion calls (nearly 50 percent of our total annual traffic) on this engine, and our clients are observing significant improvements in recognition accuracy, automation, and task completion across their applications. The average task completion improvement when moving to the new engine has been three percent on average, out of the box.

The close relationship between the delivery and R&D teams within the Speech at Microsoft group allows us to continually influence the evolution and enhancement of the speech engine to best meet the evolving needs of our customers.

The key is the close relationship with R&D. If anything, Microsoft is a gigantic R&D machine: consistently spends over $6 billion annually since 2005. With that type of R&D backing, it’s all but certain that Tellme will continue to have a major impact in speech recognition technology in general, not limited to just contact center applications.

The Apple iPhone redefined how a person interacts with a mobile device. Its multitouch capabilities pushed UI paradigms to a new era. With the success of the iPhone, Apple clearly saw the world ready to accept a multitouch tablet device.

Enter the Apple iPad.

This device has the same iPhone OS which was made purely for gesture-based interactions. Better yet, it will run existing iPhone applications with no problem. Just as companies started to make iPhone apps to complement their regular product offerings (Cisco and Avaya, have enterprise iPhone apps; Genesys announced an iPhone app during G-Force Orlando 2009), they should see the bigger-footprint iPad as another opportunity to enhance the contact center experience.

The contact center supervisor and manager would find the iPad a perfect device to keep up with their busy schedules and still able to monitor the center’s performance. Of course, it all depends on the available applications from these vendors. Another potential for a new revenue stream? Make a deal with Apple to resell iPads preloaded with the vendor’s technical and marketing documents, as well as the vendor’s apps. I bet that’ll have a positive impact on the retention rate of contact center staff, too. Who wouldn’t want a shiny Apple iPad as a work device?

In fact, the new approaches are not programming models, they essentially provide low-level instructions for the various voice platforms. Much like a virtual machine. It’s up to the user of the platform to implement its own programming model on top of these instruction sets. And this is a very attractive offer, as this will most certainly ignite the development of new application programming environments and frameworks, some of which will be platform agnostic.

We lived a somewhat similar period at the end of the last century. There were many non-interoperable proprietary IVR platforms, and the industry came up with a solution: VoiceXML. Will we see something similar happen with these new approaches? I doubt it. I think that all these approaches are sufficiently similar that a good abstraction layer on the application side can suffice to support them all easily. In the 90’s, porting an application to a new platform was plainly impossible without a complete rewrite.

As we’ve seen new programming languages and paradigms flourish in recent years, it appears that the voice API space mirrors the same trend. Just as software engineers entered the “post-Java era,” we may be on the verge of a “post-VXML era”?