Recording ShoreTel phone calls!

Call Center not Required!

Long the standard in boiler room call center applications, recording calls is often a requirement outside the call center.    There are any number of reasons to record calls for including compliance, clarity and certainty and just management of customer quality service.   There are a variety of recording solutions in the market and they all have very different feature sets.  Do you need the ability to annotate calls?   To search on more complex parameters that time and date?     If an employee is being recorded and transfers that call to the HR Director of the company, should that segment of the call be recorded?   Do we want to record inbound calls only?  Both inbound and outbound?  Do you have multiple locations in your deployment?   Do employees have the right to start and stop recordings?  Add notes?  You will also have to consider how recording are to be stored and for how long?  This can have a huge impact on hardware requirements.   Just some of the characteristics you might want to consider as you look for for a recording solution.  The list of features is long and there are many options to chose from.   It is best to get a solid requirements document together and to make sure that you fully understand that recording alone is not all there is!

Recording Server Applications

ShoreTel has an optional recording function that can be very effective!   It can be installed as a single server solution or as a multiple server, multiple site solution.   It can record all calls, or just in one direction only.   You can select who is recorded and you can also select the archive location and time frame.   The solution is deployed on a ShoreTel server, either HQ or DVS depending on the deployment model.    There are actually four modules that can be installed: the recording server; the client side, the web player and the administrative module.   The solution uses the integrated recording functionality of the ShoreTel phone system and most of the usual user group and class of service settings apply.

Generally you will create a route point with a call stack as deep as the number of calls you want to simultaneously record, and put it on the server that will host the recording application.   You will also need a route point for the player and you will need to create a user who will proxy the recording functionality.   The server install is very simple and conforms to the usual point and click install expectations of a Windows server application.  The configuration is very simple, just provide the route point extension number, note the port for recording and click install!

The Administration Application

The Administrative application enables you to configure the specifics of the recording server and  to create profiles.  This application can be installed on the server or on a PC that can reach the server.   The configuration options are very easy to understand and simple to enter.  Basically they deal with where files should be stored and for how long.  You also have the option of either saving the recordings to a file system, or saving them as a voice message.


You then create profiles that are used to customize different groups of extensions.   For example, you might want persistent recording for some extensions and not others.   This means that the recording continues even if the call is transferred.  Do you want inbound and outbound recordings?   And exactly who should be recorded!  The profile also dictates if recordings are to be made all the time, or sampled as a percentage or by a defined schedule.

Client Side Options

The client side application is installed on a pc and is optional tray icon.   You would use this only if your profile enables users to start and stop recordings and to tag recordings.   If this is not a privileged that you want to extend to those be recorded there is no need to install this optional application at each desk.  The use of the client is profile dependent.


The Player Application

The last application defines the player and is very useful for visually managing recordings.  You can use a phone to play recordings , but most folks find this web application to be more useful.   The application must be installed on a server as it uses IIS, but the recordings are played locally on a windows machine that has a sound card!   Each extension is listed and there is a time and date stamp on the recording file.  You have the option of storing other file information, like ShoreTel call properties to enrich the identification of a recording.

ShoreTel Recording Player


All in all, the ShoreTel Recording Application is a sweet suite!  It gets the job done and at a price point that compares more than favorably with the third party Recording applications found in the market place.   We recommend it for both call center and general recording applications when you are on a ShoreTel iPBX!   Give us a call and we can help point you in the right direction or get this installed and configured for you!





Understanding ShoreTel Connect ECC Shifts!

Why use Shifts at all?

Most call centers have “on hours” and “off hours” that route callers to different options based on time of day and day of week.  ShoreTel ECC has a concept entitled SHIFTS.   Shifts have day types:  Weekday, Weekend and Holiday.    You  go to System Parameters in the Contact Center Director, then Schedules and the create a Shift.  Name the Shift something useful, specific the day type and the time the shift action should occur.   You then  apply it to the IRN you want to alter, open or close based on your shift schedule.   If you do not understand shifts, however  and how they are utilized by the ECC you are at risk of shutting down your call center unintentionally.

