Reception phone best practices doc?

Unanswered Question
Aug 24th, 2010

All,

Do we have a best practices document, or similiar, that outlines best practices for setup of a reception phone user?

Thanks, John

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
antyeung Thu, 08/26/2010 - 20:49

I don't think there is a best practice doc, but there are several forums posts throughout the community that you can take pieces of advice from here and there. I think the use of a receptionist phone can vary greatly from one office to another it really depends how you plan to use the phone which would guide you how to configure it. If you have specific requirements or needs it may be better to post those any we can help suggest what the best way is to configure the phone.

Thanks,

Anthony

lawrence.david Sat, 08/28/2010 - 09:06

John,

Getting a receptionist configuration that meets your customer's needs and fits into the UC500 configuration can be complex.  Starting from first principles, what are you trying to accomplish?  (I assuming that you are not using the add-on for a Windows-based operator console).

1. Will incoming calls go to an auto-attendant where the caller selects zero to go the receptionist or will calls be delivered to the extension of a live person?

Many organizations are uncomfortable sending their callers directly to an auto-attendant.  We have non-profits that are concerned their donors may get lost in the auto-attendant.  Other organzations want the ability for callers to go directly to the right party.

2. Is there a single receptionist position or is the job shared by different people?  If the job is shared, do the same people share the job all the time or are there different people assigned at different times?

It's easier if one person acts as the receptionist all the time, but for small organizations we've found this is often a shared responsiblty.  Some have a dedicated person during particular parts of the day, while others have a schedule tahat rotates responsibilty.  If there is a full-time or mostly full-time position, you could simply have all calls go to that position and then use Pickup or Group Pickup for others to pick up a call when they hear it ringing.

You can also put an extra button on all potential operator phones as a share line that lets all of these users pick up the call at any time.  The drawback is that the default behavior is this rings at every position making the environment more "noisy" and potentially interrupting the concentraion of those not currently on duty.

Prior to the 8.0.4 software pack, you could configure buttons for silent ring through CUE, but that was removed in the latest release.  (The UC540 and UC560 are supported for CLI configurations).

It's possible to use a hunt group to distribute the call to every potential receptionist, but this rings their personal extension which can confuse the person receiving the call as to whether it is for them personally or for the organization. You can use a separate button for the operator position and still use a call group, but you can accomplish the same thing with a shared line, so a call group might be overkill.

A BACD can aso be used for the receptionist position, queuing calls for a busy position.  However, their is no way to opt-out to voice mail once the caller is in the queue making this a less acceptable choice (IMO).  BACD seems to work etter for support positions and the 8.0.4 release now allows to use HLog to log in and out of BACD answering responsibilities.

3. What is the maximum number of incoming calls the receptionist needs to handle simulataneously and what phone will the receptionist (or receptionists) be using (SPA50x, CP_79xx, etc)?

One thing that wasn't obvious to me was that the SPA50x and SPA525 are limited to two call paths on a non-overlay button.  By default, they also reserve one of the two channels on a button for an outbound call (so you can transfer the incoming call),  If you only provide one receptionist button they can b limited to one call at a time and everything else gets CFB to voice mail.

