Guideline: Collect the parts of the date which are required for your system, rather than always collecting the entire date.

Discussion: Many development platforms provide a built-in date grammar which collects month, day, and year. However, depending on the reason you are collecting the date, perhaps only part of a date, such as month and day, or month and year, will be required. If this is the case, don't force the caller to provide unnecessary extra information. Focus the grammar appropriately because:

• Collecting unnecessary additional information (such as an entire birthdate, instead of just a month and day) could be a potential security risk.
• A shorter prompt could potentially make the call shorter.
• A smaller grammar could potentially make for higher recognition rates.

When providing DTMF backup for date prompts, provide the caller with DTMF backup that matches the way they would customarily write a date in their country. For example, in the United States, people typically write MMDDYY. The caller should be prompted for DTMF backup input in a similar sequence. When confirming a date, have the system say the date in a manner that is customary in the country – for example, in the US, it would be common to say something like, “That's March 4th, 2015 – right?” This gives some additional protection against the possibility of the caller having entered a valid but incorrect date – protection that simply reading back the numbers would not provide (or at least, would not provide as effectively).

Note that there are some probable exceptions to this. For example, if the user is looking at an expiration date on a credit card that shows the month and year as four digits, then it is reasonable to expect callers to say four digits for entry and, if there is a need to feedback the input, to do so with the four recognized digits. Anything else will require users to translate the digits into months and years, which in this case is an unnecessary mental step.