Let’s take a closer look at how Shifts work!

Each IRN in the ECC that uses Shifts, has a default setting that specifies where the call should route, if there is no corresponding shift instruction.    The Shift might specify a Script, Service or Device.  For example you might have Shift named “M-F”  defined for day type Weekdays that is active at 8:00AM and specifies that the call should be routed to a script for handling calls during “on hours”.    You might then also add another Shift named “Lunch” for a day type Weekdays and set if to activate at 11:59 AM and point it to script that plays an announcement alerting callers that the call center is closed for lunch and invites them to call back at 1PM (never happen but it makes for a good lesson example).    Now we create another Shift also named “M-F” for day type Weekday and set it to activate at 1PM.  This action points the calls back to the script for “on hours”.   Clearly, you also created a Shift for “M-F” for day types Weekday and set the action time at 5PM.   The action is to send the call to the script for After hours.   Make sense?   Seem easy?


Danger – The trouble Spot with Shifts!

Let’s assume you have an IRN for Sales and an IRN for Technical Support and you apply the shifts we defined above, to both IRN’s, but on the sales IRN they do not close for lunch!   For this reason, you do not apply the Shift entitled “Lunch” to the Sales IRN.   Let’s assume the default route for the Sales IRN is the Closes script, so that after hours calls defaul if not specified in the Shift list to the after hours call handling.   So what do you think will happen to the Sales IRN at 11:59?


The fact that you created a Shift and one now exists for “Lunch” during the week is the important take away.   Once you apply Shifts to an IRN, ALL shifts apply even if you did not apply that shift to your IRN.  In this simple example,  the Sales IRN will follow the Default route because you did not specific an alternative destination in you shift list on the Sales IRN for Lunch time.   The fact that the Shift exists in the ECC database, requires that you specify an action for that Shift!   This is where most folks get into trouble!

What Version of ECC is your Shift definition?

In versions before Connect and ECC 8,  Shifts required you to open and close a shift.  After version 8,  you are not required to close a shift but it would be a good practice to do so!  You must account for all shifts, even if they are to relevant to your IRN.   The only way around this is to NOT apply any Shifts to an IRN.  If the IRN does not use Shifts at all, it will ignore all Shifts!   A bit confusing but once you “get it”  it is easy.

When in Doubt press Explain Shifts!

In the IRN definition press “Explain Shift” and then select the day you want to explore.   The list will populate with all the Shifts that impact that IRN.   Remember it does not matter if it is on your list!  What matters is that the Shift exists for the ECC and you must specify an action, or in the absence of a direction, the default destination for that IRN will be followed!




Build ShoreTel Connect inside your own private Cloud using AWS!

Placing your ShoreTel HQ in the “cloud”?

Moving the ShoreTel HQ server to a data center to increase system resiliency, reduce or eliminate down time and increasing overall recovery times has always been high on the check list for business continuity and disaster preparedness.    Our preferred “data center” however is Amazon Web Services, or AWS for short!   We have been deploying ShoreTel in AWS as a “private” cloud solution for some time and have several blogs on the subject.

Do you already have an Amazon Account?

If  you have a regular old Amazon book buying account, you already have all you need to log into AWS and get started building out your own virtual private cloud!    Though there is a lot to learn,  in less than 15 minutes you can spin up a Windows 2012 Server in a virtual private network and then link it back to your onsite location with an AWS provided VPN Gateway!

The simplest ShoreTel/AWS deployment model

The simplest of VoIP deployment models is the placement of the ShoreTel Connect Server in an AWS Region and availability zone of your choice.    Typically, we defined a private subnet in three different AWS availability zones and then launched a ShoreTel Connect server.    The availability zones provide additional resiliency  options.  It is even possible to setup an Elastic load balancer than can move from one ShoreTel HQ server to a standby duplicate in another availability zone in the very unlikely situation of a AWS availability zone going off line!

