Genesys Cloud - Main

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Hi @Paul Simpson

Definitely, I would go with option 1 as DTMF is a hard limit. We used this option with clear instructions that the entered payment amount should include both dollars and cents. True, after the payment amount is entered you have to do a bit of finesse as you need to play it back to confirm it. I would say verification and confirmation of the entered amount is a must.  First, from the entered amount (Task.payment_amount) you need to take the dollar value, then append ".", and at the end append the cent value. For example, something like this: 

Append(Substring(Task.payment_amount,0,Length(Task.payment_amount)-2), ".", Substring(Task.payment_amount, Length(Task.payment_amount)-2, Length(Task.payment_amount)))

After this, it can be easily converted to a currency using MakeCurrency(ToDecimal(YOUR_VARIABLE), "USD") before you play it back. 

One question though: is your payment IVR going to be a self-serve only?  

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Thanks, Tatjana,

Yeah, we are leaning towards Option 1. At the current time, this is part of a Self-Serve IVR, although down the line we are looking at using a Secure Flow to process payments from agents.

The conversion of the input data to usable data isn't an issue, it's more the hassle of having to then provide the caller the ability to confirm and re-enter if required. Not difficult, just tedious! 😉 In PureConnect, you could tell it to read the data back for confirmation as a dollar amount, but sadly this is yet another feature missing from Genesys Cloud.

I guess I had just hoped that someone had a really cool, inspired, or unusual way to do this, or knew of some built-in feature that I am unaware of!

Hi @Paul Simpson

Definitely, I would go with option 1 as DTMF is a hard limit. We used this option with clear instructions that the entered payment amount should include both dollars and cents. True, after the payment amount is entered you have to do a bit of finesse as you need to play it back to confirm it. I would say verification and confirmation of the entered amount is a must.  First, from the entered amount (Task.payment_amount) you need to take the dollar value, then append ".", and at the end append the cent value. For example, something like this: 

Append(Substring(Task.payment_amount,0,Length(Task.payment_amount)-2), ".", Substring(Task.payment_amount, Length(Task.payment_amount)-2, Length(Task.payment_amount)))

After this, it can be easily converted to a currency using MakeCurrency(ToDecimal(YOUR_VARIABLE), "USD") before you play it back. 

One question though: is your payment IVR going to be a self-serve only?  

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Hi Paul,

Oh, the realm of possibilities sometimes has boundaries :-) And you are right, about the data conversion. 

Probably you already explored the option of the amount to be entered on the agent script in case you go with the Secure Flow process payment initiated by the agents. 

Thanks, Tatjana,

Yeah, we are leaning towards Option 1. At the current time, this is part of a Self-Serve IVR, although down the line we are looking at using a Secure Flow to process payments from agents.

The conversion of the input data to usable data isn't an issue, it's more the hassle of having to then provide the caller the ability to confirm and re-enter if required. Not difficult, just tedious! 😉 In PureConnect, you could tell it to read the data back for confirmation as a dollar amount, but sadly this is yet another feature missing from Genesys Cloud.

I guess I had just hoped that someone had a really cool, inspired, or unusual way to do this, or knew of some built-in feature that I am unaware of!

Hi @Paul Simpson

Definitely, I would go with option 1 as DTMF is a hard limit. We used this option with clear instructions that the entered payment amount should include both dollars and cents. True, after the payment amount is entered you have to do a bit of finesse as you need to play it back to confirm it. I would say verification and confirmation of the entered amount is a must.  First, from the entered amount (Task.payment_amount) you need to take the dollar value, then append ".", and at the end append the cent value. For example, something like this: 

Append(Substring(Task.payment_amount,0,Length(Task.payment_amount)-2), ".", Substring(Task.payment_amount, Length(Task.payment_amount)-2, Length(Task.payment_amount)))

After this, it can be easily converted to a currency using MakeCurrency(ToDecimal(YOUR_VARIABLE), "USD") before you play it back. 

One question though: is your payment IVR going to be a self-serve only?  

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

Tatjana,

"Oh, the realm of possibilities sometimes has boundaries" you're not wrong there, LOL!

Yes, although at the moment, if agents are taking payment, it will be manual. This is very much part of a self-service option.

Thanks for your thoughts.

Hi Paul,

Oh, the realm of possibilities sometimes has boundaries :-) And you are right, about the data conversion. 

Probably you already explored the option of the amount to be entered on the agent script in case you go with the Secure Flow process payment initiated by the agents. 

Thanks, Tatjana,

Yeah, we are leaning towards Option 1. At the current time, this is part of a Self-Serve IVR, although down the line we are looking at using a Secure Flow to process payments from agents.

