Communication Enabled Business Processes (CBEP)

April 21, 2008

Review of a presentation at eComm2008 by Trevor Baca

This was a compelling presentation on the use of voice enabled applications to enhance/improve business processes by reducing the latency in computer-to-human and human-to-human communications.

The talk focused on real world examples of CEBP applications:

§  Buyer Verification and Fraud Control – A customer trips a fraud threshold when using their credit card for a transaction.  Instead of the card being automatically locked (and the purchase denied), the system can call the user and prompt them to ‘press 1’ if the charge is valid.  The user can also press 9 to contact C/S and dispute the charge.

§  Critical System Support – The system can be configured to automatically contact (dial) essential support staff and alert them to critical system problems/outages.  The systems can also ‘conference in’ members of the support team to discuss/resolve the problem. 

§  Wakeup Call Notifications – The user can set their current location (city or Zip Code) and time of wakeup. The system will call user with a ‘wakeup call’ and play relevant information (i.e. local weather, traffic information, flight status) based on their notification profile.

§  Job Site Closure Notifications – The system will call team members and notify them of job site closures. The notification app can get a confirmation of receipt of the message from the users.

§  Caring Line Services (not really a CEBP app) – Automated system that allows callers to leave ‘caring’ messages for individuals who are in need of support.  The messages can be picked up and played from anywhere.  This is an example of a communication system that is used to broker human-to-human communications.


The following is a summary of Trevor’s report on Judaka’s key learning and takeaways from their experience in developing CEBP applications, and my response/take on his [their] findings.

§  Voice apps are easier to develop then Web application.  ->   I would agree for simple voice applications.  However, for complex voice applications that is clearly not the case.  The problems with poor quality voice application and poorly designed voice dialogs are well known. 

§  The best opportunities for voice services are in areas where there is a sense of urgency (i.e. disaster response).  ->   Yes, especially if you want the parties to be able to communication immediately.  You could to the same thing with SMS multi-casting, but that would not be my first choice for communications when I am in the middle of trying to recover critical systems/services.

§  Voice can be a better bearer of emotion.  ->  Yes, this a clear advantage of voice over Email or SMS.

§  Try to target times in which things are going to happen, rather places where which things happen.      ->  I am not sure that I completely agree with that.  Location based services are going to be huge.

§  Look for opportunities where people that are texting or IMing and want/need to talk to one another.  ->   Yes, clearly a good opportunity for automated voice connect

§  If scaling is not currently a problem, it will be [it you are the least bit successful].  ->   Yes!

§  Integration is hard.  Even if you have APIs, and a Web Service architecture – integration will take time and effort.  ->   Yes, and you need to carefully manage the customer’s expectations at every step of the process.

§  Vertical markets did not work the way they thought that they thought that they would.  Voice did not seem to provide a significant advantage in a particular market.  ->   I am not sure what to say about that.  It is clear that their voice applications can be used in many ‘horizontals’.  However, there are many successful voice applications for the corrections, medical, finance, legal, insurance, and travel markets. 

§  Our best solutions come from thinking about people [the end user] and real-world problems and issues.  ->   Yes! 

§  The money is in the enterprise; the monetization for products and services is right there [the slide shows logos of Apple and Nike].  ->   If what he is saying is “don’t expect the end user to directly pay for the service”, then yes, I would agree.


The last point needs a good bit more discussion.  What is the value proposition for the product/service? Who is going to pay for it, and how much will they be willing to pay? 

Motivation for an XML Prompt Framework to Support Multi-lingual Applications

November 15, 2007


In developing the prompt framework for a multi-lingual application, I gained some useful insight into the use of XML in the design and implementation of flexible and extensible data/information structures.

Given the number of ways that prompts can be configured and used (initial, help, no speech timeout; single, concatenated, or escalating; time, day, month and/or year; recorded or TTS, etc, etc) it would be difficult to specify a relational database model (schema) that full represent the configuration parameters and variations of the all of the voice application prompts. Also, it can take a significant amount of effort (time/resources) to modify database tables (schemas) when the prompt structures change, or when there is a need for new features and functionality.

We try to get a full set of requirements for a new products/services before we begin development. However, the more we get into the project, and the more that we work with the users/clients/customers, the more that learn (discover) what the service ‘really needs to do’ and how best to develop those capabilities. As that is ‘the world in which we live/work/develop’ then it is essential, where possible/feasible, that we insure that the underlying data structures that hold configuration information (i.e. protocols, profiles, etc) be designed and developed with a flexible and extensible data structure/representation – if we do that, then XML can be a good tool for the job.

XML Features

XML has many features that can be of significant value in supporting rapid design and implementation of flexible and extensible information/data structures:

– Extensibility – Data tags and hierarchy are designed to match the structure of the data. We are not locked to rigid DB structure when the requirements for the data change or when new features and functionality is added. New data tags/structures can be specified/designed and then rapidly integrated, tested and implemented.

– Ease of creation – Simple XML documents can be easily created by hand. For more complex structures, there is a wide range of tools to rapidly author (create/edit) XML documents – we do not need to build tools to do these tasks. The data structures that we create are not limited/constrained by the tools that we build to author them.

– Flexibility – Data/information structure can be easily developed and tested. These structures can be easily modified/extended as needed. When requirement change or additional features and functionality are added, the XML structure can be extended or modified as necessary.

– Simplicity – Information coded in XML is easy to read and understand. You don’t need to be a programmer to make good use of XML

– Openness – XML is a W3C standard, endorsed by software industry market leaders. There are XML parsers for every programming language. There is full support for XML in PL/SQL, therefore XML could be easily integrated into our middleware

– Validation – XML provides processes for validating the structure of the documents (elements, attributes, hierarchy, order, etc). The schemas can also validate the data/information contained in the tags using – data can be validated by type, range and value(s)

– Self-description – XML documents can be stored without such definitions, because they contain meta data in the form of tags and attributes. XML Provides a basis for author identification and versioning at the element level. Any XML tag can possess an unlimited number of attributes such as author or version.

– Contains machine-readable context information – Tags, attributes and element structure provide context information that can be used to interpret the meaning of content, opening up new possibilities for highly efficient search engines, intelligent data mining, agents, etc.

– Separates content from presentation – The look and feel of an XML document can be controlled by XSL style sheets, allowing the look of a document (or of a complete Web site) to be changed without touching the content of the document. Multiple views or presentations of the same content are easily rendered.

– Facilitates the comparison and aggregation of data – The tree structure of XML documents allows documents to be compared and aggregated efficiently element by element.

– Can embed multiple data types – XML documents can contain any possible data type – from multimedia data (image, sound, video) to active components (Java applets, ActiveX).

– Can embed existing data – Mapping existing data structures like file systems or relational databases to XML is simple. XML supports multiple data formats and can cover all existing data structures and.