In search of the Killer Contact Center Script (UCCX or ECC)!

The “Killer UCCX Contact Center Script”

After your first 100 or so Contact Center Scripts, you begin to wonder if it would be possible to generate a “killer script”!   No matter how many hours you sit with clients and do your very best to extract their call handling requirements, it just never seems to be enough! Generally, you have some block of professional hours to complete the script, test, train and turn up before “go live”.   You ask the client for their requirements and “wish list”, then prioritize the list toward the goal of getting as much done as possible within the budget allocated to the project. You no sooner get the script up and operational and the client is  asking for six options that never came up during the time you were discussing requirements. They were never even on the “wish list”!   Last time this happened to me, I determined to write a script which would have run time options for the various script extensions I have seen over the years.  Starting with a basic Generic script which had modules you could switch in and out to achieve not only increase functionality,  but efficiency in both cost and time.

Route Type?  Prompt and Collect!

Most call flow scripts can be reduced to answering an incoming call, playing a menu of options, navigating to a Contact Service Queue, finding the most appropriate human resource or managing queue handling while the caller waits for service.  Sometimes there is no menu after the call is answered, and the call is sent directly to the Queue.   At other times, we need to provide some “prompt and collect” for database look up prior to call routing. We are always looking at operational alternatives for time of day, day of week and holiday or emergency closings.   This sounds like something we could develop into a general purpose call flow script, complete with generic record prompts in the language of choice.  So the Killer Script contains a library of professionally recorded prompts and prompt segments for enabling you to assemble your own prompt!

Where are the IVR Prompts and professionally voice WAV files?

We long ago learned never to start coding a project until we had the actual recorded prompts and wav files in hand!  How many hours of development time have been squandered because an attempt was made to code without the scripts.  When the client finally delivered the actual recordings to be used in the script, they were different than the call flow we all signed off on during the requirements meeting!  Don’t do it!  Get the recordings done first.  Then and only then code your call flow!  This thinking gave way to a concept of numbered prompts!   Again, you no sooner get the project on line and “go live” and the client is back asking if they can change a recording!  Why not create a module that would allow the client to call into an IVR script, select the prompt they want to record, play it to confirm that it is the correct one, and then let them record it themselves!   I started thinking about this after the first experiences in which the client asked for special closing recordings.    The client would say something like this: “Sometimes we have a staff meeting and we need to close the queue.  We want to play a special greeting to the caller letting them know we are in a meeting.”

CCAdmin to allow supervisors to Open and Close Queue with custom Closed prompt!

So we now have a Generic Call Flow Script that has an option for a Contact Center Administration and prompt management!   The Generic Call handler offers some run time options that can be set at run time.  They include a ROUTE TYPE  (i.e., Menu, Direct, IVR or Transfer) that dictate how to handle the incoming caller.   In fact, we can change the route type based on the DNIS or ANI, so the script actually changes its call flow to play a Menu or send the caller direct to Queue with each new call.  We then created a Contact Center Administration module that would allow an authorized user to open and close a queue on demand by dialing into an IVR script.  If you closed the Queue, you were offered the option to record a new closed greeting.  Optionally, you could record any existing prompt by  entering the prompt number.   All of this done by an authorized user with a PIN number and not requiring the System administrator.

Queue management was another area in which a modular approach to scripting could enable a range of options.  Do we play “your estimated wait time” or “your position in queue is” or just play music on hold?  If they are in Queue awaiting an agent resource, do we offer them options like, “Press 1 to leave a message, 2 to schedule a call back, or continue to hold and your call will be answered…?”   Not every client wants these options, but many want the choice. How do you make that option available without burdening  the project with more develop hours?  In fact you might want these options to change based on who called or what number the caller dialed.  We determined to add a third module to our script library. We can now offer the call back option on module basis.