The conversion of the input data to usable data isn't an issue, it's more the hassle of having to then provide the caller the ability to confirm and re-enter if required. Not difficult, just tedious! 😉 In PureConnect, you could tell it to read the data back for confirmation as a dollar amount, but sadly this is yet another feature missing from Genesys Cloud.

I guess I had just hoped that someone had a really cool, inspired, or unusual way to do this, or knew of some built-in feature that I am unaware of!

Hi @Paul Simpson

Definitely, I would go with option 1 as DTMF is a hard limit. We used this option with clear instructions that the entered payment amount should include both dollars and cents. True, after the payment amount is entered you have to do a bit of finesse as you need to play it back to confirm it. I would say verification and confirmation of the entered amount is a must.  First, from the entered amount (Task.payment_amount) you need to take the dollar value, then append ".", and at the end append the cent value. For example, something like this: 

Append(Substring(Task.payment_amount,0,Length(Task.payment_amount)-2), ".", Substring(Task.payment_amount, Length(Task.payment_amount)-2, Length(Task.payment_amount)))

After this, it can be easily converted to a currency using MakeCurrency(ToDecimal(YOUR_VARIABLE), "USD") before you play it back. 

One question though: is your payment IVR going to be a self-serve only?  

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA

I'd probably write a handler, like in class. 

Oh, wait....

Tatjana,

"Oh, the realm of possibilities sometimes has boundaries" you're not wrong there, LOL!

Yes, although at the moment, if agents are taking payment, it will be manual. This is very much part of a self-service option.

Thanks for your thoughts.

Hi Paul,

Oh, the realm of possibilities sometimes has boundaries :-) And you are right, about the data conversion. 

Probably you already explored the option of the amount to be entered on the agent script in case you go with the Secure Flow process payment initiated by the agents. 

Thanks, Tatjana,

Yeah, we are leaning towards Option 1. At the current time, this is part of a Self-Serve IVR, although down the line we are looking at using a Secure Flow to process payments from agents.

The conversion of the input data to usable data isn't an issue, it's more the hassle of having to then provide the caller the ability to confirm and re-enter if required. Not difficult, just tedious! 😉 In PureConnect, you could tell it to read the data back for confirmation as a dollar amount, but sadly this is yet another feature missing from Genesys Cloud.

I guess I had just hoped that someone had a really cool, inspired, or unusual way to do this, or knew of some built-in feature that I am unaware of!

Hi @Paul Simpson

Definitely, I would go with option 1 as DTMF is a hard limit. We used this option with clear instructions that the entered payment amount should include both dollars and cents. True, after the payment amount is entered you have to do a bit of finesse as you need to play it back to confirm it. I would say verification and confirmation of the entered amount is a must.  First, from the entered amount (Task.payment_amount) you need to take the dollar value, then append ".", and at the end append the cent value. For example, something like this: 

Append(Substring(Task.payment_amount,0,Length(Task.payment_amount)-2), ".", Substring(Task.payment_amount, Length(Task.payment_amount)-2, Length(Task.payment_amount)))

After this, it can be easily converted to a currency using MakeCurrency(ToDecimal(YOUR_VARIABLE), "USD") before you play it back. 

One question though: is your payment IVR going to be a self-serve only?  

Thanks, Anton!

Yeah, unfortunately, DTMF is a hard limit at the moment. I'm leaning towards Option 1 as it seems to be easier to implement, although if we want to verify the amount, it will require a bit of finesse!

Anyone else have any thoughts or neat tricks?

Great question.

We certainly have used option 1. Which requires very clear customer instructions.

We've also used the method of asking for dollars and cents as two separate prompts.

If DTMF isn't a hard limit, I like using a voice bot, which does a minimum value, can't be less than $1, eg 50cents.

I'm sure there is other ways of doing it out there, but those are the ones I've tried, keen to hear everyone else's thoughts too.

Hi,

Let us assume we have an IVR which includes the capture of a monetary amount (say a payment). How do others do this? As I see it, there are two options...

1. Ask for the amount in cents, followed by a terminating character (so $10.25 would be 1025#) but it does mean whole dollars includes two digits of unnecessary cents (so $3 would be 300#)
2. Ask the caller to use the * as the decimal point. How do we then handle the caller entering more than one *, or more than 2 digits after the *? Also, I know an input can only have one terminating character, but can it be configured to terminate on a #, but capture the *? (It looks like this should work, but the docs say that if either * or # is used as a terminating character, then the other will cause the error path to be taken.)

Of course, there may be other approaches, so what does everyone else think?

TIA