You can interconnect your ShoreTel Connect VPC  with your remote sites over a VPN, ultimately moving to a “direct connect” circuit and only using the VPN for backup.   The remote sites will have ShoreGear resources to support localized carrier access and onsite user phone services.   The distributed nature of the ShoreTel architecture makes this a natural deployment model.   This is  by far the simplest of the deployment options and one that everyone who is considering moving a ShoreTel HQ server to a data center should consider.

Even Ingate in the Cloud?

With ShoreTel Version 14, virtual switch resources make it possible to create the entire deployment in your VPC.  You can even deploy your Ingate as a virtual Session Border Controller, in the AWS cloud and centralize your SIP carrier access.    This is a bit more demanding then spinning up a Windows server but now that AWS enables you to import vmware machines, it is an exciting option.

Importing vmware based ShoreTel machines

The secret to deploying ShoreTel vSwitches in the AWS cloud is to first build the machines as vmware machines in your local environment with an IP that can be duplicated in your private virtual network.   Once your machines are created, you can then import them into AWS.

The options for deploying VOIP in your own “private cloud” have never been more flexible.   Your CFO is going to be impressed when comparing AWS to the cost of building out your own data center or renting space in a collocation facility.   You have all of the benefits and none of the cost associated with a typical infrastructure build out.    Connection options are unlimited and you can access AWS facilities on a global bases!

The Video clip demonstrates a ShoreTel HQ and ECC Server in an AWS VPC, with a VPN back to the main office site.   The office site contains ShoreGear switches for SIP trunk access and 400 series phone support.  There is a synergy when integrating AWS and ShoreTel that every CIO should be seriously considering.    Give us a call and we can help make this happen for your company!


Add DNIS routing to your ShoreTel ECC Contact Center!

Why Route by DNIS?

Routing by the number the caller dialed, or DNIS is the preferred routing strategy for any Call Center call flow.  Clearly you can assign a DID phone number to a specific call flow and anyone who knocks on that door is answered by the same group of agents.   It is much more efficient to grab the DNIS information, however, and use it to index a database to retrieve the call routing information.  In this way, we only need one door to the call center!  The DNIS might be used to route a call to the proper product or service group and it may also be used to retrieve client information that the call center Agent needs to see displayed  in order to provide a custom care answer prompt.

Consider the requirements of a Hospital that is providing “centralized scheduling services” for 1000’s of primary care physicians.  When the inbound call is presented to the Agent, the requirement is that the caller be greeted with a customized answer prompt.  For Example:  “Doctor Leary’s office, are you calling to make an appointment?” or “Thank you for calling Doctor Williams”.  This type of dynamic call handling can best be managed by using DNIS information to retrieve the Doctor’s name from a database   We do this regularly in CISCO UCCX and ShoreTel ECC Call Center solutions and the process is essentially the same for both solutions.

ShoreTel ECC Route by DNIS example

First, we need to create a DNIS Map in the ShoreTel PBX; a ‘route point/IRN ‘ combination to pass the call to the ECC;  and an ODBC connector from the ECC server to your favorite SQL database server.   The SQL server would host the database your scripting application needs to access in order to obtain the correct answer prompt.  Lets assume that the database contains a very simple table structure:

DABASE = DNIS_listofDoctorsOffices = (Field1 = DNIS Number, Filed2 = OfficeName, Field3 = QUEUE_IRN)

You would then write a simple script to take the incoming DNIS information and use it to index the database and get the OfficeName and maybe the Customer Service Queue that handles that office (City or State or what have you).  There is no limit to the information you could retrieve and present to the Agent,  For example: Name, Service Class (Platnium, Gold or Silver), Renewal date, last order, shipment date, the list goes on.   In this simple example the script would take the DNIS and use a SQL expression to retrieve the answer prompt data:

Select * from DNISlistof DoctosOffices where DNIS = %DNIS_NAME%Sample ECC Script Screen

Creating a DNIS MAP in ShoreTel iPBX

In the ShoreTel iPBX Trunk Group it is necessary to create a DNIS map for two reasons:  First, the ShoreTel ECC can not read the DNIS directly, it requires the administrator to fill in the “dialed number” column in the DNIS map.  The ECC has a mandatory call profile filed named DNIS-NAME which will be auto filled with the information you provide in the DNIS map “dialed number” column.     Secondly, unlike a DID number that might be directly mapped to an extension, we need a way to get the incoming call connected to the IRN on the ECC that is running the DNIS SQL lookup  Script.   In this example, the Destination field of the DNIS Digit Map in the ShoreTel iPBX Truk Group points to the Route Point/IRN in the ECC that supports the script.



POPing the Agent Display with useful Data

The ShoreTel ECC has two variables data types: Mandatory or System Variables; and User create Variables.  The Mandatory variables are system call parameters like ANI or DNIS and a long list of other system based data.   ANI contains the digits that make up the caller identification and that is also often used to retrieve database information.   If you are using ANI you will need to do some string manipulation to strip off the +1 from the 10 digit number, or format to match your database.   User created variables are the name you create for the fields you will get from your database.  Useful examples would be CustomerName, DateOfService, AccountBalance and RenewalDate.    Any Variable, User created or System,  can be pushed out to the Agent Display within the ShoreTel Communicator.


What is your Call Center Application Requirement

We have seen it all, so we are always interested in your requirements for custom CRM integration and Call Flow management.  Give us call or drop us an email and play “stump the vendor”.   We would love the challenge of finding yet another new ShoreTel ECC or CISCO UCCX Contact Center application requirement!

[show_related ids=”2828, 2610 ,2447, 1378″]

Quick Peek at ShoreTel Connect – What’s in ShoreTel V15!

Deploy in the Cloud, on premise or Both!

For those of us who have been working with ShoreTel since version 3.1, the introduction of a new ShoreTel release is always exciting!   The marketing folks are naming this release, ShoreTel Connect to underscore the full power of a deployment that integrates both the customer premise with the flexibility of a cloud solution.   It may be Version 1 of ShoreTel Connect, but it builds on all that ShoreTel has learned over the years and will always be ShoreTel Version 15 to the rest of us.    The product extends ShoreTel’s history of distributed switching to now include cloud  components like a new “Edge Server”.   As we were fortunate enough to be deploying for a new client, we though we would share our first impressions and show you the new Shoreware Connect  administration interface and the ShoreTel Connect client!

The product is now in controlled release and shipping to new client deployments.  There is a direct upgrade and  migration path if you are on at least ShoreTel 13 of the iPBX,  Version 8 of the ECC and Mobility 7!   Reinstall or step upgrades will be required if you are on an earlier version of ShoreTel.  You will need to shed the 32 bit operating systems as the new release runs only on supported 64 bit 2008 and 2012 Servers.    The Virtual appliance OVA images introduced in Verson 14 are still available and though you can virtualize with VMware ESXi 5/5.1 or Hyper-v 6,  we believe that the appliances still only run on ESXi hosts only.

New high density Switches!

Going forward ShoreTel is focused on its 400 family of SIP phones.   They have also introduced some new high density ShoreGear Switches including a 500 port switch, a 48 port analog switch and dual T1/E1 switches!   No longer will you need to trade DSP resources to enable analog or media termination points and they have even enhanced the paging port with a contact closure!  We are very pleased to see the addition of an ova file that enables you to field a distributed voice mail server as a Linux appliance!  Hopefully ShoreTel can continue to migrate away from Microsoft servers, further reducing cost and increasing up time!  The fat desktop client has been replaced with a browser like client thus eliminating the need for a Microsoft desktop.  In fact, the administrative interface no longer demands an IE browser as Safari, FireFox and Chrome are now supported!   Clearly, this means that the ECC client has changed as well!

 New ShoreTel Connect administration Portal and desktop client!