Clearly every call center is different. You will always need to modify your scripts.  It is possible however, to create a flexible, reusable script that has configuration options or modules.  It is also possible to make these options available at run time based on DNIS or ANI. There is no need to launch a separate script when you can reconfigure the same script on the fly to address the various call handling options required to manage a caller through a successful contact center interaction.  Ask us about our generic scripts and save yourself a ton of money while paving the way for self-managed call center flexibility as you move through your business process! DrVoIPGeneric, DrVoIPCCAdmin and DrVoIPCallBack are all available for CISCO UCCX and come with professionally recorded generic voice prompts that can be easily branded.  We also include supporting XML documents for Scheduling, Holidays and a Queue options template for changing call flow based on DNIS!

 Killer Script Overview  – Updated for 2019 Version!

The Core Root script is a single thread that enables both application level run time variables as well as “variables on the fly” through the QueueOptions.XML file.   Typically the script will be trigger by one of the DNIS numbers attached to the script.  This DNIS become strDNIS in our application and it is used to index the XML file to pull back all the variables for that specific CSQ.  One of the variables that is returned is the strApprefix value.   For example we have  “CSQ_SandBox” for testing and it has a strApprefix of “SBOX”.  This variable is prepended to objects like Queue Message Wave Files.  In this way SBOX_QueueMessage1.wav and PTAC_QueueMessage1.wav can both be represented by strApprefix+”_QueueMessage.wav” in the same script!    This also makes it possible to create Layouts that are pushed out to the agents.

The QueueOptions file contains all of the variables that you want configured for a specific CSQ.   It sets options for offering Estimated Wait Time and Position In Queue.   We offer the option of a call back without losing your place in queue.  This has a variable that can be set to enable “record a short message to be played to the Agent before you call is returned” or to disable that option and move directly to collecting the target call back number.

Route Types  (Direct, Menu, IVR, Debug)

Some CSQ’s require that the caller be sent directly to the Call Center.   Others require the caller to navigate an IVR or MENU and the option strRouteType defines these options.   If the caller is to be offered a Menu of choices the script loads the correct menu, again using strApprefix to bring back SBOX_Menu.aef at the appropriate point in the call flow.  Likewise the caller can be directed to an IVR platform before the call moves to the call center.

 

 

The Killer Script is actually a series of scripts, documents, professionally recorded voice prompts and sample XML documents that you can copy, modify or edit to suit your call center CSQ configuration goals.  All this for $295?   What a deal, your average professional service company is billing scripting engineers out a $275-$350 and hour!   If you have any scripting experience at all, you should be able to configure this script!  Optionally, we can quote a fixed project fee to install and configure it for you!

Text Us at 929-292-8100 for details!

Most Annoying Business VoIP Marketing Gotcha’s

If you have ever tried to decide on a new hosted business VoIP solution for your company, then you have most likely run into, and been frustrated by some of the “gotcha’s” that VoIP company’s use to get you to consider their service above all others. Even when you have narrowed it down to just a few options, you have likely struggled to perform a   comparison of VoIP services that helps you make a final decision.

So what are we talking about here? Well here are just a few that come to mind and please add a comment below if you have run into any others that have caused some level of frustration:

Tiered Per user Pricing! – You spot an advertisement that states “Business VoIP service from $19.99 per month” and you immediately get excited and take a look. It turns out that the $19.99 price is only available to companies that want more than 50 lines and you only need 10 lines for your small business. Actual price for 10 lines turns out to be $34.99/user/month.

No Detailed Pricing on Website! – The aforementioned tiered pricing models are actually fairly common and it is great when the VoIP provider’s website clearly states these pricing tiers. There are some providers that do not even list tier pricing information and you need to get on the phone and as such become part of their sales funnel to just get a ballpark price.

Premium Features are NOT included!– Did you know that getting an auto-attendant in addition to business VoIP service can often cost you in the region of an extra $24.99 per month? Did you know that some VoIP companies will charge you an extra fee if you want numbers ported? Did you make sure that the “cool” VoIP feature that you have heard about is even available from the provider that you are about to sign with? The answer to these questions is quite often “NO”, and when you start to add these premium features to you service at a later date, the big savings that you made by switching to VoIP in the first place, slowly start to erode.

