Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

So when I test this in Ask for Intent, it doesn't seem to map to the slot with a value, but it does take me down that slot's path.  In my screenshot, I have Ask for Intent as noted in my previous post.  If I say only actual numbers, one digit at a time, it works fine. 

Examples:

12345678 matches the CaseNumber Intent AND writes that value to the slot

1 TEN 45678 goes down the CaseNumber intent path, but then it hits the Ask for Slot right below, which tells me it didn't do something properly.

One-Twenty Three-fifty-four seventy-five goes down the Case Number intent path, but also hits the Ask for Slot step instead of having the Slot filled from Ask for Intent.

If I'm expecting too much form the Ask for Intent step, I think I can just force the caller to say "case" and then send them down the CaseNumber path.  It already works like that, so I'd just have to re-word my prompt on the Ask for Intent step.

 

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

can you try removing the /b and just use [0-9]{8}

So when I test this in Ask for Intent, it doesn't seem to map to the slot with a value, but it does take me down that slot's path.  In my screenshot, I have Ask for Intent as noted in my previous post.  If I say only actual numbers, one digit at a time, it works fine. 

Examples:

12345678 matches the CaseNumber Intent AND writes that value to the slot

1 TEN 45678 goes down the CaseNumber intent path, but then it hits the Ask for Slot right below, which tells me it didn't do something properly.

One-Twenty Three-fifty-four seventy-five goes down the Case Number intent path, but also hits the Ask for Slot step instead of having the Slot filled from Ask for Intent.

If I'm expecting too much form the Ask for Intent step, I think I can just force the caller to say "case" and then send them down the CaseNumber path.  It already works like that, so I'd just have to re-word my prompt on the Ask for Intent step.

 

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

can you try removing the /b and just use [0-9]{8}

So when I test this in Ask for Intent, it doesn't seem to map to the slot with a value, but it does take me down that slot's path.  In my screenshot, I have Ask for Intent as noted in my previous post.  If I say only actual numbers, one digit at a time, it works fine. 

Examples:

12345678 matches the CaseNumber Intent AND writes that value to the slot

1 TEN 45678 goes down the CaseNumber intent path, but then it hits the Ask for Slot right below, which tells me it didn't do something properly.

One-Twenty Three-fifty-four seventy-five goes down the Case Number intent path, but also hits the Ask for Slot step instead of having the Slot filled from Ask for Intent.

If I'm expecting too much form the Ask for Intent step, I think I can just force the caller to say "case" and then send them down the CaseNumber path.  It already works like that, so I'd just have to re-word my prompt on the Ask for Intent step.

 

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

Try adding NO_HINT to that slot.

can you try removing the /b and just use [0-9]{8}

So when I test this in Ask for Intent, it doesn't seem to map to the slot with a value, but it does take me down that slot's path.  In my screenshot, I have Ask for Intent as noted in my previous post.  If I say only actual numbers, one digit at a time, it works fine. 

Examples:

12345678 matches the CaseNumber Intent AND writes that value to the slot

1 TEN 45678 goes down the CaseNumber intent path, but then it hits the Ask for Slot right below, which tells me it didn't do something properly.

One-Twenty Three-fifty-four seventy-five goes down the Case Number intent path, but also hits the Ask for Slot step instead of having the Slot filled from Ask for Intent.

If I'm expecting too much form the Ask for Intent step, I think I can just force the caller to say "case" and then send them down the CaseNumber path.  It already works like that, so I'd just have to re-word my prompt on the Ask for Intent step.

 

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

Try adding NO_HINT to that slot.

can you try removing the /b and just use [0-9]{8}

So when I test this in Ask for Intent, it doesn't seem to map to the slot with a value, but it does take me down that slot's path.  In my screenshot, I have Ask for Intent as noted in my previous post.  If I say only actual numbers, one digit at a time, it works fine. 

Examples:

12345678 matches the CaseNumber Intent AND writes that value to the slot

1 TEN 45678 goes down the CaseNumber intent path, but then it hits the Ask for Slot right below, which tells me it didn't do something properly.

One-Twenty Three-fifty-four seventy-five goes down the Case Number intent path, but also hits the Ask for Slot step instead of having the Slot filled from Ask for Intent.

If I'm expecting too much form the Ask for Intent step, I think I can just force the caller to say "case" and then send them down the CaseNumber path.  It already works like that, so I'd just have to re-word my prompt on the Ask for Intent step.

 

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?

This is EXACTLY the problem I'm having today.  I'm trying to capture license plates, and I get "NINEMNX563"  the challenge with using the 3 alpha and 4 is that trucks have a different pattern.  Any advice on the best way to accurately capture license plates? including vanity?

I almost never use built in types, but choose to use REGEX so I can customize input to specific types of information and length.  For Instance if I am looking for license plates and I know it is 3 alpha then 4 numeric, I can use [a-zA-z]{3}[0-9]{5} to specifically listen for the alpha first and then digits second so the oh in abo305oh becomes abo3050 and that not abo3050o.  

I agree with what you have there as it limits input to 8 numbers where Numeric has no limitation on the length.

Should I be using the Regex slot type in this case?  I was testing with this as the value for the slot type.  Are you using the OOTB numeric slot type and getting the positive results?  If so, does this also work within an Ask for Intent step, or just Ask for Slot?  My Ask for Intent has two paths at present.  One covers a "product and interaction intent" path where we look for product and sales/support/billing phrases, and the other is entering case number.  The goal on putting this in Ask for Intent is that we can one-shot route the call if we get enough slot matches from their initial utterance, either by product/intent or by case number.

Right now, my Ask for Intent step is worded like:

You can say things like "GoTo Resolve Support", "Buy GoTo Connect".  If you have a case number, you can say "case or enter it now"

CaseNumberSlot is regex type using this as a matching value \b[0-9]{8}\b

I know I can add more, but I also know it's likely over-engineering it if I should be just using a numeric slot type.

I have great success when I define the slot properly.  For instance, my number 3103502010, I'll vary it by saying "35oh2502010" or "3ten3502oh1oh" et al and rarely see problems recognizing if I have the slot set to look for specific number set like [1-9]{1}[0-9]{9}.  

Hi all,

I'm building a voice bot flow that collects a case number from the caller.  Rather than forcing them to enter it on the key pad, I'd like to also support them speaking it.  This works if I use precise pronunciation of the digits when testing, but I worry about scenarios where a caller may replace "0" with "o", which is pretty common in English language speaking.  Does Genesys properly handle this in bot flows, or do I need to add some string manipulation to post-process the Slot variable before reading that back to the caller?