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.

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 ECC and CISCO UCCX Contact Centers!

As Contact Center implementation consultants we get to work with both ShoreTel ECC and CISCO UCCX.   The fact of the matter is they are both really excellent solutions and very similar in many respects.   Historically, ShoreTel has had a single administration portal for the deployment of their iPBX solution.   You go to one portal to define your Users, Gateways, Call Flow, Automated Attendants, Workgroups and Voice Mail.   Add a User in ShorewareDirector and that user has a voice mail box, is instantly in the online Directory and it is “brilliantly simple”.    CISCO has always been bit more challenging to configure.  You have multiple Administration portals,  the Call Manager Users are not necessarily in the Unity Voice Mail and you most definitely go to different portals to administer these systems.   Gateways are programmed in addition to being created and registered with  the Call Manager and multiple servers are the rule regardless of the number of sites.

When it gets down to the Contact Center, both companies have very similar implementations.   For example, both companies use a separate server to run the Contact Center run time engine, manage agent states, store configuration data, usage data, scripts and prompts.    The system use the CTI strategy of Route Points to logically interconnect the host PBX to the Contact Center and they both have separate  administration interfaces.   Both Systems require you to define your Agents twice, once in the iPBX and then again in the Contact Center, though CISCO has an import capability.  ShoreTel is clearly migrating toward a single browser interface for the entire product line, but currently, you open one portal for the PBX and another for the Contact Center.   CISCO does the same thing and clearly does not think that  multiple administration portals is  a market requirement.

ShoreTel has a straight forward license model for the ECC.   You get a fully feature contact center to which you just add agents and IVR ports.   Email, Chat and Campaign dialing are options, but everything else, at least with Version 7, is included.  Pricing is simple and easy to understand.  Real time reporting, historical reporting and the ability to do custom reporting are standard platform features. Integration options include DDE, Triggers and Active X.   CISCO is a bit more complex in its packaging offering Standard, Enhanced and Premium packages. The Standard package, however,  provides all that is required for a fully functioning Contact Center.   The Standard package does not provide CAD or CISCO Agent Desktop.  CISCO has the ability for phones to subscribe to XML based services and Agents use that option to log in, log out and generate wrap codes.   CISCO provides all IVR ports in the base system, where ShoreTel has ten packs to grow IVR ports as required.

From a sizing perspective, the CISCO UCCX supports 400 Agents and 400 IVR ports, while ShoreTel boasts 1000 agents and 250 IVR ports.  I used to operate with the understanding that I could have a maximum of 150 IVR ports on a single server and would required a three server solution for 300 IVR ports and Agents.    I was not able, thought I did try diligently to get ShoreTel product management to confirm the server requirements and specify Busy Hour Call Handling, but could not get anyone at ShoreTel to respond ( DrVoIP is not a ShoreTel partner, so why bother?  Then again, we are not a CISCO partner either and they sent us truck load of documentation,  lab licenses, Virtual Machine Templates  and answered all questions).    If you do the arithmetic with 1000 agents and a maximum of 250-300 IVR ports, something does not add up?   IVR ports are used to prompt and collect as well as source media streams for music on hold.  Clearly if you have 1000 agents, nobody is holding and 250 IVR ports may be more than appropriate.   Why the large disparity in Agent and Supervisor sizing for these two solutions?

The ShoreTel ECC Script Editor is a powerful little box of goodies and just gets the job done!   Clearly, there are always ways to improve capabilities, but I have yet to encounter a client requirement that we could not resolve with the ECC tool kit.   I would like to see the ability to import and export scripts; run the editor when not connected to the server and a simple record to file capability.  XML document processing and HTTP triggers could be improved, but again, we have always been able to meet the client requirements and at the end of the day that is what it is all about.   CISCO has a script editor that is also very powerful and offers options for XML document processing and configurable HTTP triggers.  We particularly like the ability to run the editor while disconnected from the Server.   Makes travel time more productive for us consultants!

CISCO has a number of desktop applications to support both Agent, Supervisors and Administrators.   We value the fact that the applications are downloaded from the UCCX server via a web page.  CISCO phones have a native ability to subscribe to XML services and a display large enough to make this a viable option.  In many UCCX deployments not Agent Desktop application is necessary.  ShoreTel provides an Agent and a Supervisor desktop application.  The desktop Agent application is currently a two EXE solution, one for the ECC application and one for the ShoreTel Communicator.  Again, ShoreTel has done an excellent job of integrating the two desktop applications, but there are in fact, two applications running on your desktop.   Some end users like the smaller Agent toolbar anyway, so I vote to keep it as a desktop option!  CISCO has a powerful tool named the WorkFlow Administrator which enables the creation of Agent buttons, work flow processing, web page push that enable a range of optional agent capabilities without the need to grant administrator rights.

