Using Leg Types to make your life easier

First, a quick chat about call legs vs. calls.   We all know what a call is – that period of time from when you pick up a phone until you put it back down again.  In modern systems each call  is comprised of one or more call legs, with each leg being a single source/destination combination.  So if you try to call Sally, you could see the following legs:

  • Leg 1: You dialed Sally’s extension.  It rings.  No answer.
  • Leg 2: Your call gets forwarded to voicemail.  You leave a message.  You hang up.

That’s a two-leg call.  Simple, right?

Introducing Leg Types

Leg types are a way to add a reusable, human readable “tag” to the individual legs to make both searching and seeing call flow easier and better.

For instance, you could define leg types for “Abandoned at voicemail” to catch those legs where the caller went to voicemail and just hung up on it.  Another could be “Left voicemail”, which is just like before except that they actually left a voicemail.  Maybe even “jumped out of voicemail” to tag legs that went to voicemail but then transferred themselves out again.  This is a little more tricky –  these legs should be ones that went to voicemail, but which there is no “on hook” party – i.e. no  one actually hung up at that leg.

There are two things to be aware of –

  1. Make sure that each call leg is matched to only one leg type.
  2. These are leg types, not call types.  They operate on individual legs, not on what you or I think of as “calls”.

For the former: there should be no overlap on an individual leg, that gets weird, and may very well behave incorrectly or break something.  We do try to test for such overlaps in the Health Check page (under “Setup”), but it’s easier to just make sure they don’t overlap in the first place.  This means you shouldn’t have a generic “went to voicemail” leg and also a “went to voicemail and left message” leg – because a leg that went to voicemail and left a message would pick up *both* legs.  In that case, just redefine the more general one to be “not what that more specific one is”, so “went to voicemail” becomes “went to voicemail and didn’t leave a message”.  (This is in the example below, so if that sounds confusing perhaps continuing on will clear it up!)

For the latter: We hope to implement a call types feature on top of leg types and other functionality in the future, but baby steps.., so stay tuned.

Now that we understand what they’re about, let’s jump in to a short example!

Voicemail calls example

Let’s build a leg type for calls that ended in voice mail, and another for calls that ended up getting hung up on when they went to voice mail.

Step 1: Find your voicemail calls

Step 1.1: Define what a voicemail call is.

The first task is to define what it means “to end in voice mail”.   This is dependent on how your calls get routed and thus varies from place to place, but we’ve found several common threads in most people’s environment which I’ve outlined below:

device_type=”unityvm”

If you used the default voicemail naming scheme, you should be able to see voicemail by looking for device_type of “unitvm”.  This is the most commonly needed search for finding voicemails.

on_hook_party=”caller”

A leg which has the on_hook_party set as the caller means this is the leg where the caller hung up and thus terminated the call.  This helps determine if they *ended* at voicemail or if they then hopped elsewhere via some menu option.

deviceName=X

Underneath our created “device_type” is an assumption that the default voicemail naming convention was followed, specifically that voicemail devices are named like “CiscoUM-VI*.”  If “device_type” never says “unityvm” even though it should, this is probably the issue.  The resolution is to just use the deviceName(s) that you configured, perhaps with wildcards, like deviceName = MyVoiceMailSystem*

Step 1.2: Construct and validate the search

In our example, let’s assume that when the device type is the default “unityvm”  and the calling party hangs up, the call is one we want tagged as voicemail_left_message or voicemail_abandoned.

To test this, let’s open up Browse Calls, then in the field “other search terms” type in device_type=”unityvm” on_hook_party=”caller”

Review that list, make sure it looks right!

Now we have to decide on a duration to use – I’m going to pretend 5 seconds is our cutoff.  If the person was in voicemail for more than 5 seconds, they left a message.  If 5 seconds or under, they hung up right away.  Your own threshold may be different, but it seems between 5 and 10 seconds is the most common range used.

This gives us two non-overlapping cases:
When they “hung up” on the voicemail – device_type=”unityvm” on_hook_party=”caller” duration<=5
When they left a voicemail – device_type=”unityvm” on_hook_party=”caller” duration>5

Again, test both of those using search, make sure they look correct.  You might have to leave yourself a few voicemails – and abandon a few – to see how the duration should be set.  I recommend testing with some coworker who happens to not be at their desk.  Most folks feel loved when they come back from a break and find someone left them a few voicemails!

Step 2: Building leg types

Now that we have our searches, let’s build some leg types!

  • Click Settings, then Event Types.
    • We are going to assume you have no leg types already – if you did, search for them by typing “leg_type” in the search box and pressing enter, then review what you have to make sure we aren’t duplicating legs.
  • Click the green “New Event Type” in the upper right.  Fill it in as such:
    • Name: leg_type_voicemail_abandoned
    • Search: device_type=”unityvm” on_hook_party=”caller” duration<=5
    • (Note the initial “leg_type_…” in the name is important, it’s how our app knows these are for it!)
  • Click Save

Now, build the “left_voicemail” version.

  • Click Settings, then Event Types.
  • Click the green “New Event Type” in the upper right.  Fill it in as such:
    • Name: leg_type_voicemail_left_message
    • Search: device_type=”unityvm” on_hook_party=”caller” duration>5
    • (Note the initial “leg_type_…” in the name is important, it’s how our app knows these are for it!)
  • Click Save

Step 3: Testing.

Click back in your browser a few times to get back to your search, or reselect the Cisco CDR Reporting and Analytics app then go to Browse Calls.

If you do not see the field “leg_types”, click “Fields” in the upper right, search for “leg_type” on the left and add it into the right pane.  Then obviously click Save in the field selector.

As long as any calls matching the search we built above are in the results, you should see leg_type populated.  Fiddle with your timeframe a bit if you need to.

Step 4: Using Leg Types.

Now that we have leg types defined for a few cases, we can search for those using the ‘other search terms’ field.

Rather than bore you with prose, how about I just make a little table with some examples and see how that looks?

 

To see all calls that have: Search this:
Any leg_type defined
leg_type="*"
A leg_type of “voicemail_left_message”
leg_type="voicemail_left_message"
A leg_type starting with “voicemail…”
leg_type="voicemail_*"

The neat part is that though these are defined on individual call legs, those legs roll up into calls and keep their call legs as part of them.  Searching for leg types of X means the app returns your *calls* that include legs of those types.

 Additional possibilities:

This is by no means complete, but some random thoughts on leg types:

  • tagging legs that were placed to your call center as perhaps “call_center_received”
    • split that into “call_center_received”, “call_center_abandoned” and “call_center_no_answer”
  • tagging a certain DID block with “incoming_sales_took_call”
    • NOTE that “OR” is OK, but put parentheses around them, like “(finalCalledPartyNumber=7344 OR finalCalledPartyNumber=7345) duration>=15 on_hook_party=*”, which would legs that were to either 7344 or 7345, lasted more than 15 seconds, and where someone hung up without transferring (so they didn’t get transferred away).

There are many possibilities for building and using these and we’d love to see the system you come up with!

 




-->

Post a Comment

You must be logged in to Post a Comment.