About us and our stuff

The primal questions

• Who are we?
• Why are we here?
• What do we believe in?
• What is our niche?

We are developers who use software to solve problems.

We are here because we found out just how hard it can be to build a scalable server application to answer telephone calls when we automated a Fortune 100 client's help desk.

We believe it shouldn't be as hard or as expensive as it is. We believe the job should be doable by mere mortals who should be able to use the development tools and languages that they already know.

We want to provide our customers who want to build applications with the easiest and least expensive means to get the job done. We want to sell high quality, scalable and inexpensive products to customers who don't have the resources or the inclination to build their own solutions.

How is our stuff different?

Tools for building IVR applications generally fall into two categories.

Misguided Approach One

The first of these is the component category which offers software widgets to answer calls, detect keypad input, play messages etc. Very often these components only address the needs of single-line desktop applications. The very hard task of cobbling the components into a scalable server is left to the application developer.

Misguided Approach Two

The second of these is the server category. Here vendors build scalable servers which require the use of proprietary call-flow designers or script languages for applications. Frequently integration with the backend of an enterprise is difficult. Sometimes these servers require applications to be cast as COM components ignoring the object model of the developer's chosen language. Some others adopt a model like the one used for web development. They require a hodge-podge consisting of web server, an application server, an XML markup language, a scripting language and a programming language. Having so many moving parts serves to increase costs and complexity needlessly. Worse, it steepens the learning curve which prolongs the development effort.

A Better Approach

Our approach combines the best parts of the approaches above. We have developed a server because that's clearly the biggest hurdle facing our customers. Out of the box, it knows how to answer calls, stream media, record messages, synthesize speech, recognize speech, detect touch tones and manage resources. Further, it knows how to perform any of those operations on any number of telephone lines at the same time.

In addition, our server adapts itself to the applications that it hosts rather than the other way around. In any of the languages that we support there are three high level objects written in that language which handle the telephony and media functions, the text to speech functions and the automatic speech recognition functions. The developer is shielded not only from the complexity that underlies scalable servers in general but also from the inherent complexity that specifically underlies a speech-capable telephony server so that most operations take a line or two of code. 

Developers don't waste time learning technologies that have little bearing on the task at hand. Further, the application which the developer writes is less an application than a module which plugs into the server. That reduction in scope of work simplifies the job immensely. The components used by the application are simple because the server is predisposed to do the work common to all IVR applications. Integration with the rest of the enterprise is simplified because the familiar language, tools, and runtime libraries may be used to build an IVR.

Summary

In short, our server makes it trivial to perform telephony, media and speech operations in a scalable way. The complexity of building an IVR application then becomes determined completely by what it does and not at all by the form of its user interface.

Building a server application to answer telephone calls in a scalable way is too hard.

Buying an IVR is often too expensive.

In either case, very often integrating with existing systems in your enterprise is cumbersome.

Markup languages such as VoiceXML and SALT are great at documents but they are poor choices as development languages. Build your application using the language and the tools that you know.