Both systems have a long history and have undergone many changes in packaging and functionality.   ShoreTel is about to release Version 8 and CISCO is at about the same level.  The ShoreTel engine is running on a Windows server, where CISCO has migrated away from Microsoft to a Linux platform.   ShoreTel uses MySQL and CISCO uses Informix for the configuration, activity and repository database functions.   There is no reason that you could not have multiple ECC or UCCX servers on a single PBX.  In fact, why not?    They would not share the same Agent database or inbound trunk groups, but that may not be necessary in a large multi-site enterprise spanning the country or globe in which there are multiple business units.

We find both Contact Center solutions to be powerful, fully feature and very capable of handling blended activities at very aggressive price points.  Though it may be such that you choose a PBX based on the Call Center, it is more likely that you will select your Call Center based on which vendor PBX you select!    In either case DrVoIP can help develop your Contact Center call flow and scripting!

New ShoreTel ECC and CISCO UCCX feature – Text Messaging?

We continue to focus on call center strategies that optimize the caller experience by reducing or eliminating wait time. Now clearly, you have to be in a business that actually cares about customers, we don’t expect the IRS will be implementing this feature in the near future! In our last blog we took a look at the use of Smartphone based applications that can do the “wait” for you, alerting the call center to call you back when an agent is available to speak with you. We thought we would take the state of the art to the next level, and interface an SMS resource to the call center. Using this technology, you can have your clients send a text message to your call center. The call center receives the message and queues you for call back. When an agent becomes available, the call center places a call to the phone number that originated the text message.

The smart phone applications have the advantage of offering the user a visual menu to alert the call center as to the reason for the call. “Make a Service appointment” would be a different button then “My bill has an error”. The SMS or Text message, however, has the advantage of being interactive. Sending a text message to the phone number associated with “make a service appointment” or just texting “service” could trigger a return text message that indicates available service times and the estimated wait time for your agent to call and confirm the appointment. Text messages can also contain key customer service information that can be used to trigger the CRM application when the agent does call you back.

If you don’t mind a third party service bureau, or being on a list of competitors offering a similar call back functionality you might look at the emerging players in the Smartphone market. Both fastcustomer.com and Lucyphone.com are offering Smartphone applications that you can tap almost immediately. In either case, the technology is basically augmenting the call centers existing call back feature set. We have been implementing our early SMS to CC interfaces using Twiio scripts and have just written the return telephone number to the database containing the abandoned call or call back from queue requests. These applications are relatively straight forward to implement and can be customized and refined as you call center learns more about how your clients make use of the application. The advantage of SMS approach is that you can implement it with your existing call center technology and you do not need an outside service bureau or the creation of a new iPhone application.

Call Center technology is going through a comparatively vigorous revision. If you really care about the experience your customers have when they call you, the old Music-on-hold model may not be what you want. Basically, you want to call them when they want to talk to you! Don’t make them wait on hold for the next available agent. Have the next available agent call them! We think these programs can be funded in the overall reduction in telephone lines alone. You can now size your call center based on how many agents you have not on how many clients are holding!

Send a note to DrVoIP@DrVoIP.com with comments and questions, or better yet, text us 702-553-2706!

New ECC Feature – Smartphone based “Visual IVR”!

Imagine that you go to a restaurant, ask for the menu and the waiter hands you a phone?   You lift the handset and hear “Thank you for coming to our Restaurant home of great food and fine dining.  For breakfast, please dial one; for Lunch dial two and for our dinner selections, please press three now”.    Sound like a scene from the theater of the absurd?   Using a touch tone telephone to self-navigate through a customer relationship interaction is just as absurd in this day of Internet connected Smart phones.   It occurs to me that Smart phones should be communicating with smart call centers that have adopted, the next frontier in call center technology, “visual” menus!

Most customers contacting your call center know exactly who they want to speak with, so why do we present an audio menu tree?   We do that because we need to collect information that will help route the call to the most appropriate customer service agent.   Like teaching pigs to fly, however, it only annoys the customers and burns up expensive call center resources.   Is there a better way?   Imagine a Smartphone application, like a visual restaurant menu,  that could take the client directly to a “call me back button” representing the desired menu selection. Clicking this button passes all the relevant  customer contact and account information to the Call Center and directly places the customer in the proper queue, talking directly to the proper customer service agent.  The Agent not only knows who the client is, they are on the phone when the customer is connected.  Even when there is not available agent, the Smartphone application can trigger the call back, holding the customers place in queue, all without the annoying prompts and the extended hold times that often result when navigating the usual maze of an audio based IVR system.

Using a combination of existing technologies,  ECC Smartphone applications can eliminate customer frustration, improve the customer shopping experience and dramatically impact call center operations.  The Smartphone application actually gathers all of the needed customer input information and bypasses the “automated attendant”, hitting the call center queue only if there is an available fully informed agent, armed with the correct CRM display available before directly engaging the customer.   No more hoping the Caller ID brings up the correct CRM page!  No more fumbling while waiting for the “screen pop”!  No more conversations with angry and frustrated clients who have been waiting in queue far to long.

