VoiceObjects 9.0, the newest version of the Voxeo VoiceObjects platform, is now available for download from the Developer Portal (for the free Developer Edition) as well as from the VoiceObjects Service Portal (for existing customers).

VoiceObjects 9 offers a number of new capabilities e.g. in event handling and in the playback of dynamic data (”Text-To-Audio”). We are going to provide more detailed hands-on descriptions of some of them in a separate blog post during the next couple of days.

In the meantime, download the newest version, take a look at the Release Notes, upgrade your existing applications – and by all means, contact our support team if you have any questions or problems. It’s easier than ever, with a new menu entry right in VoiceObjects Desktop for Eclipse that immediately takes you to our support chat.

In this latest post in our “tips and tricks” series, we want to take a look at how to efficiently work with layers in VoiceObjects Developer Edition.

Layer objects are, as you probably already know, what the Voxeo VoiceObjects platform uses to enable dynamic personalization. To learn more about the concept, have a look at Volker’s excellent introduction. What we’re interested in here is how to utilize your layer objects to influence the behavior e.g. of prompts that are played.

When you open object editors in VoiceObjects Developer Edition you see that in many places you have a Layer field that allows you to apply personalization. To do this, simply drag&drop any layer state (not the layer object itself!) into the field. You’ll end up with something like this:

All good and fine. Now whenever the coffee size is “tall”, this particular output will be activated.
But what if you wanted to change the relevant layer state and use the output e.g. when the coffe size is “venti”? You could, of course, drag&drop that layer state onto the field to replace the existing content. But there’s a much simpler way! Just click on the layer state side of the entry, and a pop-up menu listing all possible states for this layer appears:

Now just select the state you want, and you’re done.

Sometimes you want to take a certain action when one specific case is present (e.g. the caller selected a tall coffee). Yet some other times you want to take a certain action when a specific case is not present – for instance you may want to let callers know that “venti” is really the best value option when they selected anything else. How can you achieve this?

Easy: Layer state conditions can use both the “equal” and the “not equal” operator. Just click on the operator, and you get a pop-up menu:

Select “!=” for “not equal”, and your output will be activated whenever the caller selected either “tall” or “grande” (or any other layer state you may later add, other than “venti”).

Layers are an extremely powerful way of building personalized phone applications that dynamically adjust to your callers’ needs and preferences. For a lot more information take a look at chapter 7 in our Design Guide (PDF) and at the documentation of the Layer object in the Object Reference (PDF). Both are part of the VoiceObjects documentation, which is available in its entirety right here.

Infostore, the VoiceObjects data repository for real-time caller behavior analysis, offers a wealth of information so rich that it can be outright confusing for novice users. So in this series of blog postings, we want to shed light on Infostore’s inner workings and provide technically minded readers with the understanding and some sample SQL to explore the data on their own.

In addition, of course, there is VoiceObjects Analyzer with its comprehensive set of pre-built reports for all of the leading Business Intelligence (BI) frameworks. To find out more about it, as well as the Voxeo VoiceObjects tools in general, go to http://developers.voiceobjects.com/voiceobjects-documentation/.
For those eager to learn more we also offer hands-on training sessions on Infostore. Visit http://www.voiceobjects.com/en/support/training/ for details.

In this first part of the “Inside Infostore” series, we’ll look at the general structure of the Infostore repository and focus on the single dialog statistics record that is written for each call. In the subsequent parts we will then dive deeper into more detailed information about input states, personalization, business tasks, etc.

On a high level, Infostore is organized as a snowflake schema and optimized for immediate analysis of session data, typically by using BI tools, without the need for intermediate ETL processes. In particular this means that there are a number of key fact tables referring to lookup tables for the various dimensions. The following image gives a high-level overview of the relationships:

The Infostore data model has been designed for extensibility and integration with data derived e.g. from CRM systems, IVR logging, etc. In the same way, custom data logged by an application can be merged with the standard information contained in the Infostore fact tables.