You can use octo-line capable phones, but remember that only the primary extension can be configured for octo-line.  (I believe there is a future release that will allow octo-line capability on phones that support it for other buttons.  I also believe the ability to support octo-line capbility may be hardware specific, so if the phone you are using now doesn't support it, it probably won't do so in the future.

If you use a shared line or an additional button and a call group to share receptionist responsibilities, you can get around the multiple simultaneous calls issue, but the incoming calls will be ringing only at nn-busy stations.

You can also stack call appearances by creating some shared line appearances on a "fake" phone (create a new phone in CCA with a made-up MAC address) and then stacking them as an overlay button on receptionist positions.  This can get around two channel limitations.

It also helps if you traing recetioists to use call parking instead of hold.  Call parking releases the call from the recpetionist's phone so she can take more incoming calls.  They just need to keep track of who is on what line.  If there is a side car attached to their phone, you can program extra buttons for monitoring call park extensions.  That makes it easy to retrieve parked calls.

4. Is different handling required during busies shours and after business hours?

This can be handled by defining a busines shours schedule and then creating daya and night call call handling if the organization uses an auto-attendant.

You can also configure the nght bell to change how incoming calls to extensions are covered.  This can be switched on command so if the receptionist leaves their position, you can change where the incoming call rings.

5. How does voice mail for the receptionist need to be retrieved?

Some calls are going to end up in voice mail.  When they do, how do you wantmessages to be retrieved?  If you've used a shared line they'll be in a general delivery mailbox by default.  In some other configurations, you could end up with a regular voice mail box with its own extension number and password.  You'll also need to consider how to get a Message Waiting Indicator (MWI).

That should be plenty for now.

Dave

SteveOrfanos Sat, 08/28/2010 - 13:59

Hi David

What would be the best way to configure a reception phone which will be receiving incoming calls directly and would have the capability of answering 4 incoming calls to the main number. Calls missed will be sent to voicemail and the reception phone would have to monitor MWI. Phone SPA525G with sidecar to monitor extensions.

My ideas:

A blast or hunt group with the main number as the pilot number and four dummy numbers presented on the reception phone keys. Not sure how MWI would be presented to reception phone.

Creating multiple dummy numbers of the reception DN and sharing them on keys on the reception phone or overlaying them. I think this method would present MWI on reception phone.

This is my first UC500 deployment and any other suggestions would be appreciated.

Steve

lawrence.david Sat, 08/28/2010 - 17:31

Steve,

I am only a couple of deployments ahead of you with IP Phones, so keep that in mind.  There are others in the community that have a lot more experience than I do with Cisco IP Phone systems.

1. What phone will the receptionist staion have and will there be a side car with additional buttons?

If you are using SPA50x or SPA525 phones, you'll have to deal with the 2 channels per button limit for call appearances.  If you'll have an octo-line capable phone, you can probably make a simpler implementation.

I personally like to make the receptionist/operator position a separate button from that person's primary extension.  That way they know by which button is flashing if it is a personal call or a receptionist/operator call.

This also separates personal messages from company messages for the receptionist.

If you make the additional button a shared line, others in the compnay call also have the same button added to their phone to assist with receptionist responsibilities without having to use pickup or group pickup to answer the call when the receptionisty is away.

If there isn't anyone else sharing receptionist responsibilities, a call or blast group is unnecessary.  You can simply forward calls to the receptionist/operator extension button (again, not the primary extension) for each incoming FXO or SIP trunk..

If you create a fake phone in the voice configuration dialog of CCA, you can define multiple shared lines on the fake phone, then create an overlay button on the receptionist's phone to handle the incoming calls for all of these shared lines.  Set Call Forward No Answer (CFNA) to voice mail on each shared line to the last shared line from the fake phone using the direct to voice mail prefix.  Set Call Forward Busy (CFB) on each shared line in the sequence to the next shared line.  On the last shared line, set CFB to Voicemail.  This will allow four separate calls to be received simultaneously before going to voice mail. If the receptionist can't get to one, it will go to voice mail naturally.

Do not enable a voice mail box except on the last shared line in the sequence on the overlay.  The receptionist (and anyone with that last shared line or the overlay on their phone) will have a MWI indication and be able to retrieve messages from that General Delivery Maibox (GDM) using their personal voice mail user name and password.

If there is a side car on the receptionist's phone, you can also create buttons for multiple call park positions.  Make sure the the receptionist knows the difference between Hold and Park.  (On hold, only the recepitonist can retrieve the call.  When Parked, other users can retrieve the call if they know where it is parked.)

2. How many other phones on the site?

If there is a side car for the receptionist phone and a small number of phones on site, I like to create Monitor or Watch buttons for each phone.  Monitor buttons only watch one extension, but Watch can tell if any button on the phone is in use.  I like using Monitor because you get a MWI for the extension which can be useful information for the receptionist when users with local voicemail boxes call in.  (That's true on the 7956 and 7916 sidecards, I have't tried this on SPA500 sidecars).  That way the receptionist can let them know if they have any new messages.

The receptionist can also use these buttons to identify the destination for a call transfer or to intercom the user at that phone.

3. What was their previous phone system?

I find that users familiar with key systems miss having buttons for each incoming line.  Frankly, it's not very efficient to have the whole office watch every incoming call.  It break their "flow" and the multi-tasking actually makes getting their primary job done more difficult.

4. Do they need a Paging capability?

I like to create a paging group on well-placed phones (kitchen, conference room, distributed extensions) so that someone wandering around the office can hear the receptionist announce they have a parked call.  This can be a negative in some environments, so check before implementing paging.

One final point, try to fully configure the phone system and all phones in you compter lab before going on site.  It is easy to create a situation onsite that can require a significant amount of time to resolve and might need a call to support.  It can also take some time to get familiar with how a specific deployment will work so you can teach it.  Both of these are much easier to do in the privacy of your own office.

Since we try to deploy switches and sometimes an SA500 at the same time, we've acquired small desktop/portable racks with 8 or 12 U from Middle Atlantic and a rack mountable power strip for initial configuration.  We then just take that rack on site and move the components to the customer's location already configured.

I would also like to hear ideas from other Cisco partners and support engineers.  Please contribute to this discussion.

Dave