I'm looking for ways that we might improve the experience for users of our Communications Manager systems. In particular, I'm interested in User Pages enhancements (e.g., easy config of Single Number Reach), calling/phone features that the community would like to see (e.g., being able to set speed dials from the desk sets themselves) or even enhancements to existing features (e.g., more consistent EMCC across phone models).
To be clear, I'm not looking for everyone's gripe lists or favorite "corner-case" feature, but rather I would appreciate pointers to basic inconsistencies across our phone models (or even protocols) and to hear ideas for well considered features that would enhance productivity and most importantly, make our systems more convenient and a pleasure to use.
Thanks in advance for your input.
I'm a product manager in IPCBU ... and I'm looking for widely felt pain points to address and ideas for novel, useful features.
One issue that comes up all the time in CUCM is the lack of the ability
to set or cancel Call Forward All from any line on an IP Phone other than
the Primary line 1.There is a feature/bug request open for this problem CSCdr03425
but it never seems to make the cut
Ah, yes .... well, I can tell you it's not for lack of awareness! Priority calls just keep going against me on this one, but I may get a shot at it in an upcoming release. I will certainly keep it near the top of my list for phone features.
I'd say those ccmuser pages want scrapping entirely and a fresh start being taken. They're just not friendly or well laid out.
Also it should be possible to configure most of what's in there from the handset.
Reverse number lookup (at least to the corporate dir/AD, and probably also to the user's personal/speed dial names) is something people often expect.
Yep, I know it. It's hard to completely start over with these things as there are always customers who want you to drag everything (features, not design) along behind. But you will see some moderate changes in the 9.0 release (home page w/all your speed dials for a phone listed up front, improved directory, new CSS theme and look, etc.) and with any luck, MUCH more significant changes in the 9.5 release. We will also spend some effort to get better integration with the clients and continue to build out our UDS API so that 3rd party developers can begin to offer alternatives (e.g., apps for your Cius and widgets for Open Social frameworks).
Handset changes take more coordination, resources and time so they will lag a bit. But I am looking at obvious benefits, like being able to set speed dials from the phones themselves.
Something necessary is the ability to add at least a secondary number for each user.
One should be able to have the GSM number directly from the directory on the phone itself.
Other thing, ablity to use only number for every field in the login/pwd fields from the phones.
if not possible, at least the numbers should appear first. before the wildcards.
One thing available on Alcatel phones wich is really appreciated by the end users :
the phone have buttons with speed dials(...) as Cisco phones but you can change by 5 times the screen of the phone by scrolling down (with a button).
That means that you can have 5 x 5 buttons on a single phone without an extension.
For the CUCMExpress, something needs to be done ont the web page style (for admin and users).
I'm not sure what you mean by "adding a secondary number for each user"? Do you mean in your personal address book? If so, you can do that now, right? Perhaps you could elaborate on this one a bit more?
And for the login/pwd fields from the phones, I presume you are talking about Ext. Mobility, right? I had thought that use of different strings in these fields was controlled by admin policy which you could change? I'll look into it, if not.
Alcatel's use of a scrolling button template for speed-dials is interesting -- it has some advantages/disadvantages vs. our analogous features (abbreviated dials, speech connect, and KEM's). I'll pass this along to the phone designers.
CME is handled by a different team, in a separate business unit. But if you'll tell me more about the issues with the web page style for admin/users, I'll be sure to the information along.
Hi Dave. I'm new to UCM in that we are just finishing having a UCMBE 5000 8.6 installed at my business which replaced a minagerie of phone systems.
My high level observation is that, for reasons that baffle me, there are features that CME gets right that UCM gets wrong or doesn't have at all. Here's my top 4 so far:
1. Lack of 2-way intercom. In the CME world, this is known as Dialable Intercom I believe. UCM only allows for a whisper intercom out of the box. I would have great difficulty believing it would really be that hard for Cisco to have an option on the intercom setup to allow the phone to answer unmuted. I am told by the Partner installing this system that this is their number one feature request from customers.
2. No Call Park reminder notifications. This one is also baffling. In CME you can program options for the park slots so they will notify the DN that parked the call that the call is still parked after a certain amount of time, and then after a certain timeout you can transfer the call somewhere (either back to the DN that parked the call or to another DN). For some reason, in UCM this option simply doesn't exist. It is frankly much more logical in CME. There is something called Park Monitoring but appears to be limited to a select few Cisco SIP phones, leaving the Skinny world out in the cold.
3. See Rob Huffman's post above, that one has caused us heartburn as well.
4. It would be nice if you could figure out how to duplicate or replicate the equivalent of the "Night Service" feature in CME so that you can toggle the night service on a set that is a member of a broadcast group and have the forwarding work. CallFwdAll doesn't trigger on an incoming call to a broadcast group.
I know some people will react with "well it sounds like you should have bought a CME based setup instead," I had a UC560, and I already like the UCM much better. I just wish it carried over some of the useful features, especially ones that make call handling easier whether you're a small business or an enterprise.
If you'd like more detail please feel free to contact me, I'm happy to help.
agree with Bill
CME support for example paging, night bell and simple queuing while CUCM not for now i heard this might come with version 9 but not sure if it gonna be addressed
on the other hand, the CCM user page not sure if cisco can make it to be accessible via a softkey within the phone where users can login and change settings as desired like, forward all, SNR ..etc will be very nice i think
Hi Bill, Marwan,
I'll look into what it would take to modify our current 2-way paging to allow for phones answering unmuted. I know that feature hasn't been touched in quite awhile. And as for simple call queueing, yes, that will be included in the 9.0 feature set, due out this next summer. A night bell was being designed into the BE3K program (at least when I was running it), but for larger CUCM installations, we have generally relied upon Unity Connection to provide those services. As you have noted, there are a number of small business features which just don't scale into the enterprise feature set though perhaps we might be able to adapt them and make them available on the mid-range 5K/6K platforms.
With respect to Call Park notifications, there is an associated reversion timer with each parked call and when it triggers, the call is sent back to the parking DN. I'm trying to understand why that is not enough or what more might be needed?
Lastly, while we elected many years ago to pursue a web-page strategy for setting user options and preferences, the direction has been towards providing these services in collaboration clients, whether they be Sametime, MoC or our own CUPC, Cisco Mobile, and now Jabber. We will continue to make significant enhancements to our web pages as we're both due for a refresh and need much better ease of use. But a higher priority will be placed upon client features, and "on phone" features may lag somewhat (excepting where clients will be co-resident, e.g., Cius), though you will see us start to address some of the items I have discussed above.
It would be great if you could get a 2 way intercom built into UCM. For what its worth I built a 2 way intercom system thanks to some pointers from Rob Huffman by creating a separate Partition and CSS and assigning DNs to auto-answer. Its kind of a kludge but it works. It really seems like Cisco could just add a simple option to answer muted or unmuted in the "real" intercom config though and save us all the trouble with minimal effort.
For Night Service/Night Bell, let me give you my scenario so you can understand what the problem is. We use an answering service for night calls, and we call-forward to them after the staff leaves. This is usually at 5pm, but not always, so using schedules is not optimal. Each office call-forwards to a different answering service phone number, so the answering service knows which of our offices the call is coming in for. The problem is that we really need to use broadcast groups at these offices for incoming call flow, but if we set the incoming answer DN to the broadcast group, then call-forward all doesn't work when we need to send them to the answering service. The solution, which doesn't work very well, is to have incoming calls ring a primary DN on the receptionist phone and then forward busy/no-answer down to a broadcast group if the phone isn't picked up quickly. It confuses whoever is answer the phone at the receptionist desk because if the call is answered quickly enough it hunts down to another key on the phone, anyway, its a mess. If you guys just added a night service function identical to CME's, this would vastly simplify our life.
For Call Park notifications, I'm not sure how I can explain it any better. If our receptionist parks a call intended for another staff member, but that person doesn't answer the phone within the timeout (lets say a minute), I want the phone to notify her that the call is still parked so she can make a decision on what to do with it (either pick back up and inform the person that somebody will be with them shortly, or just keep being aware that it hasn't been addressed yet). By just triggering a reversion and sending it back to her, there's no decision to be made, she has to answer it, and if she has multiple calls already going, the last thing she needs is the parked call ringing off the hook, instead she just needs to be notified its still parked. Additionally, if a staff member parks a call rather than putting it on hold to go look something up, and doesn't get back to their desk in time for the reversion timer, then the call transfers back to their desk phone and goes to voicemail. Well, that's not good. I know in CME you can also configure where you want the parked call to revert to in the event it reaches timeout (I haven't looked yet), if that feature isn't in UCM, it should be.
Dave, I would like to thank you for reaching out to us on these issues and reading/listening to the feedback. This is an awesome sign. If you want more clarification please let me know, I'd be happy to try and give you additional scenarios that perhaps you could simulate in a lab so you can see what I'm talking about and get a firsthand idea of what I'm seeing. Thanks.
First of all, thanks for asking. It's nice (and refreshing) to see someone at Cisco asking the patners (and therefore by inference Cisco's customers) what features would make the products better to use.
A few thoughts - which I'm trying to relate to the user experience thing.
1. Call Forwarding in a hunt group. I've lost track of the amount of time customers have asked me if there is a way for CUCM to "honor" call forwarding settings for a DN that is a member of a hunt group. Particulalrly useful when you may have office staff working remotely and the business still wants them to field calls (e.g. on a cell phone). You can kind of configure around this to a fashion with mobility, however IMHO this is a bit of a sledgehammer to crack a nut.
2. Agree with previous posters - paging would be really useful. In my CME deployments, this feature gets used frequently and it's difficult to have to explain why it doesn't work in CUCM.
3. Slightly away from the user experience (although it is all related), MTP support for individual DNs. CME has this feature which allows us to hairpin audio streams from remote handsets particularly those connected over VPNs. Incredidbly useful as it avoids us from having to establish a full mesh of VPN tunnels between remote offices. No such feature exists in CUCM which creates a load more work when setting up this kind of deployment. Impacts users as if I had £1 for each call I get from a client saying two users in remote offices can't hear each other, I'd be, erm a little better off than I am now.
4. Another vote for reverse number lookup. Again, something supported on CME, not supported on CUCM without having to configure TCL scripts on H.323 gateways, which is never fun.
I'l have a further think and come back with anything else.
Thanks again. The fact that someone from Cisco has asked the question has made my morning.
Now I just need someone from the Smartnet team to do the same.....
I'd like to talk to you further about your items #1 and #3, as I have had some conflicting feedback regarding CF out of hunt groups and am not quite sure I understand the use of MTP's you are suggesting that CME has. I'll send you a separate email to see when you might have time to talk.