The fact table we will focus on for right now is VOLDDLGSTS containing the dialog statistics, on a level that corresponds to what is often referred to as a Call Detail Record (CDR). In more than a hundred columns, the table contains aggregated information about the respective dialog session and can answer many important questions about application quality and caller behavior even without the need to join other, more detailed fact tables.
The entries in VOLDDLGSTS are the highest level of session information in Infostore, and in most installations it is desirable to have them for each and every session (at least for a certain period of time, such as 30 days). However, through simple configuration on the level of each deployed service it is possible to use statistical sampling and only collect data e.g. for 5% of all calls.

The following paragraphs describe the different types of data present within the VOLDDLGSTS table and provide sample SQL statements to answer typical questions. The SQL has been tested using Microsoft SQL Server; adjustments may be required for other databases. SQL buffs should also note that the statements have been optimized for readability as opposed to performance.
Entries in VOLDDLGSTS belong to specific services identified by a unique ID, the VSC_SID. In all of the samples we assume this SID to be known and fixed. It can be retrieved like this:

select vsc_sid from voldvscobj where vsc_refid=’<VSN of service>’ and is_current=1

Finally, the SQL statements used here operate on the “raw” Infostore tables. For Analyzer, there is an additional view layer that adjusts localization and performs a few mappings that usually aren’t relevant here. In some statements you see “locale_id=1″, which indicates the English localizations. Should you prefer German, use “locale_id=2″ instead.

Basic Session Information
On the most basic level, VOLDDLGSTS contains information about the vitals of each call session, including:

• When the session started (MONTH_ID, DAY_ID, MINUTE_ID, SECOND_ID)
• Which context parameters were available for the session (DLG_AAI, DLG_ANI, DLG_CRMID, DLG_DNIS, DLG_GCID, DLG_IID, DLG_RDNIS, DLG_SPSID)
• Where it was processed (SRV_HOST_IP, SRV_INST_PORT, SRV_INST_NAME)
• Which media platform driver was used (DRIVER_ID)
• How long it lasted (DLG_CALL_DUR_MS, DLG_PROC_DUR_MS)

Even on the basis of just this core information, a number of relevant questions can quickly be answered:

• How many calls were there yesterday / last week?
  Calls for a given day can easily be extracted with the data format YearMonthDay by use of:
  select count(*) from volddlgsts where vsc_sid=SID and day_id = ‘20090403′
  Similarly, making use of the date dimension table VOLDDATDAY we can retrieve all calls for a given calendar week:
  select count(*) from volddlgsts where vsc_sid=SID and day_id in (select day_id from volddatday where cw_id = ‘200914′ and locale_id=1)

• Which percentage of calls comes from within the San Francisco (415) area code?
  For certain applications it is interesting to see where callers are geographically located. This can often be approximated by area codes:
  select 100.0*count(*)/(select count(*) from volddlgsts where vsc_sid=SID) from volddlgsts where vsc_sid=SID and dlg_ani like ‘415%’

• Which calls lasted over a minute?
  Depending on the application, long session durations may indicate that callers had problems getting the information they called for. Thus it may be helpful to look at such sessions in more detail.
  select dlg_id,dlg_ani,day_id,minute_id from volddlgsts where vsc_sid=SID and dlg_call_dur_ms > 60000

As an excercise, you may want to build SQL statements to answer the following questions:

• Which percentage of calls came in during weekdays / weekends? (Hint: Use the information in VOLDDATDAY)
• Show number of sessions per day of week
• Which is the busiest day of the week (in terms of number of sessions)?

Interaction Details
Moving up from the session basics to information on how the caller interacted with the application, we get the following:

• How many dialog steps the session encompassed, and of which type (NO_DS_STEP, NO_DS_STEPS_VOICE, NO_DS_STEPS_DTMF, NO_DS_STEPS_TEXT)
• Which No Input / No Match events occurred during the session (NO_NI, NO_NM, NO_NI_1..4, NO_NM_1..4, NO_DS_NOINPUT, NO_DS_NOMATCH)
• How well recognition worked (AVG_CONF_VOICE, NO_DS_IMMEDREC, NO_DS_NONIMMEDREC, NO_DS_SUCCESS, NO_DS_NONSUCCESS)
• How often standard navigation commands were used (NO_BACK, NO_FORWARD, NO_RPTS, NO_SKIP)
• How often custom navigation commands were used (NO_HYPERLINKS)
• How the session ended (DLG_EXIT_TYPE_ID, LAST_DS_STEP, LAST_DS_NAME, LAST_DS_TYPE)

Frequently used questions in this area are:

• How do calls end?
  There are multiple ways in which calls can end (e.g. caller hanging up, application terminating normally or in exception, etc.) and it is good practice to keep an eye on the distribution. Here we use the localizations for the various exit types contained in VOLDEXTTYP.
  select count(d.dlg_id) as no_sessions, x.dlg_exit_type_dsc from volddlgsts d right outer join voldexttyp x on (d.dlg_exit_type_id = x.dlg_exit_type_id and d.vsc_sid=SID)
  where x.locale_id=1 group by x.dlg_exit_type_dsc

• Which objects do callers typically hang up in?
  For those calls ending with a caller hang-up it is relevant to look at where in the application this happens, since it may point to spots that cause callers grief.
  select distinct last_ds_name, count(last_ds_name) as no_sessions from volddlgsts where vsc_sid=SID and dlg_exit_type_id=16 group by last_ds_name order by count(last_ds_name) desc

• Which percentage of calls uses any sort of navigation?
  Most applications offer some way of escaping the normal top-to-bottom dialog flow, either by jumping to specific points (e.g. “main menu”) or by relative navigation (e.g. “back” or “repeat”). If a very large percentage of callers uses them, adjustments in the standard flow might be useful.
  select 100.0*count(*)/(select count(*) from volddlgsts where vsc_sid=SID) from volddlgsts where vsc_sid=SID and no_back+no_rpts+no_forward+no_skip+no_hyperlinks>0

Other questions you may want to explore for yourself could be:

• Which percentage of calls has both No Input and No Match events?
• Is the average confidence in short calls higher than in long calls?
• How does average confidence vary by area code?

Processing Details
In addition to details on the interaction with the caller, VOLDDLGSTS also contains a lot of useful information about the interaction with backends:

• How many backend interactions occurred, and how long they took (NO_CONNECTOR_EXECS, CONN_EXEC_TIME_MAX, CONN_EXEC_TIME_MIN, CONN_EXEC_TIME_TOT)
• Which errors occurred during the session (NO_ERRS, NO_ERRS_CONNECTOR, NO_ERRS_INTERNAL, NO_ERRS_MP, NO_ERRS_SCRIPT)
• How many notifications were sent during the session (NO_NOTIFICATIONS)
• Which network-related activity took place (NO_REQUESTS, VOL_BYTES)

Interesting questions regarding the backend are e.g.

• During which times has backend access been slow?
  This may point to problems on the backend itself, or to network congestion.
  select day_id,minute_id from volddlgsts where conn_exec_time_max>3000 and vsc_sid=SID

• Were any calls aborted due to backend errors?
  Again, this may point to either problems on the backend itself or in the integration code that connects the application to the backend.
  select dlg_id from volddlgsts where dlg_exit_type_id=2 and no_errs_connector>0 and vsc_sid=SID

• What’s the total data volume (in MB) transferred between IVR and VoiceObjects Server by week?
  This information is useful to ensure that network cpacacity between the IVR and VoiceObjects Server is sufficient to maintain optimal performance.
  select sum(d.vol_bytes)/10485476 as volume, t.cw_id as week from volddlgsts d, volddatday t where d.day_id=t.day_id and t.locale_id=1 and d.vsc_sid=SID group by t.cw_id order by t.cw_id

Other interesting backend-related questions could be:

• What is the average backend processing time?
• Are errors tied to backend slowdowns?

And finally, of course, you can combine information from the different categories to answer broader questions such as:

• How does average confidence vary by area code?
• How much longer are calls with many No Input / No Match events than calls with fewer of them?
• Do weekday calls show a different caller behavior than weekend calls in terms of events and navigation?

That should do it for today. Keep in mind that we’ve used only a portion of the columns in VOLDDLGSTS so far – and that’s just one of several fact tables in Infostore. So there’s lots more to come.
Next time, we’ll look at how callers navigate through an application by means of module sequences.

For a couple of months, many of us have been happy users of the beta version of NuEcho’s Eclipse-based NuGram IDE, my favourite grammar development and testing tool. Now, on March 31, they announced general availability of the “Basic Edition” of their IDE. It’s available as an Eclipse plug-in from their website.

Good news: It remains free of charge. A Professional Edition will follow in a few weeks, and I’m very curious as to what the additional features will cover. Also, their NuGram Server (which is all about creating dynamic grammars) will be generally available soon. Maybe some of you remember my blog on integrating VoiceObjects Server with NuGram Server, where I showed how the combination of both products makes it easier than ever to manage dynamic grammars.

Building great phone applications is kind of an adventure all by itself. But let’s admit it, from time to time there’s also just the need for some good, clean fun. In this special edition of our “tips and tricks” series, we’ll show you that the Voxeo VoiceObjects tools can deliver on that count, too.

If you’ve already worked with VoiceObjects Developer Edition you know that it offers fully integrated application testing capabilities. Just select “Test Application” on any start object and use the Test Monitor to call the application using a variety of IVRs including Voxeo Prophecy, or step through the mark-up code using the Debug Viewer. When building text or mobile Web applications you can also use the Phone Simulator to experience the application in same way that it appears on actual phones including e.g. BlackBerries and the iPhone.
What you probably don’t know is that there’s more than meets the eye.

Are you bold and fearless? Are you willing to venture where few have dared to tread? Are you sure you don’t have any project deadlines coming up?
Then follow these steps into the unknown:

1. Create a new Module object and call it “I want to play”
2. In the Object Browser, right-click on the Module object and select “Test Application”
3. This opens up the Test Monitor. Right-click the “Call” button and select “Phone Simulator – Web”

   

4. Pick the phone skin of your choice – BlackBerry looks best.
   
5. Enjoy
   

Oh, and if you get stuck don’t hesitate to contact our Extreme Support. We’re here to help

This is the second post in our “tips and tricks” series, and this time we’re taking a look at dialog flow options and new capabilities added with VoiceObjects 7.4.

If you have already worked with the Voxeo VoiceObjects tools you know that application dialog flows are presented in a self-organizing tree format, like this:

You read the flow from top to bottom, and at any point you can “drill down” to explore more details. In the  example shown above, you could expand the sub-sequence “Check applicable rebates” to examine its dialog interaction. Or, if you do not really care about that part of the application for the time being, you can leave it collapsed and have it out of the way while you work elsewhere.

By default, the dialog flow shows the “main path” through the application. In addition there are a variety of options that show more information and enable other ways of interacting with the dialog flow. To activate these options, right-click anywhere within the whitespace of a dialog flow editor:

Alternatively, you can access the options by clicking on the Dialog Options button in the menu bar:

Either way will get you to the Display Options window:

By default, only Show comment icons is selected. It alerts you to comments defined on objects by showing a text bubble icon to the right of the object name. The comment itself can be seen in the object’s tool tip. It is often used by designers to explain certain assumptions made in the object, or certain restrictions it exhibits.

Show Output items enables the separate display of each item within an Output object, as well as embedded outputs within other objects such as Modules, Menus, Inputs, etc.

Show pre-/postprocessing enables the display of pre- and postprocessing for all objects that have it. For Module objects, it additionally shows Dialog End Processing.

Enable validation automatically validates the dialog flow to indicate broken or insufficiently configured objects such as Inputs without grammars. Broken objects are marked in the dialog flow by a red name display.

Normally, the modified display option settings are only applied to the current dialog flow editor. By selecting Use as default for new worksheets you can set them as the new default for the current as well as all newly opened dialog flow editors.

