Sometimes you can get into secret menus if you play the tones for them...
I'm def. gonna try this out. I usually pres & and # a couple of times, because it often skips the useless menus and takes me to a person
Yes. Depending on your OS, it might even have the sound files:
https://pbxbook.com/other/dtmftone.html does. I'll try a company I know takes at least 40 minutes usually :
Also, something that annoys me about VOIP is that they don't take into account the different tones in different regions. Here in the Netherlands we use 425Hz fo dial tone etc. It always feels very emulated because it's a different tone.
It was mainly for doctor appointment reminders, though, so hopefully those called still had their appointments written down somewhere (or also signed up for email reminders).
It surprised me coming from Apple Business Manager. It was unprofessional. Don’t skip the docs, guys!
Result: As expected, my problem wasn’t solved by following their 18-step DUNS/Apple process during the last 8 month. (My problem: My company changed both address and name, they still have both addresses with the old one as primary).
The client really didn't want people sent to live agents if at all possible, as they only had a certain low number of agents and wanted to keep it that way, so we had extra prompts that tried to convince the user to give the app a try first before we did a transfer to an agent, but it was something that could start the process off.
And this was an IVR app for a Fortune 500 corporation, not a small company.
There's almost always a regular language more constrained and useful than .* that contains the entire set of acceptable terms (although sometimes it'll be a strict superset, in which case DFA acceptance cannot constitute complete validation).
A really small example of this is postal codes in Canada. For a long time the norm was to put a hyphen between the two clusters: A1B-2C3 but then at some point a lot of websites decided that's bad and they started rejecting it, often with really obtuse messages. This is just annoying and no one is really well served by it. Canada post doesn't care.
And that's not even getting into 0 vs O and the fact that yelling at the user for entering the wrong one is rarely helpful.
I think most of the time the better thing to do is attempt to normalize and ask the user if the normalization is correct. For a numeric thing like a phone number this is probably stripping out non-numbers (other than + at the start) and putting hyphens back in and validating the number of digits you get back, and presenting it to the user if it differs. More work but feels way less hostile to the user.
I really can't think of any case where changing a "0" to an "O" is a good idea (or vice versa), except like base 58 whre you're explicitly avoiding both.
Either way if you're going to normalize you need a regular language, so I think you're kinda missing the point here on what regular languages mean in this context?
The real point is that you want to have one regular form for the input in your database, but imposing that one that you prefer on your users creates friction when their experience of the world differs.
As for 0 vs. O, in a Canadian postal code it doesn't matter, because there is indeed a very regular language to them: letters alternated with numbers. A round circly thing in a numeric position is a 0 and a round circly thing in a letter position is an O. No matter what. The only time this actually indicates a problem is if the pattern ceases to hold after the round circly thing, in which case it may or may not be the 0/O confusion that's the problem but it was wrong anyways.
I'm not saying you should store it wrong, but if a user enters "HOH-OH0" and you ask "did you mean 'H0H 0H0'?"[1] and they say yes then you've given the user a much better and helpful flow than "Invalid Postal Code, please fill out the form again."
[1] This is a 'real' postal code btw and it goes to a weird santa-letter black hole even though it doesn't indicate a geographical location that corresponds to the north (an H prefix is for Montreal).
A faculty that was, of course, lacking at this particular organization
Good rule of thumb: if a reasonable person calls it a number, but your application is never going to perform arithmetic on it[0], it should probably just be a string.
[0]: Yes, a credit card number can be checksummed, but that's more in the sense of a CC# being a sequence of numbers rather than one int.