Reassigning '*' within voicemail

[admin_2]

Currently, pressing '*' while in voicemail initiates our main greeting. This can be very confusing to the user since they now hear what you would hear if you dialed in as a non-subscriber. <br><br>Previous posts explained this function as a 'exit to the previous menu' but what I don't understand is why does it not exit to the 'attempt signin' menu? Our call handler routing lists 'attempt signin' first, then our 'main greeting' handler.<br><br>Is there _anything_ we can do to change the action this key takes? Or at least a workaround that when they press the '*' key it takes them back to the voicemail prompt, 'please enter your password'?<br><br><br><br>

[#2]

I'm not sure I get your description here since it's not correct as I read it.

If you at the opening greeting (or any other greeting by default) and you hit * you're going to get the subscriber sign in conversation (you'll hear "please enter your ID" followed by a password if you have one set...). Unless you've remapped the * key default behavior by changing it in the User input section for that handler/user in the SA.

If you're talking about users backing out of their mailbox by hiting *, then yes... when you exit the subscriber conversation you are routed to the opening greeting. Why would you want to go to the subscriber sign in conversation when you just exited the subscriber conversation in the first place?

Or am I misunderstanding your question?


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#3]

The issue is that when the user hits "*" they back out of the voicemail box into our auto attendant greeting, rather than the sign in.

The particular users we are concerned about are subscribers with IP phones. It would make more sense for them to back out to the interface that they came in through in the first place, which is what they got when they hit the "msgs" button on the phone - the subscriber signon.

It is confusing for IP phone users to find themselves at our auto-attendant greeting when they hit "*", and to be honest, I'm not sure why they're ending up there instead of at the subscriber sign-on or even the opening greeting (which is different than our auto-attendant greeting.)

[#4]

I am profoundly and totaly confused by your logic.

I hit the messages button, check my messages, then hit * (why?) and you want to have that user sign right back into their mailbox (the one they JUST came from?) What?! What am I missing here? That just makes no sense at all...


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#5]

Are you calling another subscriber and then pressing * from their mailbox?

[#6]

The original post may not have been clear regarding the issue we have:

1) An IP phone user dials the Unity extension or presses the "msgs" button on their phone. They are connected with the Unity subscriber sign-on.

2) The users signs in, and at some point during their session hits "*", either to exit, or accidentally hits "*". They are immediately ejected from their mailbox into our auto-attendant greeting, which is typically only the destination for external (ie non-ip) or non-subscribers.

Currently our call routing rules dictate that non-subscriber calls (including calls external to Call Manager) get our auto-attendant greeting upon dialling the Unity extension and subscribers go to the Unity sign-on greeting. I would expect that the same thing should happen for users who press the "*" key while in a voicemail session, and the fact that it doesn't is confusing to internal voicemail users.

[#7]

The short answer is no... the * key always goes back out to the opening greeting when you get to the top level of the subscriber conversation... it's supposed to do that. It doesn't dump you to the opening greeting any time you hit * from anywhere in the subscirber conversation, by the way... if you're down in your transfer rules etc... * always backs up one level. The opening greeting is considered one level up from the subscriber conversation and if you hit * again you go to the subscriber sign in conversation and if you hit * again we hang up.

There are legitimate reasons for subscribers to want to be able to exit their mailbox and get to the audio text capabilities (i.e. if they want to look a user up by name in the directory handler if they forgot their extension number or something). I'm not entirely sure why you think this is so confusing.

I have the ability to be able to dictate the destination when callers exit their mailboxes as an item down for the tenant services changes (i.e. different subscriberrs would get sent to different opening greetings depending on what company they work for), we could certainly make it flexible enough to basically say you cannot exit your mailbox. Personally I think that's downright evil UI design but that's just me... These types of changes aren't being targeted until 3.2 or 3.3 I believe and I don't have any schedules for that yet.


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#8]

I see where you're coming from on the role of the "*" key - I had not noticed that it rolls up a level if you're deep in the menu structure - obviously an important feature.

However, it does remain an issue for us, and I'm glad to see that it's on the list (even if it's far down the list.)
It's confusing for the voice mail user because when they hit "*" in their top level voicemail state, they bail into our auto-attendant greeting (not the Unity opening greeting,) which has nothing to do with voicemail (as far as they're concerned) and may leave them confused about how exactly they got there. Ideally "*" at the top level should hang up the call (although if it's done abruptly, such as during a self-enrolment procedure, that would be even more confusing, unless there was an "are you sure?"
prompt ahead of the exit.)

I suppose we'll have to put up with it the way it is for a few more versions.

[chelget]

Our users were confused by being dropped back to the attendant rather than the subscriber sign-in as well.

Excuse my Unity ignorance, but I guess a tag on this question is what is the graceful way for a subscriber to exit a mailbox? Our users are used to having to press a series of key strokes to logout of the previous VM system to ensure their settings were retained and messages were deleted, etc.

With Unity, I was just telling them to hang up, but from these postings it appears that at the top level mailbox menu they should press:
* once to exit to the attendant greeting
* a second time to go to the subscriber sign-on
* a third time to hang up the call and reset the port.

Is this correct?

Thanks

[#10]

yes, that's correct. Unity doesn't have the concept of "session variables" that need to be saved when you exit, changes you make are executed. From anywhere in the conversation if you keep hitting * you'll back up a menu level until eventually the system hangs up (this is based largely on the VMUIF standard for the use of * as up a level and # as skip). If they're deep in a configuration setup menu in the subscriber conversation they may need to hit a few extra *s (i.e. they're in the greeting record menu, hit * to return to settings, * to get to the top level subscriber conversation, * to the attendant, * to sign in and * to hang up).

or, of course, they can just hang up assuming your phone system integration has a disconnect supervision capability (most do).


Jeff Lindborg
Unity Product Architect/Answer Monkey
Cisco Systems
lindborg@cisco.com
http://www.AnswerMonkey.net (new page for Unity support tools and scripts)

[#11]

Sorry - we should have made this clear at the beginning - if a user hits '*' by mistake, or when they're "exploring" the system. Even if they DO hit it on purpose to exit, it does not make sense for them to exit to the auto-attendant, something which they may have never run into before, if they're only an IP-phone user. It's a very awkward and unexpected transition for the user.