In the previous blog article (TAPI Windows and Web APIs Integrations) we investigated the definition of TAPI and Web API. This time we will discover which Unified Communication capabilities can be integrated using these technologies.
Smart Routing
Even before a user answers the customer’s call, the UC system can automate the processing of the call itself.
It can, for example, determine who should answer the call, the level of service agreed, and even the preferred language. This is done by integrating with our application before the call is delivered to a user.
The integration can be achieved either via TAPI routing points or by using web requests to an external service.
In the case of TAPI routing points, our application receives a notification that there is a call waiting and information about it. After performing all relevant operations, the application can reply by requesting that the call be transferred to a specific operator or to voicemail.
Using a web request from the dialplan (the place where calls are managed by the PBX) in a similar way, we can perform operations in the CRM system, such as lookups in a database, and then return information to the PBX about how the call should be treated.
Automatic / Predictive Dialer
Besides the routing of incoming calls, telephony integration can also be used to automate outbound marketing campaigns. The advantages of automatic dialing is that it:
- Reduces the number of repetitive operations performed by the users, such as repetitive calls
- Increases productivity, by connecting only those calls that have actually been answered to call agents
- Centralizes the management and supervision of campaigns
- Mixes inbound/outbound calls
For example, when using such a dialer, users can independently manage inbound and outbound calls during times when incoming call volume is low.
Many commercial dialers currently exist on the market, and implementing one (for example, TAPI or Web API) is not difficult. Most implementations work by generating outgoing calls via Web API which, once answered, are transferred to an operator.
Since calls are not generated by users, unreachable numbers are managed by the application without wasting the user’s time. After the call fails, the application stores the event and schedules one more call to that customer at a later time. The exception is when the trunk returns a “subscriber does not exist” error. In such a case, the number should be checked and probably updated.
Predictive dialers go a step further by generating more calls than available operators, thereby reducing idle time. Although this leads to higher efficiency, it can result in having no operator when the call is answered by the customer.
Faxes and SMSes
Using Web API, a UC solution can easily provide the means to automate the sending of faxes and SMS. As we saw previously (Automation of Daily Tasks), SMS can be a useful method for sending real-time notifications to customers regarding meetings, orders deliveries, flight statuses, etc.
Tracking of Calls via Tags and Extra Variables
While developing your app, it is always important to keep track of the history of the call or chat session. It is important since it provides some additional information for the receiver, for example, whether a call is new to the system or if it has already been managed by a user, before being transferred to another one.
Unfortunately, this information is missing in most systems.
When using TAPI, CallID can be used for this purpose. CallID remains the same within the call if we use a solution with an ICS TSP approach, and if the system implements the feature.
Having a single CallID allows the system to determine and save the “story” of each call.
When using other forms of integrations, a consistent and unchanging ID should always be present throughout the duration of the entire call or chat session.
If the system allows it, extra variables (besides the remote party ID) can be set and read to trace the life of each session. These extra variables can be set from the dialplan of the PBX to read (via a web request) when the call is routed to a user. These variables should always be stored in a call / chat log at the end of the session.