What does a Feature actually do anyway? – Believe it or not, there is often different terminology used for the same VoIP feature by different service providers.  The common features (call forwarding, call hold, etc)  are typically named the same but when it comes to more advanced, or premium features, the same feature can often be called something completely different. An example of this is “call pass”, “call flip” and “single number reach”. All of these do pretty much the same thing but are named differently by providers.

Are Smartphone apps supported and what do they actually do? – Functionality and availability vary from provider to provider. Most Smartphone apps are an extension of the in-office solution and create a virtual presence for the user. Others are stand-alone extensions that require an additional payment. Additionally, some of these apps will support VoIP calling via Wi-Fi while others will use cellular minutes for every call.

Does the provider support the Phones I already have? – If you already have IP phones, make sure the new VoIP provider that you are considering can actually support them, as otherwise you could end up with a hefty upfront cost that could have been avoided.

The good news is that there are actually a lot of providers that display this information very clearly on their websites and make it relatively easy to understand what the pricing is, what features are supported and what any extras will cost. The bad news is that it will likely be somewhat painful to perform a proper comparison by simply pulling up two or three provider websites on your screen.

Some options that can help with this comparison are:

1 – Call each provider and request a custom quote and full feature list with detailed pricing for any extra features. If a provider can’t deliver this quickly then you might want to ask yourself why.

2 – Use a 3rd party website that lists the providers that you are considering and check to see if they have a feature comparison tool.

3 – Avoid all the research and comparison and just go with your gut. Not the recommended approach but it can save you time and get you up and running with a business VoIP solution quicker. You may pay the price later though.

Regardless of any potential hassle or confusion, VoIP is still a great option for phone service that every company should be considering.

What is going on at ShoreTel now?

I very seldom comment, in this technology blog, on company policy and just try to stay focused on VoIP.  This time I am speaking out as a ShoreTel Shareholder.You know, one of the people who bought into the $10 a share IPO (at about the time they were suddenly sued by Mitel for patent infringement)?  ShoreTel stock (SHOR) is now trading at $3.50 or so?  The company has been through at least three CEOs post start up. They are now scouting for yet another.  Every key executive in the non-Engineering side of the house has jumped ship.  What do you do when your key sales people go to work for a competitor, like Mitel?  What signal does that send to the market?

ShoreTel had a real lead on VoIP technology. They make excellent products. They have had, and still have, some really great people! Leadership, at this point, is lacking.There have been some clear mistakes!  Acquiring a “hosted PBX company” that cannot even use ShoreTel phones? Come on, I know I am a bit dense but really?   (Note: “Follow the Money”.)  The acquisition of the Mobility Router company, Agito Networks, made some strategic sense,  but there has been no real follow through.  (The secret weapon that was acquired from Agito was the SIP over TLS, which should have replaced the OEM VPN strategy ages ago, and built into ShoreTel phones and Gateways.)  Just like their OEM acquisitions of previous products like the conference server, this will end up being yet another boat anchor!

I was hopeful that someone would buy ShoreTel before it becomes another Altigen (ATGN)!  When I see Directors and the company’s own counsel filing Form 4s with the SEC, that does not sound very likely either.  ShoreTel was the iPhone/iPad but like those products, it has fallen behind. The competitors are moving in with updated solutions and it has lost its luster.  The adopted cloud strategy was a poorly placed wager on what could have been a winning strategy. They have missed the Virtualization market completely.   Actually, very sad indeed! Maybe Mitel (MITL) does have it right? Maybe these two companies will merge?  Why not, most of their executives have?

Open Letter to CISCO Certification Management!

Martin Sloan CCIE Voice Candidate #211151677 speaks for the entire CCIE Candidate community (DrVoIP included) when he wrote the following letter:

I’m writing you this morning to express my great disappointment in regard to Cisco’s recent announcement to retire the CCIE Voice track with no reasonable upgrade path to the CCIE Collaboration.  I know that you’re well informed as to all the arguments which are being made against this decision on Facebook, Twitter and other social media outlets, so I won’t go into any detail on why I think this is a bad decision.  At this point, the facts are well laid out for everyone to see.

I’d like to ask you to please reconsider this decision and provide a reasonable upgrade path for the certified CCIE Voice candidates.  I, myself, am not yet certified but I will make my first attempt on July 29th of this year.  I don’t need to tell you how much time, money and effort I’ve put into preparing for this exam.  It’s been a goal of mine since I first started on the CCNA.  To completely retire a certification track that is still very relevant is incomprehensible.
At the very least, I want to request that Cisco provide it’s community with an intelligent argument to support it’s recent decision to retire the CCIE Voice without a reasonable upgrade path.  We’ve heard very hallow responses citing new exam topics (that are already on v3) or that the description of the certification path wasn’t accurate with the technology.  These answers are very much an insult to those that have been so loyal and sacrificed so much to achieve CCIE certifications.  Please, ask your team to reach out to the community so we can come to an objective decision on this.

https://www.change.org/petitions/cisco-provide-a-reasonable-transition-path-from-ccie-voice-to-ccie-collaboration

CISCO UCCX or ShoreTel ECC – CCadmin script and power to the Supervisor!

If you have managed a contact center of any size, sooner or later, you will be asked to make a change on demand.    A contact center supervisor feels the need to have a “team” meeting in the middle of the work day and needs the entire staff to be present.  This means nobody will be logged in to take calls.    This is the point they call you, the contact center administrator,  and ask that you not only close the queue but record a new closed greeting.  This happens so often that we determined to automate the process and put the power of opening and closing a queue in the hands of the Supervisor or Team leader.   We created a Script, named CCAdmin,  that is always running and waiting for a Supervisor to call it and make that famous request.

In the case of the CISCO UCCX, the script makes use of the Recording Step and the ability to read an XML document.   Each operating script in the contact center has a “getstatus” subflow at the start of each script.  This subflow checks an XML document, named for the queue, that has a single status variable.  This is a simple boolean operation and it is either set to true or false.  During normal operations it is set to false.  The main queue script calls the subflow, finds the status as false and continues its normal routine of servicing clients.  If however, the status is true, meaning that we have a special closing, the script branches to the closed section of the script and plays a special closed greeting, made by the Supervisor when they called into the CCAdmin script.

The CallCenterAdmin script has the matching setstatus subflow that is checked by the main script.  When a Supervisor calls into the CallCenterAdmin script, they are prompted to select their queue by menu number.  They are asked to Press 1 to open a Queue or 2 to close the queue and make a new recording.   Then they are prompted for a PIN, which compares to a previously stored Integer to determine the Supervisors authority to make a queue closure.  Assuming the PIN is correct, the CallCenterAdmin script, then prompts them to make their recording, thanks them and hangs up.   The CallCenterAdmin script then setstatus to true and waits for the next request. All of the queue scripts in the call center have the getstatus subflow as part of their normal definition.   As each script launches it tests for status and if closed plays the newly recored closed script and hangs up.  When the Supervisor desires to open the queue again, they just place a call to the CCAdmin script and start over.

Though the concept is very straight forward there were a few kool tricks that needed to be developed.  First of all, you need to define a naming convention that allows you to use a standard XML naming convention.  So if we are checking the getstatus of the CustomerServiceStatus.xml we could use the same code we used to check the getstatus of the TechnicalSupportStatus.xml document. The setstatus of the CCAdmin script would also have to address this challenge.  Likewise, making a recording and naming it so that you could use the same body of code or script was also an interesting brain teaser.   CISCO UCCX enables the creation of Recordings wihtin a script, but ShoreTel does not.   Likewise, CISCO UCCX can make use of XML documents as the database record, but ShoreTel would need a flat file or OBDC connector.    I have been able to do the same script on a ShoreTel ECC, but I had to use a standard closed announcement as changing files in ShoreTel ECC on the fly, is not possible.  You can point to a different previously recorded wav file, but you cant create on on the fly.

