Well, it sure sounds like they don't actually have a recorded voice name - by far and away that's the most common cause of the exact behavior you talk about. But if you're absolutely sure that they have a valid recorded name then something else must be going on.
The first thing to check is if the name dialer you're going through has a limited search scope. By default it'll show everyone on the local box but it's possible to limit it to members of a COS or a public distribution list or the like. If this is the case, make sure Petroski is included in that scope. If it's a public distribution list it may take a while for the membership information to propogate (this has to be manually "flattened" by us on a background thread).
The next thing to check is the DTMF spelled name fields for the user - if their name has changed of late this could come into play. So check the actual digits you're using to search for the user - presumably you're dialing 738 for "PET" here - and I'm also assuming the directory handler your using is setup for last name then first name spelling. So go into SQL (you can use enterprise manager or CUDLE in your Tools Depot), open the Subscriber table, find Petroski in your subscriber list - look at their "DTMFNameLastFirst" column - it should start with 738 - if not, there's a problem. If you go update the first and last name for that user and save it (just edit the field and put it back and then press save) it'll force a recalculation of that spelled name field.
if neither of those are the case and you've double checked the users voice name and "list in directory" status then I'd suggest opening a TAC case since you've run into something new...
