Amazon Connect Email Routing using Dextr.Cloud

The Dextr Dashboard for Amazon Connect Agents has added email routing to its existing voice and SMS/MMS channels.   Similar to a voice call, an incoming email message is routed to the next available in the queue assigned for email.   Dextr will collect emails, provide auto responders.   The email is “sticky” and the email conversation will stay with the first Agent to respond to the email until the conversation is ended.  Similar to the Dextr SMS channel, if the original agent is not available to handle the follow on conversations, the entire conversation will be forwarded to the next available agent.

Setup is easy, in the Channels tab of a Dextr user with Administrator permissions, simply enter the appropriate email user, password, imap and smtp host address!  Then configure the queue that should be the target of an inbound email along with the initial email auto responder and the end of conversation auto responder.  Multiple emails can be established and can point to different customer service queues!

Email setup and queue selection!

Agents can manage email and voice calls depending on the permissions and queue assignments.  Creating an email named can be routed to the customer service team.  Email is an asynchronous yet powerful customer tools and many folks prefer it to waiting on hold for the next available agent!  When an incoming email is routed to an available agent, they accept the mail exactly as they do a voice or sms call.   Opening the ENGAGE EMAIL tab displays the content of the incoming email.  As the email conversations ping pongs back and forth, the agent will see the entire email conversation in the ENGAGE portal.