ShoreTel Connect can be deployed as a cloud solution, as a completely CPE solution or as a “hybrid” solution that blends both componet options.        We have not had time yet to study the firewall traversal options, but I am sure this has all been thought out!   The accompanying video will give you a quick overview of the administrator interface and the new client.     We will continue the video development as we complete the deployment, sharing what we have learned along the way and updating our video training library.     Hit us up with questions and challenges!  We are long time Cloud Architects!




The ROI of a “Call Back” option!

In his newly released ebook, Fonolo founder, Shai Berger, defines Abandoned Calls Rate as the Number of Abandoned Calls / Total Calls.  Abandoned calls represent not only a lost revenue opportunity, but they cost you hard dollars. Shai does a masterful job at outlining these costs in a way that business folks can understand.  Throughout my 35+ year career in telecommunications,  I have witnessed the pain of  Call Center management endlessly struggling to increase customer service levels and response times with limited available resources.   One solution,  hire more agents until there are no busy signals is never considered.  Yet business managers never tire of adding more incoming telephone lines,  queuing more and more customers to wait on hold for longer periods of time, resulting in lower customer service levels and higher abandonment rates!


Recently we heard of a company, HOLDYR,  that actually makes a product that allows people to select what music they want to hear while on hold!  As Shai points out in his book, if you think this is a joke, take a road trip with your browser open to to see the rants of folks who have been on hold.  Putting customers on hold will result in lost business and high frustration levels.  You will also be tying up a phone line for the duration of that hold period.  Couple that phone line to an incoming toll free number and the cost per minute of hold is even more dramatic. Only the IRS can leave folks on hold and care less about abandoned call rates, most competitive businesses prefer to take action.

Call Backs offer reduced operating costs, smooth traffic demand, and fully employ customer service resources,  so why not provide callers that option?  After  answering an incoming call and finding no agents are currently available, the caller is offered the option to “receive a call back without losing your place in queue”.   If the customer elects this option, we can confirm their caller id or ask for the number we should call them back at.  Fonolo offers a number of equipment agnostic “virtual queuing” solutions that can be added to an existing call center.


We can take this strategy to yet another level by providing call back options that do not even require a call to your customer service center at all!   Web based call backs are one example, in which a client on your website provides a phone number and requests a call back.  We are particularly fond of TEXT based solutions in which the customer sends a text message, and either receives a call back immediately, or receives a text with an estimated call back time.  This text can prompt for an alternative call back number or time for call back.  In both cases however, there is no need to queue callers or to have more telephone lines than you have customer service agents.  (In fact, if you think about it, under the right conditions you might not need a call center at all!)

Send “TextMyECC” to 760-867-1000 for a sample interaction.  We can even build these  solutions around Smartphone apps which completely eliminate automated attendants, IVR and queuing, but allowing the customer to directly interact with the correct call center queue to schedule a “call back”!
[show_related ids=”1749, 1753 , 1699, 1598″]

The sad sound of a silent voice

Since late 1998, I have had the pleasure of working with the wonderful folks at OnHoldAdvertising!  The husband and wife team of Brent Brace and Karen Kelly have produced literally millions of voice prompts for thousands of systems throughout the American Business Communications landscape.  Karen can be heard on more automated attendants and voice mail systems in this country than we have touch tone keys to push!  Behind the scenes, unless you required a superior male voice artist, was Brent working away tirelessly as the editor and producer.  They brought “a human voice to a technical wilderness” and great joy to those they worked with.


