No problem,

I know from my engagements with customers they want to be able to track so called "negative events" or events which show the behavior of the caller when problems occur.

To do this we need to log specific value e.g. "045" when the callers hit a step. From the 3 banks I have been involved in this is a pretty common requirement.

We have found this extraordinarily messy in Audium as the base components are fixed, and cannot be extended in a way which makes them flexible.

In terms of a negative event
When a caller enters incorrect information or presses a key out of scope (i.e. menu) then a no match event will kick off.

No Match 1

• We would log 060

No Match 2

• We would also log 060

No Input 1

• We would log 62

No Input 2

• We would also log 62

If third failure is a No Match 3 (combined from any combination of no match/no input)

• We would log 61 and transfer to agent

If third failure is a No Input 3 (combined from any combination of no match/no input)

• We would log 63 and transfer to agent

Problem

-----
To make this work in Audium we would have to turn the no match/no input count down to 1 (so it leaves the component) and record the event type value "no match" or "no input" in a session variable.

The use a counter/decision object to manage this so to log against <2 or 3 when final value is logged when a specific event kicks in.

Implementing this in Audium out of the box means

• The call flow doubles/triples in size

Workaround for today

-----
1. turn dtmf/speech object no match/input count down to 1
2. Capture the event type "noinput", "nomatch" in a global variable
3. Extended the counterwithdecision but with logging facilities "no match 1+2", "nomatch final" and same for no input
4. Loop back into the DTFM/Speech Component so it will play again but complete after 3 tries (using counter with decision type object) - So now we're managing this instead of the component itself.
5. Imagine 200 off pages of call flow and a good 60 off input components that need tracking and you see the nightmare before us.

Impact

-----
Since your no input/no match counts are 1 we the lose the easy ability to use changing prompts against nomatch/no input counts and now have to manage this too. Groan!

If only

-----
If Audium's could write to a variable or log information within the DTMF/Speech input component when the events for occur for
no match 1, 2, 3
no input 1, 2, 3

That would then keep it all self contained in the element.

That would have removed any extended call flows from that component (from 3-8 extra elements) allow us to log information against their own events at every count stage and keep the tapered nomatch/no input count prompts.

• also have an optional event if th "no input / no match" combined count reaches a certain value too!!!! We see this a fair amount on engagements. Again workaround have to be written.

We are feeling a lot of pain on this project.

If you feel you want a direct conversation over the phone, I'm sure that can be arranged, but hopefully it makes sense what I'm writing here.

Many thanks


A noinput event when the caller is unsure or does nothing.

Vance,

its very simple.

In the call flow, we want to write each no input and no match to the log in our own way and also have the option of writing it to a variable.

What isn't right is to achieve a 3 stage no match/no input timeout, we have to lower the nomatch/noinput count threshold to 1, put in a counter/decision process, intercept the event and loop back (if you want your prompts to change progressively to simulate a 3 stage nomatches/no input process, you have to use a dynamic prompt variable too because your threshold is now 1 so it doesn't sound like a repeating parrot).

As suggested, in in the log/data tabs why don't you add a noinput/nomatch event besides the create before and after.

Hi Karl,

It seems that you are asking a couple things in this post:

1) to customize the log for nomatch/noinput;
2) to control the nomatch/noinput that are allowed at runtime based on certain conditions.

Could you please provide a few use cases for the above so that we could better understand that?

Thanks,

John

Thanks but element groups won't make this better.

1. We're using CVP 3, so we should not be using Audium 5 with its set of call services until the next release

2. Secondly every event interaction has different numvalues. Yes we could create session variables but again defeats the object.

My understanding of using groups is if something is reusable great but in this case we are configuring in every case.

One of the weaknesses of element groups is you can't parameterise them as part of a workflow definition. You could create session variables but in our view you should have an object that you can create parameters against and point it to the element group and this parameter object will only point to a parameter group.

That makes the whole thing even better.

I suggest you add that one to your list too.

Parameter Object----------> Element GROUP