But display options do more than just change the look of the dialog flow. They also offer additional ways of manipulating the dialog flow, always specifically adjusted to what you’re looking at. When displaying pre- and postprocessing, the respective embedded sequences can be manipulated in the dialog flow by simply dragging objects into them. Additionally, pre- or postprocessing can be set directly by dragging a Sequence object onto e.g. a Module object and selecting the respective command from the pop-up menu:

Likewise when displaying output items, embedded outputs e.g. in a Menu can be set by just dragging an Output object onto the Menu and selecting the desired target:

The dialog flow display options are one of the ways in which users can customize the Voxeo VoiceObjects tools to suit their own preferences and working styles. Stay tuned, there’s more to come in future posts of our “tips and tricks” series. And as always, let us know what you think and how we can make you even more productive in building outstanding phone applications.

VoiceObjects Developer Edition offers lots of little features that may go unnoticed with casual users. In a series of blog entries, we want to point them out to you so you can get the most out of your work with the Voxeo VoiceObjects tools.

As a start, we pick a fun feature appropriate for the weekend: editor themes. VoiceObjects Developer Edition offers five of them, which can be selected in the Advanced section of the Preferences:

The default theme is Arctic Blue, a suave mix of cool blues and sand tones that feel right at home within the Eclipse framework:

Lovers of understatement may prefer Slate, a monochromatic blend of solemn grays:

More outgoing users will enjoy Neon, a no-holds-barred theme of greens and yellows that is sure to get your attention as well as that of your office neighbors:

If you have been using the VoiceObjects tools for some time you may enjoy Classic, a theme that is reminiscent of the VoiceObjects Desktop for Web look:

Finally, the Canyon theme is our reverence to the rugged reddish beauty of the American West:

Pick the theme that fits your style or mood – add a bit of additional fun to building great phone applications in the Voxeo VoiceObjects tools. And by all means let us know which one is your favorite, and which other themes you would love to see in future versions!

What are you doing on April 21, 2009, at 8am PDT/11am EDT/5pm CET ? Would you like to join a web seminar where you will learn all about what is new in Prophecy 9 and VoiceObjects 9?

If so, please head over to our Developer Jam Sessions page and sign up for the April session. I (Dan York) will be speaking first about all the new capabilities in Prophecy 9 including a new simple dashboard to quickly see how your applications are performing, a new rich graphical management console, new deep log analysis tools and increased SIP capabilities . Stefan Besling will follow me speaking about Voice Objects 9’s new event handling features and deeper integration with Prophecy and Prophecy Hosting, as well as a variety of new infrastructure capabilities. At the end there will be plenty of time for any questions you may have about either Prophecy 9 or VoiceObjects 9. Please do plan to join us!

P.S. If you can’t join us on April 21st, the presentation will be archived on the Developer Jam Sessions page

If you found this post interesting or helpful, please consider either subscribing via RSS or following us on Twitter.

Over on the Monthly Jam Sessions page, the recording and slides are now available for the Developer Jam Session that Andreas and I gave on Tuesday titled “Voxeo IVR and SIP platform – Overview and use with VoiceObjects“. I spoke for about 25 minutes about Voxeo’s products in general and then Andreas followed with about 15 minutes on how to integrate VoiceObjects with Voxeo Prophecy.

One of the nice features of our new use of GoToMeeting/GoToWebinar was that Andreas could break out of the slides and show the integration using his actual PC setup.

Unfortunately, as this was our first time recording while using GoToMeeting, we inadvertantly recorded the Jam Session using a proprietary GoToMeeting video codec. Windows users can can download the G2M2 video codec for free. Mac and other users will unfortunately not be able to view this recording. We apologize for this and now know how to record webinars differently in the future.

Tonight this developer portal was upgraded to run WordPress 2.7. As far as I can tell, everything seems to be in order.  All links and downloads appear to be working fine.  However, if you find any issues while using the site, please either leave a comment here or send me email to let me know.  Thank you.