The application however, is very useful and we now deploy this as a standard for all Contact Centers we deploy.    I will ultimately get the entire CCAdmin script into the lesson library along with the full prompt library as recorded by the first lady of all our prompts, Karen  Brace of OnHoldAdvertising

Compare ShoreTel ECC and CISCO UCCX – Handling Language Options

Anyone who has been deploying telephone systems for any length of time has run into the “language” issue.   Though I am personally tired of having to “Press one” for English, the fact remains that we market on a global basis even if we are a small local business.  It is rare to encounter an Automated Attendant or Call Tree that does not offer us the option of selecting another language.  In the States, Spanish tends to dominate the motivation to change language and it is invariably offered to all callers.

Setting up a basic automated attendant to handle a language change is relatively straight forward.  You end up recording your prompts in at least two languages and then you navigate a different tree based on the selection.   Providing a language option in an IVR Script for a ShoreTel ECC or CISCO UCCX, for example, is an entirely more complex process.  Yes, you end up having to record your prompts for each language offered, but do you really want to write to sets of call flow?  Contact Center Scripts can get relatively complex very quickly.  If you apply the same solution to a Contact Center Script as you do an Automated Attendant Call Tree, you will end up having to create at least two scripts: one in English and one in the other offered language.

You will really want to focus on a single call flow and a single set of prompts.   Do you want to have the complexity of writing a script that says play “WelcomePromptEnglish.WAV” and then have to write the same call flow again, but this time the script says play “WelcomePromptSpanish.wav”.  As my Grandson says, “REALLY”?    Would it not be more economical to write and to maintain a script that simply said play “WelcomePrompt.wav”?    At some point you are going to have to ask the caller to press or say something to change their language choice.   How about we run the same script and the only thing that changes is the subdirectory that the prompts are retrieved from?   In this way we only have one call flow script to maintain and scripting writing is significantly relived of the duplication of effort that language options often require.

ShoreTel and CISCO both manipulate the language option in their respective script editors differently.  Here we take a look at how the Java based Script Library in the CISCO UCCX would implement a language option using a single call flow script.

Should You Run Your Company from Smartphones?

With an estimated 45 percent of Americans now using smartphones (66 percent for those under 30), it smartphones are starting to bleed into the enterprise. And now some businesses are beginning to evaluate whether they can manage their phone system needs directly from a smartphone.

But before jumping directly into managing your business via smartphone, you need to ask yourself a few questions. For instance, what if you want more than one employee to be responsible for responding to your company number? Or, how should you handle call recording, phone routing and other services you traditionally associate with landline service?

In this article, I’ll summarize research from Software Advice contributor Kelly Lindner. She recently shared her insights on strategies for deploying smartphones for business, as well as pros and cons for transitioning to this type of business phone system.

To PBX, or Not to PBX?
Companies with three or fewer employees can usually get by just using their smartphone network to run operations. But larger organizations might instead opt for a “virtual” private branch exchange (PBX) – a call routing and management service – to unite their mobile-device empowered workforce. In this model, one employee’s number is designated as the main line, and other individuals provide their numbers to customers as needed.

Or, companies can leverage products such RingCentral or Google Voice to provide a main line, that routes callers to individual smartphones using business extensions. As an added bonus, when an employee calls from their mobile phone, these PBX systems will show the main line on recipient’s caller ID. Some of these Cloud-based services also offer call recording, voice transcription and other business-focused services.

The Pros of a Smartphone-Run Business
The first and most obvious benefit is customer accessibility. If employees are reachable anywhere – in or out the office – customers are less likely to have to wait on hold, or for their messages to be returned.

“Having a landline tied us to a specific location and was presenting a barrier to connecting with clients. … Now we don’t have to run back to the office to check messages,” said Stuart Randell, a virtual PBX user and head of business strategy at Code & Company Inc.