This ECC application couples a call back strategy with a visual navigation menu on the customers smartphone that actually places a phone call to the agent and the customer simultaneously. The inbound call request acts more like a web page or email, but is handled by the phone system as if a caller were pressing digits after being answered by an automated attendant system.   All the information that the caller would have otherwise had to enter into the IVR system has already been collected and made available to the call center.   Congestion in the Call Center, does not result in a “queue” of callers holding on very expensive telephone lines.   The same “your estimated wait time” technology has been translated into Smartphone display estimating when your call back should be expected.

The first step is for us to map our your existing IVR or Digital Receptionist to enable us to create “buttons” that take callers, using the Smartphone Applications, to there desired end points.   As a second step we integrate this call flow into your existing call center, enabling “call back” when no agents are available.  Lastly, we make sure that the account information is collected and made available to your CRM solution before the call is present to either the agent or the customer! The internet is already in place and your customers already have smart phones.  More than likely, your company maintains a very sophisticated website, complete with shopping cart.  Rather than invest in building out the infrastructure that houses more telephone lines and more customer service agents, an investment is made in more fully integrating your existing CRM and Internet technologies toward the goal of higher customer satisfaction and retention.

Give us a call or write DrVoIP@DrVoIP.com for implementation details!

Will Technology Kill the Call Center?

We recently posted a blog on how smart phones could be used to bypass automated attendants and deep dial into a call center with a Smartphone visual menu.   This  blog received a lot of interest and the follow on questions clearly indicated a level of interest in just how technology impacts the traditional call center.    The “call center” is now the  “contact center”!   Customers are calling more frequently from mobile devices and less frequently from land lines.   What does that mean to your contact center?   Have you integrated your website with your Contact Center?  Can clients who visit your “online store”,  hit a chat link and interact with the next available customer service representative?  Are you formatting webpages for both the full size computer screen as well as the Smartphone screen?   Technology is shaping the channels or touch points that your customers use to interact with your company and your call center will most undoubtedly go through a significant change in the very near future.

Will Technology kill the call center?  Ashley Furness CRM Analyst for  Software Advice, Austin Texas,  hosted an online panel discussion to seek answers to the questions impacting the current transition of forward thinking contact centers.   She asked industry experts: How have you seen consumer contact channel utilization change in the last decade?  What role has technology played in this change?  How do you see technology impacting the way customers contact a company in the future, and the kind of service they receive?  Finally, Will technology eventually render call centers irrelevant?

These are very interesting subjects for those who have responsibility for managing customer experience, satisfaction and fulfillment.   Industry participants from Avaya (Customer Experience), Drumbi (mobile), IntelliResponse (Virtual Agents), and Etech Global (Chat Services)discuss these questions and provide expert insight.   These experts do in fact answer the question “Will technology Kill the Call Center” and the panel discussion is well worth viewing!

Compare ShoreTel and 3CX – Part 1 License Strategy

The trend in the Unified Communications industry is to charge a “per seat” license for access to VoIP Business Phone Solutions.  In large part a legacy “flat tax”  from the old TDM world, phone system suppliers continue to license based on the number of users that the system supports.   Microsoft, ShoreTel, Avaya and CISCO all seem to have software licensing based on the number of users.  Some licensing strategies become more complex as features and services are added.   ShoreTel has by the simplest licensing strategy of the major suppliers, but they do count the number of users as the base software license cost.   Additional license fees are assessed for “Professional” Communicators or Communicators that access Workgroup functionality for Agents and Supervisors.   It is all rooted, however, in the number of users the system will be hosting.

If we consider a simple 100 extension solution, ShoreTel will have a $20K software license fee before you purchase any of the required VoIP hardware.  Basically, you are paying $200 per user for an Extension and Voice Mailbox.  After you purchase your software license, you will still need to purchase handsets, gateways and servers! Microsoft, CISCO and Avaya, though significantly more complex in their licensing strategies, start from the same basic “per seat” model.    In fact, if you look across the  business communications landscape  all suppliers have to offer basically the same set of components   Yes, all automobiles are different,  but they generally have four wheels, a steering,  seats, dashboards and a power source!

Clearly this has a significant impact on your ongoing cost of support.    For reasons that I have yet to figure out, “technical support” is somehow a function of your system acquisition cost?   The industry trend is in the range of 10-20% of your total system cost, including software licenses, will then be used to calculate your ongoing cost for software insurance and technical support.    I know there are smarter people than I that have been working this out,  but I just cant see the relationship between the cost of equipment and the cost to service that equipment?   I get “making money”, but I don’t’ see the value relationship in punishing customers for buying more equipment?

