Best Way To Enter Numbers

[briesmith]

In people's experience what is the best way to configure the response rules when capturing data using VG?

 

Say a value that can be entered can be up to 99; ie two digits in length.

 

Is it best to configure the rule as maximum length 2 and tell the user that when they enter a single digit number they should use the hash key (so they don't have to wait for the timeout before the script moves on)? Callers getting the habit of using the hash key might get confused if they inadvertently use it when they've entered a two digit value and the script has moved on automatically because the filed length has been completed.

 

OR, should the general rule be: set the rule to the maximum field length permissible + 1 (in this case to maximum length 3) and ask the caller to always use the hash key? This approach has the benefit of consistency although on fixed length responses - like an account number or credit card number - the hash key is redundant and can be dangerous. Supposing the caller uses the additional character to enter not a hash key but some other digit?

 

I've tried it all ways round and can't make up my mind; suggestions gratefully accepted.

[Guest Guest_zackrspv]

Just a bit of background for you; we run VG for 10 businesses that we control; all use the same 888 number as they all share the same Tech Support staff. We use the 2 digit frame of mind when dealing with our customers. For example our main menu will ask them to enter either 10 & 11 (main features) or *2 for directory, or *0 for help; it is easier for most of our clients to do this.

 

We have reviewed our call log prior to using the 2 digit frame approach and noticed that most customers simply hang up or press the wrong number of keys; but after switching to the 2 digit frame approach, most (about 85%) of people who call in are routed to where they want to go by pressing just 2 keys.

 

We have sections of our menu where users register their name and ect information for doctor visits, and class trainings, ect, and they enter a user length password of their choice; when they enter that they have to use the hash key (as we make it whatever length they want) and when they call back in they have to as well use the hash key.

 

But, aside fromt hat part, that is the only section of the menu that uses the has key; the credit card authorization, and account access verification section all uses determined length fields; ie we know they will be 16 digits or they will be 9 digits, ect, so we simply just let the customer enter their code and AUTOMATICALLY move on, w/o any interaction from them.

 

Most of our customers say it makes the system appear 'smarter' as the only interaction the customer has is with the system directly, and not with TELLING the system what to do.

 

We will be moving away from DTMF based data entry and using Speech Recognition, because Luminvox SDIS has an API that is usable with VG to incorporate Speech Input into the system. (Though the API reguires alot of VBS programming in VG, but it still works).

 

So from a general point of view; if you have alot of options, and alot of messages to get across to a caller, the 2 digit frame approach is best, after all you can have up to 99 of these choices in 1 menu!; also if you have limited caller responce, ect, then a simple 1 digit frame approach would be best (like press 1 for sales, 2 for support, ect).

 

It all depends on what you want, and what you have to offer. In general, users are already used to pressing the hash key after whatever they enter; however the vast majority of users would simply RATHER NOT press that key as it makes them in control of the system (and any caller will tell you that when calling into a Call Direction Center it is best for the CENTER to appear to be in control (and just ask questions) instead of the caller directing everything). I do apologize for the indepth thing there, it is a concept most won't grasp so quickly.

 

Thanks!

[briesmith]

Thanks Guest_zackrspv

 

My problem though is with unforseeable input. Like, for example, "Please enter your age". How do you program for the response? If they are under ten or over 99? They might enter "9", "99" or "100". If you set the field length for 3 - to allow for the centenarians - the younger respondents (those under 100) will have to wait while the timeout process goes on.

 

If you allow the hash key as terminator then when the 99 year turns 100 they will be confused because entering 1, 0, 0, followed by the hash key - as they did when they were under 10 and under 100 - will be "wrong".

 

If you set the field length as 4 and always wait for the hash key you could get repies of 1000 or more.

 

I'd appreciate people's responses here based on experience of running IVRs.

[Guest Guest_zackrspv]

Well, from experiance with most of our callers, even the old ones; waiting for the timeout is hardly ever a problem; remember, customers are talking to an 'auto attendant'; they expect this 'auto-bot' thingy (lol) to take some time to process their request; with that said, however, let me point out a few things.

 

The vast majority of callers into our IVR system are between 18-30; we do have some that call in over the age of 40; however of those most are between the ages of 60 and 90. (hehe, i love demographics when recoreded, don't you?)

 

From our experiance, if the person knows the information they are entering, it seldom takes them more than 2 seconds to enter the information on the phone; old people, of course, have factors such as sight that limit them, but it still rarely is slower than 2 seconds.

 

So, the timeout function to wait, really is not that big of a concern; a simple 1 second pause or 2 second pause isn't that tragic.

 

As far as entering information that the computer doesn't understand; well, that opens up alot of discussion; ie, perhaps it is an account number that isn't in the database; well that can be filtered out with an evaulate expression or database query module; if, however, it is a key sequence to another menu that doesn't make sence, the system can use the 'false' module to send the person back to the main menu, you can also use the evaluate expression module to check the key sequence, and if it doesn't match one of the accepted norms, well send back to main module.

 

Most people, at least those of resasonable intelligance, will not be confused via the hash key; however entering multiple data in a sequence followed by the hash key is not user friendly and can cause concerns.

 

One example:

 

Bank Of America, for example, makes you enter your account number followed by the pound key; however they do not make you enter your pin or your expiration date followed by the pound key because that would confuse people.

 

This is done by using the information that the customer enters AS THEY ENTER IT based on a set field IE ACCOUNT NUMBER, and returning the correct vaules back to the system once found (so if the unknown numbers get returned, the system will ask the person to reenter the numbers or values untill the correct information is available)

 

But, then of course, you have more concerns: (if there is no set field to lookup: that can lead to invalid information (say a person has a PIN of 1234, and another has a pin of 12345, your VBS call would be invalid if it only returned the 1234).

 

So, in general, what is the best way of handling invalid information? Well, the true/false expressions in any module in VG are wonderful, if it doesn't find what it wants, then send the customer back a menu; if it does, it will take that path; for example: (enter 1 for sales, 2 for tech support) [client enters 3] well the false module would evaulate that as true and send the person back to the same menu to get them to reenter; if they entered either a [1 or a 2] that would take them to those prospective elements. (it works great in our system lol can't vouch for anyone else) VBS makes this much simpler, however, it is nice to use what VG can do first.

 

It is all up to you, the designer; what information do you have that the customer is entering, what information do you need further to that situation; can you cross reference this information via the database to get the correct information out as the customer types it.

 

I hate to type alot, and i do hope that i havn't muddled the question up too much.

 

Thanks!