Brent had been fighting one of those long term muscular and neurological diseases for years, but not once did you ever hear him complain about it.   A Vietnam Veteran,  Brent soldiered on, and built an outstanding business, and a greatly admired professional reputation.  Most recently in the Denver area where he and Karen had relocated from Southern California, he had been teaching voice artistry workshops.  Brent entered Hospice at home a few weeks back, yet he was still directing our voice production!   Unfortunately, Brent passed away in the early morning of this Memorial day weekend. We will miss his voice forever!  Our heart is heavy and we are again reminded that “business” is conducted by “people”.

Karen will continue the wonderful work of On Hold Advertising but will need some time to process all that has happened this year.  If the voice these folks have produced has touched your life, please send Karen a note of care and consolation.

“Soft and safe to thy my brother, be thy resting place.”


ShoreTel ECC “Sticky Email” ?

Call Center or Contact Center?

Call Centers had no sooner become “Contact” Centers  when multimedia “nice to have” features became “must have” requirements.   The more mobile the customer base, the more likely they are on a smart phone and not sitting at a desk computer.  They want “contact”, however they want to communicate.  That used to mean voice by telephone, but might now mean text, chat, email and now video!   (See our Blog on this subject.)  Email, however, is an interesting option as it cuts across platforms and can be read at the desk or on the phone. For this reason, it is still a strong feature requirement on the Contact Center landscape.

ShoreTel has had the ability to route an incoming email to an agent, much the way an incoming phone call is routed to the next available agent.   Send an email to and the ShoreTel ECC will grab it from the mail server and route it to the next available Agent.  ShoreTel ECC will even allow an Agent, already engaged in a phone call, to take that email and work with it, increasing Agent productivity and cutting customer service response times.

One of the challenges with ShoreTel ECC email however, has been the ability to route the email to the same agent who initially responded to the customers’ first email request.   An Agent might get an incoming email, answer the email and send it back to the customer.   The customer might have a follow up request and when they hit reply, to the reply, there is no assurance that the original Agent will get that same email.  Often the email is routed to the next available agent, as if it was a first time contact.

Why do you “Sticky Email”?

The solution here is to create a “sticky” email. One that will relate the original customer request to the Agent who initially handled the response until such time as the case is closed.  This can be done with the existing ShoreTel ECC tool set.   Using the C2G or Interaction reporting database and some SQL glue,  an incoming email can be reviewed before it is passed on to the Agent.  That review process would check the Interaction database to see if the FROM field has been previously entered into the database during, say the last 30 days.   If so, the email is routed to the personal email queue, within ECC, of the Agent who responded to that email!

Simple, elegant and actually it is really quite cool!   We have been using this process to manage our Text to ECC email messages for some time and have now adopted it for ShoreTel ECC routing.  Text the word “STICKY” to the phone number 858-223-1040 or email us at We can get your Contact Center connected! While you are at it,  we can set you up with TEXT to Agent as well!

(Note – The CISCO UCCX has “sticky email” built into the application along with Chat, and Social Mining!   This is a great overview of how CISCO does this feature).






V14 Configuring ShoreTel SIP Trunks P2 -SonicWall or InGate SBC?

A question that keeps coming up in the support ticket system is the subject of InGate and Session Border Controllers.  Folks want to know if you need a SBC to configure a SIP trunk.  Why not just use a Firewall?  Can you configure ShoreTel SIP trunks to work without a SBC?  The simple answer is “yes” but the smart answer is “no”.  In our humble opinion, just because you can do it, does not mean you should do it!   Session Border controllers, like those offered by Intuit for ShoreTel,  provide functionality not normally found on a firewall.   “Normalization” for example, the ability to mediate ShoreTel SIP and your carrier’s  SIP, as they most likely speak a different “dialect” of the common language SIP, is not a standard firewall feature.