Is there another model out there?  Are we forever bound to the “per seat” license model?  In fact there is another model out there!   Enter low profile, high performance, global provider of  Unified Communications, 3CX!    These guys amaze me and I think they are harbingers of how the communications industry will work as we move deeper into the 21st century.  Now hear this, they do NOT charge a “per seat” license!   Contrary to the industry trend, they also include most functionality that the other players generally “option”.  Full chat or IM services, presence, fax server, call center and mobility services, soft-phones, iPhone and Android applications are included with no “per seat” cost!   Then how do they bill for their software?   Simple.  They license based on “simultaneous connections”.    Clearly, if you have a 100 user system and a PRI for PSTN connectivity, all your users are not on the phone at the same time.   Why not pay only for the maximum number of live phone conversations that you project for your business?   3CX pricing ranges from 4 to 1024 simultaneous connections and that can cover both large and small deployments.  Lets assume that same 100 extension system and instead of $20K or $200 a user, you paid $5K to support 64 simultaneous phone calls?

This is not some small upstart trying to buy market share.  This company 3CX,  a certified  Microsoft Developer,  has been deploying on a global basis since 2006.   They have a fully formed, Unified Communications solution that can match the established players,  feature for feature.   They will not compete with ShoreTel and CISCO in the 1000 seat market, but in the larger 25-250 seat multi site segment, they are a serious contender.   Technical support is offered on a global basis, is astonishingly effective and uses a combination of traditional TAC center live remote support but leverages alternatives like video wiki, community, email and chat support. ( In future blogs, we will do the architecture comparison thing).

I know I am alone in the belief that you can not be both a hardware company and a software company!  I think you have to pick one side of the street and really do it well to create a defensible market share and posture for growth!   My Son argues that that is a ridiculous position, “just look at Apple they do both and have the best products on the market”?   Not withstanding Microsoft, I think that the issue of comparative size plays a key role in enabling a company to pursue both.    If you are a comparatively  smaller player (Market Cap: SHOR  $247M, APPL  $611B, CSCO 100B) I would argue that it is more important that you figure out if you are a hardware company or a software company!

I would identify 3CX as a software company that you need to pay very close attention to!

contact DrVoIP@DrVoIP.com

Backing up your iPBX Call Center, what is your plan?

“The Check is in the Mail”;
“I gave at the office”;
“The software if fully tested and bug free”;
“We are working on the documentation”;
“Go ahead tell me, I promise I won’t get mad”;
“Yes we backup our data every day, off site”.

These are just a few of our favorite white lies.   That last one, however, is a real resume creation event.  Today I took my late model SL convertible in for a smog inspection.   You could have knocked me over when the technician informed me that the car failed the certification!  Just the day before I had the car into the dealership to get the “consumer electronics” battery changed and have the normal scheduled maintenance.   Apparently, at least here in the peoples republic of California, if you have On Board Diagnostics (OBD)  in you automobile, that data is submitted or evaluated as a part of your smog inspection.  Having just had the battery changed, my dealer had failed to backup or protect this data and as a result the OBD  had no history.  I failed the smog check , wasted several hours of my life and can now retest when I get 100 miles of driving history back into the on board automotive computer.   Clearly my dealer had no data plan or process in place to protect the data during routine maintenance.

Now imagine if that had been your VoIP phone system or call center?   Simple server upgrade? New Version of the iPBX being installed?   The question is, does your dealer have a process in place to protect your data during routine maintenance?  More importantly do you have a plan and process in place for backing up your iPBX configuration database, system prompts, voice messages, call detail records and even your maintenance history (e.g. Logs)?   Want to play, “bet your company’?   Chances are that you have this on your list of “things to do” but you just have not had the time to execute.   You may even be trusting that your dealer is taking care of this as part of that expensive maintenance contract you entered into.

If you are really feeling secure about your iPBX failover plan why not just pull the power plug and test things out?  There is nothing like a crashed phone system to bring out the facts about database backup, recovery and the  business continuity preparedness of you and your vendors!  The facts are that having an active emergency back up and restoration plan in place is absolutely essential in this day and age.   Cloud backup automation services abound and there is not acceptable reason for not having this process in place.  Just as important, is a restoration plan that is periodically exercised.  You can have all the data available on backup, but if you can not restore that data, it is useless to you and your business.   Yes, it may be just another “fire drill”, but it will save your company if you include this process in your maintenance activities on a regularly scheduled basis.

Very recently we have had an opportunity to experience cloud based, on demand, iPBX redundancy and disaster recovery strategies.  We have explored some of the current cloud options for both day to day redundant operations and disaster recovery.  In one case we were able to bring up a complete PBX in the cloud in a matter of minutes, on demand using predefined Amazon Machine Instances.  The results were remarkable, dramatic and redefined operational readiness. Hit the AskDrVoIP button for details!