A smartphone-run business also has advantages for employees. They get to use the device they are most comfortable with. Also, business owners realize savings (though sometimes small) compared with traditional VoIP-based systems.

The Cons of this Telephony Model
There’s nothing worse than hearing that dooming beep indicating your phone is about to lose power. Loss of battery life is a huge negative to using smartphones only for your business. You depend on workers to keep their phones charged, and chargers close by. But we all know it can be easy to forget to plug and recharge your phone.

Additionally, cell networks are not always dependable in certain locations. This connection is particularly at risk during a natural disaster. And, generally speaking, voice quality in any condition can be fickle.

What advantages and disadvantages do you see with using PBX-enabled smartphones over traditional VoIP? Join the conversation by commenting here.

UCCX Scripting – “Get Statistics” and manage your call flow dynamically!

Have you ever call into a customer service function, been answered with “all of our Agents are currently busy with other customers, please wait and the next available customer service representative will be right with you” and then waited and waited and waited.   It probably crossed your mind that maybe they all went home!   Is it possible that a call center could queue a caller for service when nobody is actually logged in to handle the call?   Well, the answer is absolutely yes!   A bit of careless script writing and you will find that customers are queueing for Agents that went home hours ago!

Influencing the call flow within your Contact Center, based on the dynamics of your environment,  is an essential part of call center management.   The dynamics of your call center are changing by the minute.  More callers are entering the queue; call holding time is increasing; the position of callers within the queue is changing and the priority of the caller is also changing.   We have Platinum,  Gold, Silver and Bronze (Yes Virginia, all customers are not create equal) and we handle them differently!  How do we estimate holding time?   Do we even know if someone is logged in?   That is the stuff of call flow scripting using real time reporting data!

ShoreTel has an entity in their ECC Scripting tool called a “service”.  One of the elements of the service is “Agents Logged Out” call handling.   It is a great solution, but it is an all or nothing binary solution.  (There are 10 types of people in the world, those that understand binary and those that don’t).   If anyone is logged in, the service continues to define the call handling strategy.    What happens if I want to handle callers base don the absolute number of agents logged in?  Maybe it is not a smart idea to handle callers the same way given that there is only one Agent logged in rather than an army of 20 Agents.    We are going to need a more sophisticated filter to handle callers based on this dynamic.

The CISCO UCCX Script Editor has an amazing library of Java Beans that can be used to find out not only if an Agent is logged in, but how many are logged in!   Now that is a level of flexibility that can make your call flow really intelligent.   In this video clip we take a look at the very powerful “get statistics” icon within the CISCO UCCX scripting error.   We can use this icon to participate in the real time data stream that defines the dynamics of our call center.  We can tap the number of callers in queue, the number of agents available, the average call holding time and even handle a caller based on the fact that they have become the oldest call in queue.   The UCCX Scripting editor in the hands of a talented programmer can add a “knowledge” based routing component to your call flow!   Intelligent Call Management indeed!

Compare ShoreTel ECC and CISCO UCCX call back from queue scripts!

It is almost expected that a modern call or contact center be able to offer a “call back from Queue” option to your callers.  In fact some call centers are now offering a Call Back with no phone call required from your caller at all!  The caller can text a message to the call center and receive a text back with an approximate wait time until the next agent is ready!   Take the time to develop a custom “smartphone” application and the incoming text message can also contain  business appropriate CRM information like a client ID or policy number.
While you are waiting for your contact center to be updated with this advanced SMS text caller option, most modern contact centers can offer a “Call Back From Queue” option.

Generally, we want to capture the inbound call, route it to an available agent and if the agent is not available, we will play a customer care message to the caller and keep them in Queue.   Should an agent not become available in the next programmable period of time, we will play yet another customer care message, but this time we might invite them to “press 1” to arrange a call back without losing their place in queue.
Should the caller elect to activate this option,  they might then be asked to enter the number that they can be reached at when an agent becomes ready.