The Agent will find the accepted email in the email client registered for that agent’s email box.   The agent will then respond to the email and Dextr will assure that the recipient of the email sees that it is from the address of the origitanl email TO: filed.   There is a button to END the conversation and when clicked, the final auto responder defined during the email channel setup, is sent to the author of the original incoming email.  (Those familiar with ShoreTel ECC routing will be very comfortable with this email implementation which has the additional benefit of being “sticky”.  If the agent who originally responded to the incoming email is unavailable, the entire email conversation is forwarded to the next available agent for follow up.

Dextr email routing is a bundled feature in your subscription and you should give it a try!  Price is what you pay, value is what you receive.

Configuring a SIP Trunk TIE Line between CISCO CUCM and ShoreTel iPBX

Merging Systems is fun and easy?

In a world of swirling mergers and acquisitions,  IT organizations are expected to integrate the different systems so that they all work together.   In the world of  IP PBX systems, that might result in having to make a ShoreTel system play nice with a CISCO system.  Actually, both systems support SIP and though it is sometimes more of an art than a science, it can be configured and made to work.   In fact we are seeing this request a lot lately.  Not sure why, but there are a lot of ShoreTel/CISCO integrations out there in the real world!   This video cheat sheet takes a look at a real world configuration from both the ShoreTel side and the CISCO side, so there is something for everybody who has to work with either or both systems.

Quick Topology Overview

In our example we have a CISCO Version 11 deployed in France and a ShoreTel version 14.2 CPE solution deployed in several NY locations.    This will be an interesting configuration as both systems have over lapping extension numbers.  For example, both systems have the range of 4100-4199 as extension numbers.  This along with a requirement for tail end hop off or TEHO at both ends makes for an interesting configuration puzzle.  We determined to take it a step at a time and get a basic SIP  TIE line working between the two systems.  Once that was up an operational, we could then focus on the basic dial plan strategy that would enable us to resolve the extension number conflict.

We are not going to use a session boarder controller at either end.   The good news is that it will greatly simplify the configuration as the two SIP proxies will directly exchange SIP messages.   In the case of the CISCO, the SIP trunk will originate on the call manager server itself and will terminate on a ShoreTel SG appliance (one of those orange boxes for you CISCO guys) with SIP Trunk resources sufficient for the number of channels you want to set up.    The bad news is, that on the CISCO side it makes trouble shooting a bit more time consuming.  If you had a CUBE in the mix you could easily open up CCSIP Messages in the debug on the IOS device, but when you do not have IOS you need to download logs from RTMT.  On the ShoreTel side, there is the ability to do a remote wire shark capture from the HQ server diagnostic panel using the SG appliance as the end point source.   (As a VOIP engineer SIP debugging should be second nature).

To avoid the use of a SBC on either end, we have to configure the solution entirely within a private IP topology.  In this case we have a /24 network on the ShoreTel side and a network on the CISCO side.   The WAN connection is an MPLS network.

ShoreTel and CISCO dial plan strategies

CISCO does not really care about over lapping extension numbers of difference in extension number ranges.  When I say, they don’t care, I mean they have a strategy for dealing with it.   You might have a multi-site deployment as a result of a recent acquisition and you have four digit extension numbers at one site, and five digit extension numbers at a different site.  CISCO can deal with this.  ShoreTel not so much.   With ShoreTel you would have to convert the four digit site to five digits (you can expand from four to five digits,  but not five to four) if you are going to have one dial plan.  In CISCO you could actually let both sites coexist with different extension number lengths.

CISCO has a verbose dial plan strategy that expects you to create route “patterns” that when matched by dialed digits, point to a gateway or route list that contains a destination reachable by that route pattern.  In our example, we set up a dial pattern of 51.xxxx with a pre-dot discard that points to the SIP trunk TIE Line over to the ShoreTel.   The SIP Trunk configuration is relatively simple and is shown in the video below.

ShoreTel requires you to configure a Trunk Group and then put your individual trunks into the group.  These individual trunks are basically SIP channels and the video also shows this configuration.  The difference in the strategy of both systems is interesting to note.   CISCO is routing to this trunk group based on a route patter that matches dialed digits.  ShoreTel is going to want you to define both an access code and list out the OPX (off premise extension) numbers that this trunk can reach.

From a digits dialed perspective, ShoreTel is going to match the dialed digits against the list of OPX extensions to route calls over the Trunk Group that contains a matching OPX list.   Note that no access code will be required, though it will be required in the Trunk Group configuration.

SIP Trunk Group Profiles

Both systems required a reference to a SIP Profile that defines specifics of the call setup messaging.    Sometimes this is a bit more of an art than a science and it may take a bit of tweaking.   CISCO has a standard SIP Profile and an associated SIP Security profile both of which will be referenced in the SIP trunk configuration.  The only change I typically make to the SIP Profile on CISCO is to activate the “enable PING option” so that I can keep track of my trunk status which would otherwise be “unknown”.

I made all my SIP Profile changes on the ShoreTel Trunk side.   This is the  list of configuration options we applied and it was the result of trying and retrying, so this list alone should be worth the blog read as it most definitely works in our example:


If you have never configured a ShoreTel SIP Profile, the video walks you though this in detail.  ShoreTel provides a “standard tie-line” sip profile and suggests that you use it.  In fact if you change it, they generate a strong message urging you not to do so, but change it we did to the settings above and we had a more than acceptable result.

Extension conflict resolution

ShoreTel trunks do not out of the box allow abbreviated dialing.  The Standard ShoreTel domestic dial plan really wants what amounts to an E164 format.   ShoreTel will take all digits dialed and attempt to construct a +1 NPA – NXX – XXXX dial string.   So in this example, we are not going to be able to dial 51 as an access code on the ShoreTel side, then output only four digits.  Not going to work.    As outlined above, ShoreTel will want you to define the OPX extension reachable by the encapsulating trunk group in a detailed list as part.   The good news is that this means that you only have to dial the distant extension number and ShoreTel will see it as an OPX and route it over the associated trunk.

Clearly this means these extensions are unique.   What are we going to do? We have extensions on both sides of the TIE Line that are not unique, they are the same 41xx.   ShoreTel will allow you to create translation table to over come this limitation.   We could create a range of 61xx for our OPX list and then convert it to 41xx in the translation table and that would eliminate our problem.  Not my favorite solution but it may be the one we have to go with.   The down side is that we have no eliminated the 61xx range for use on the ShoreTel side.   Additionally, it is not very friendly to directory systems as people have to remember that if you are calling 4304 in France from New York, you need to dial 6304 not 4304 another colleague in NY!

Ideally we want to make use of that access code.  It would be nice to dial 51 + XXXX and be done with it, but as previously explained ShoreTel does not easily support that option.   It may be possible to write a custom dial plan and apply it to this specific trunk group.   For example, when working with paging adapters that have zones, you want to dial the paging amplifier and then dial your zone.   The custom dial plan for this would by “;1I” but you would still have to dial an OPX number.   For example, you would create the trunk group and maybe put 1234 as the OPX which would route the caller to the paging adapter.  The custom dial plan rule would be interpreted by ShoreTel as “do not echo any digits” enabling the paging adapter to play a second dial tone, and then you could touch tone out some digits.   Sounds like this would be a good solution but you would end up dialing eight digits, but it would free up a range of extensions that might otherwise be eaten alive by the required translation table.

ShoreTel Update

At the end of the day, the solution was to create a custom dial rule and apply it to the ShoreTel Trunk Group.  Users inside the ShoreTel would dial 50+xxxx but as a result of the custom dial rule, the ShoreTel would see 999-555-xxxx and only pass the xxxx.   Remember that ShoreTel wants you to list the extension numbers on the other side of the TIE line in the OPX list of the Trunk Group.  In a situation in which you have extension conflict you can use a translation table, but often that is not the most friendly solution.  Ideally you will want to dial and access code, get connected to the distant phone system and then out dial the extension digits regardless of extension conflict.   To do this on a ShoreTel system will require a custom dial plan modification to the trunk group.  The document on this subject is very limited so you either have to pay ShoreTel  Professional Services or be prepared to play detective.  We went the detective route, so hit us up for the solution.








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!





Customer Service by the Numbers – brightmetrics!

In business what is measured gets done!

We subscribe to the business adage that what is measured gets done! For this reason key performance indexes are absolutely essential to the success of any customer service environment. How many contacts did we manage today? How long did a contact have to wait on hold before we were able to engage them? How much time does an average customer engagement actually take? What is the rate of abandonment and how long did a caller tolerate waiting before they gave up and hung up the phone? Sometimes we have to refer back in time and search “historical” records to locate a specific caller and verify the fact that they actually called! Other times, we have to be aware of “real time” data and be alert to what is happening right now! How many callers are waiting to engage us? So where do you obtain this type of information no how easy is it to obtain?

ShoreTel Call Accounting

In a ShoreTel solution there are at least three separate databases that keep this kind of information. The ShoreTel iPBX can generate historical reports out of the internal Call Detail Records log using the integrated report generator that you access through the ShorewareDirector administrative interface.   A great solution if you want to generate total trunk activity reports showing the aggregate number of inbound and outbound calls. It has detail reports that can even list every phone call made by every extension user in the system.  Ask it a simple question like how many phone calls did we receive this month from 202-555-1234 and you will quickly learn the limitations of this system solution.

The ShoreTel ECC has an internal historical data repository and a primitive report generator that has mystical templates that you can modify to create performance reports. You can not however, directly access the data in that database! The internal historical report generator has some serious limitations however. For example, do you want to generate a Group Activity report, showing all the desired metrics for all Groups in your deployment?  You would have do to this one Group at a time using the ShoreTel provide tools.

The ShoreTel C2G is a veritable cesspool of disjointed data elements or “events” like, extension 123 went off hook;  IRN 155 received an incoming request for service and Agent 789 logged in. Not very useful unless you are an accomplished SQL programming genius and want to spend your career figuring out the ShoreTel data dictionary while writing custom reports that assemble all of these events into meaningful record.

Though ShoreTel has some “standard reports” the fact is, you will want to generate custom reports unique to your environment. No matter how many templates are provided, we have yet to encounter a call center that did not have unique one off requirement when it came to reporting performance metrics.   Where is the data?  Is it in the PBX? or the call center?    How do you track a call that came into the PBX, connected with the call center and transferred to an offsite backup answering service?  Do I have to retain a SQL programmer to figure this all out? (Fortunately brightmetrics has already done that for you).

BrightMetric Illumination!

brightmetrics has created a powerful, yet very simple to navigate report generator available as a hosted solution. Connecting with the various databases internal to your ShoreTel deployment,  brightmetrics can sort and integrate data from the PBX side, the Contact Center side and that cesspool of events that contain information from both sides of the data equation.  Are you running ShoreTel Workgroups?  BrightMetric puts wheels on the information that would otherwise require professional application software add-ons from ShoreTel.

The brightmetrics user interface is easy to understand and navigate. The portal has video based help files and report templates for almost every type of data assembly.  You can generate reports on demand.  Save reports and schedule reports for future delivery.  The administrator can setup user accounts that provide access to specific report profiles and easy to understand “dashboards”.

Call Flow Diagrams can save an Admin’s life!

One of the most useful none numerical feature of brightmetrics is the ability to diagram your call flow.   Have you every wondered about your automated attendant options, Hunt Groups, Route Points and IRN’s?  Where do all the options lead?   If you press 1 for customer service, where does the caller go and what are the possible outcomes for that caller?    Do you have a complex SQL data dip over an OBDC connector from you ShoreTel ECC?  Want to see where all the routing options might point to?  This feature will map and diagram call flow from an Automated Attendant, IRN, Workgroup, ECC service and even an ECC Script!



How about Real-time Reports?

Historical reporting is extraordinarily important to both customer service and employee productivity.     Real-time information is also very necessary and important.  brightmetrics has introduce a new element to the product mix and now offers Real-time displays suitable for framing!   If you have ever tried to make a Wall Board out of ShoreTel supervisor desktop, you now how frustrating getting status information in front of the Call Center team can be!    Using a real-time event feed, brightmetrics can display comprehensive  status information formatted for legibility and clarity!



The brightmetrics team!

brightmetrics has been making incremental improvements in the product from day one and post all of there progress, both features and bugs!  Today the are generally recognized as the only viable solution for ShoreTel call accounitng accuracy and flexibility.   More importantly, the company behind the brightmetrics product family is an astonishing group of people.  Usually, pre-sale is about as good as it gets in American business!   Not the case with brightmetrics!   The real story begins after you sign on with them.   The folks in this company from Jim Lewis the founder and CEO through each and every person you meet on the team, will  treat you with a level of commitment and customer focus, that in this day of “Internet shopping carts” is very rare.   Ask a question, open a support ticket, make a suggestion even offer a criticism and these folks will overwhelm you with not only time  but focused attention.    We have worked with many clients who use the brightmetrics solution and we have always had the most positive and productive experience.   Technology is great but its people who make the difference!

Want a Free 21 day trial?   Just text the word STATS to 630-GANDALF or 630-426-3253

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!




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″]