Application Level Gateways, sometimes take actions that are injurious to SIP messages.  Remember, SIP was not designed for NAT based networks.   Something has to keep track of which internal private trusted network users made a SIP request for service to another IP address across an untrusted boundary!  Which RTP (voice, video or “media”) ports need to be opened to support this request?  SBC can do this more effectively than firewalls. At the end of the day, you end up turning off the SIP ALG functions in your firewall to make it work! (In SonicWall turn off  “consistent NAT” and “SIP transformations”.)

We have never recommended bringing your SIP services into your VoIP deployment over the same circuit as your Internet circuit, but so be it.   At least, let’s use a separate IP address and make use of the DMZ port on your firewall, if you are not going to use a separate circuit!  Let us try to keep the SIP traffic from undergoing the same port specific inspections you put the Internet traffic on!  Again our best practice recommendation for ShoreTel, if you are serious about SIP trunks as the main Communications link for your company, is get an Intuit SBC and bring your service in on a separate circuit or IP!

SonicWall has for sometime, had a number of “service objects” to support the ShoreTel MGCP phones.  In fact, before SIP was enabled on ShoreTel, all media flowed on port 5004 which was really great for enabling transport level QoS!   Though there is a steady trend to use TLS and get both SIP messages and RTP over a single port, most SIP carriers expect to send messages on UDP 5060.   So if you are using a SonicWall, you will need to create new Service Objects, and put them in new Service Groups to get SIP to work.   You will need to configure Network Objects for your ShoreTel SIP proxy and configure access rules.  We recommend you also create a network object for your ITSP rather than enabling  an open 5060 for all the script kiddies running SipVicious!

We will do this again on a  CISCO ASA 5505 just for giggles as we get a lot of requests for that as well!  At the end of the day, however, for a serious business application of SIP trunks on ShoreTel, get a separate circuit and invest in an Ingate SBC!  Heck, you can even get a virtualized version of InGate!

A ShoreTel Workgroup is a Contact Center for the rest of us!

We have been working around the call center space for a long time.  Actually, it is our first love! Does everyone need a full blown Contact Center?   If you have a real boiler room operation, with shifts of agents that are heavily manged, counted, recorded, measured complete with staff forecasting and multiple channels of client communication, yes you need an Enterprise Contact Center.   As Arlo Guthrie might say “what about the rest of us”?   The small to medium size business that is really not cracking the whip on customer service agents, but making efficient use of “knowledge workers” who often participate within a group setting.  How do we organize customer calls to this group?

A techncial support group or an order entry group might be a good example.   By grouping these folks into a “workgroup” we can funnel calls to them in a call center like fashion without the call center overhead of application servers and third party middle ware.   ShoreTel has an embedded call center like feature aptly named “WorkGroups” that is an ideal solution for this environment.   You can organize a group, route calls to group members and even queue the call until a group member becomes available.   While callers are in queue, you can organize the messages they hear, the time they wait between care messages and you can also provide “bail out” options at each step of the way.

The workgroup can be reached as a menu selection off of an automated attendant or have a phone number assigned that enables outsiders to call directly to the workgroup!   The workgroup can have an operating schedule applied that routes callers to alternative answer points if the group should be reached after hours.  Group members can Log in and Log out of the workgroup using their ShoreTel Communicator and still maintain their personal extension number and mailbox.  While logged into the workgroup, they can share the group voice mail box and see callers waiting in queue!  Supervisors can monitor the callers in queue and manipulate resources to meet call demand.   Reporting statistics on the group are maintained and easily obtained by the workgroup supervisor or administrator with reporting permissions.

We are now even making it possible for Callers to TEXT into your workgroup!  Group members can even email back a TEXT message!

The ShoreTel Workgroup strategy is a powerful call center like functionality and very cost effective.    The marginal cost of adding agent and supervisors license when you plan to implement a ShoreTel iPBX when compared to adding a complete Enterprise Contact Center is amazingly low!   We would be happy to explain the difference between a Workgroup and the ECC, so just contact us for details!

TEXT the keyword “workgroup” along with your name or email to 702-956-8700 and we will respond immediately!