Optionally you can offer to call the customer back at a scheduled time in the future and also prompt them to enter a date and time for call back.   How this is accomplished is dictated to by the system that you are planing to use for your call center.   Generally, some kind of IVR functionality that can “prompt and collect digits”.   The ShoreTel ECC and the CISCO UCCX both enable this option though they do it quite differently.

ShoreTel offers a scripting tool that enables calling options through per-programmed routines encapsulated in high level Icons.  These Icons are interconnected on a pallet that graphically mirrors your call flow.   This is “brilliantly simple” and is often all that is required to establish control and options over your call center.   CISCO uses a scripting option based on Java and you will be more comfortable with this option if you have a background in software development.  CISCO is a bit more demanding then the ShoreTel scripting tools, but along with its complexity comes greater flexibility in feature definition.   In the hands of a talented programmer,  you will be able to create features that could not easily be encoded in a higher level graphical scripting tool.   The UCCX Scripts enable you to not only “prompt and collect” but also to “prompt and record”  the callers voice message for playback to the agent prior to placing the out bound return call.

Call Back from Queue is a useful customer service option in those business centers that care about customer satisfaction.  I would not expect to see this on the IRS toll free line, but rest assured that Charles Schwab will have it!   As the cost of keeping callers on the line continues to escalate with the cost of wireline facilities, you can expect other options to become more available.  The SMS option, being one, offers higher customer satisfaction potential while reducing the infrastructure costs associated with paying for more telephone lines than you have agents to handle the calls!  Keep your eye on this option as it is sure to change the nature and value of existing call center strategies!

Compare ShoreTel and CISCO – Extension Mobility Options!

Do you run a business in which the day shift and the night shift share the same telephone instrument?   This is a very common feature requirement in call centers, help desks and order lines.   In the Health Care Profession,  a very common staffing requirement is to rotate the  “front office” staff,  with  the “back office”e staff from time to time.   If your business or organizational requirements demand that you match a telephone extensions with specific named individuals for voice mail or activity tracking,  you need “Extension Mobility”.    If you want to travel between your geographically distributed office locations and you do not want to be tied down to a single telephone instrument at a specific desk location, you need “Office Anywhere”.      The ability to “log in” and make any phone in your business organizations VoIP deployment your phone is a very powerful and useful feature.

Both ShoreTel and CISCO offer this advanced functionality but they implement it in very different ways.   This is, in our humble opinion, the result of the “cultural” difference in their system architecture.   We have written on this subject before and it is one way in which the two systems distinguish themselves.   ShoreTel does not allow an extension to  exist without an associated user.   Such a phone is “anonymous” and, though registered and available as a system resource,  it can not be “called “as it does not have an extension number!   Until it is associated with a specific User, it has very limited capability.    It is the User that associates a “class of service” or set of permissions and an extension number to the phone.  CISCO separates the concept of a phone device from that of a User profile.   CISCO phones can in fact exist without being assigned to a User.   They can have an extension number, be called and make calls.   It is the Line Number or Extension number that determines the “class of service” or permissions available to that device.    Users are defined separately.   This is a subtle but very significant difference in these two systems.

“Extension Mobility”, on the other hand,  is an optional feature in a CISCO deployment and it requires configuration by a systems administrator.   Given the logical separation between a “device” and a “user” in CISCO, it is necessary that both entities must be configured for this feature to work properly.   Extension Mobility is an XML service in a CISCO deployment, that both the user and the device that a user might log into, must both subscribe.    An “Extension Mobility” profile must be created for any CISCO user who desires this licensed feature.   It might be possible to have a situation in which a User with an “Extension Mobility” profile, can not log into a different phone because that phone has not subscribed to the service.  Given that this is a licensed feature, it is not generally deployed on all phones during the installation.

“Office Anywhere” and “Extension Mobility” are excellent solutions for “hoteling” employees,  and “hot desk” environments where the staff moves between desks and do not have assigned seating.