Trouble Shooting ShoreTel ECC Scripts

ShoreTel ECC Future?

The ShoreTel ECC or enterprise contact center is a remarkable product in many ways.   Though we are depressed to see that it has apparently taken a back seat to ShoreTel Connect as it relates to product enhancements, it remains a formidable player in the contact center space.   Clearly, if you are deploying a ShoreTel phone system, then it may be the only viable option.    We note that ShoreTel has made a new acquisition for contact center functionality in the cloud, so the potential of supporting ECC product enhancements may even be less hopeful as product development resources shift to the “cloud” and ShoreTel Connect.

Remember EasyRun?

We have worked with the ECC since before it was a ShoreTel product.  It actually originated as an OEM product, a re-branding  of a software solution brought to market by EasyRun, an Israeli based company founded by Avi Silber, long time VP of Software Development for Telrad.   ShoreTel ultimately executed a software source code licnese and the rest is history.  Unfortunately, we seem stalled at Version 9 of ECC, which was not a major evolutionary step from ECC Version 8.

At any rate, the product does a super job in small to medium sized Call Centers and meets the minimum daily adult requirement for call center functionality.   One particular  function enables the system to integrate with popular database solutions like Microsoft SQL.   This enables the system to take on some very sophisticated applications that include routing inbound calls based on the return of data in the customer service database.  One of them most asked questions of marketing professionals as it relates to Contact Centers:  “are all customers created equal”.   You might want to route an incoming call based on the callers status in your customer database as a Platinum client or as a deadbeat on credit hold.

SQL database dips are almost essential for any Contact Center offering.   ShoreTel enables this functionality through OBDC connectors to the host SQL server or CRM system.    One of the challenges for design and implementation engineers is testing the design and results of the SQL data dip.  Historically, ShoreTel has not provided a lot of debug tools here and documentation on inner workings of the ECC is not generally available.  If you are bold and go poking around in the BIN files, you will note a lot of exe files and if you are curious, brave and inquisitive you might take on an exploration of what these files are used for.

Undocumented ShoreTel Debuggers!

One file in particular seems to launch a very useful test tool.  We have never found any documentation on it, and it has become something of a legend among we ECC implementation engineers.   If you are fortunate enough to maintain a relationship with other engineers that share information, you can build up a library of useful tools based on shared results from others.  Kudu’s to one such brilliant engineer, Bill Fraedrich for sharing his growing list of FC_Thingy functions and the other members of the development community who regularly publish results.

Route Caller by ANI (caller ID)?

Recently we had to create a SQL data dip to pull back a customer record using Caller ID or ANI as the database index.   Now anybody who has done any Contact Center CRM integration regardless of vendor, knows that you have to do some string manipulations to strip off the +1 that will be passed by the carrier as part of the ANI information.   ShoreTel ECC, CISCO UCCX, it does not matter it is all relatively the same.   Once you clean up the ANI you can pass it off as part of a SELECT command and go get your data.  Then manipulate the data to find the fields you are looking for to make your routing determination.

The undocumented debugger!

The issue becomes how do debug a script that is not producing the results your design expected?  Again, ShoreTel comes up short here as it relates to documented debug tools.   The CISCO UCCX, for example, has a step by step debugger built right into the script editor, which is really helpful for those of us who have to design, implement and test these scripts.   It turns out that ShoreTel has one as well, you just have to know where to find it.   Again it is not documented and is well known only to those that know it well.

In this video clip we take a look at the tool and show an example of how you might use it to unravel a particular SQL data dip problem.    We have found a number of these tools and we are always looking for documentation and road maps produced by those who have gone this way before!   Next blog we will take a look at a TAPI debugger that is also very useful when troubleshooting ShoreTel phone system Communicator issues.

At any rate, the ShoreTel ECC has great potential and is a wonderful solution when applied in the proper environment.   You can create some very sophisticated routing applications based on a variety of CRM integration, custom software solutions and IVR scripts.    Despite all our grumbling and complaining,  we have not found anything we cant make work on a ShoreTel ECC!

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″]

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).