Course12:Advanced - Operator

From innovaphone-wiki

Jump to: navigation, search

This book describes the concept behind the v9 operator software



Introduction Operator Console

innovaphone offers an own operator application (sometimes called attendant) to manage and distribute calls in a personal guided way - the innovaphone Operator.

The operator software is a windows-based application running on Windows XP onwards (we recommend to use at least Windows7) and is licensed per desktop installation.

From version 8 to version 9, innovaphone did some major changes in the operator application which result in the current version OperatorV9. Within this V11-training we will train this version and give some additional information about new features - so don't be confused too much about the naming "OperatorV9" - it works perfectly with PBX-firmware V10 and V11!



The operator software allows you to

  • monitor a Waiting Queue(WQ) object in a PBX
  • access an LDAP corporate directory to identify calling and called people
  • control the operator phone (comparable with CTI) and thus comfortably handle switched calls
  • find people and their presence and busy status in all PBXs which are part of the system
  • search PBX users and manipulate PBX user data (like Call Forward and Presence info)
  • contact people using email or instant messaging

Please note that you are not monitoring a Trunk Line and see all incoming and outgoing calls. You are monitoring a WQ object, therefore incoming calls must be forwarded to the WQ, using trunk line properties like Loopback, Busy, No Answer etc. These calls will be signalled to all operators (depending on their subscription in the primary and secondary WQ group) by the waiting queue object, regardless if they run the operator software or not.

Using the operator software, the call can be answered by the operator. The caller will be then usually asked for the person he wants to be connected to. By using again the software, the operator can search through all PBX users and the Corporate Directory for the asked person. Upon finding the searched person, the operator will use the operator software to setup a consultation call and eventually transfer the call to the intended recipient.

screenshot.png call flow

In any case we want to refer to the fish-help.png innovaphone OperatorV9 article for further information.


Operator Features

Beside the already known features like

  • call acceptance
  • blind transfer
  • transfer with consultation
  • un/park calls
  • call logging in journal

several features have been newly introduced or improved within OperatorV9.

Here an overview about the main changes and a description on how to handle them:

Simplified usage

There have been made heavy improvements in terms of keyboard usage beside the mouse.

It's now possible to accept any incoming call at the operator itself (not the WQ) by just pressing ENTER.

The action focus automatically switches to the search area to investigate for any contact.

Once found, a blind transfer for example can be initiate by just pressing "+" which immediately forwards the incoming call to the selected destination.

Consultation calls can be done in nearly the same way - just click ENTER on the selected destination to open a call - whilst the incoming call is set on hold. If destination agrees to take over, pressing "+" does the transfer.

Any pending transfer is shown up in the transfer list area right at the bottom.

Of course you could also use the mouse (Drag and Drop) to do the aforementioned actions.

Call switching

The above mentioned setup is valid if calls are directly forwarded to the operator who is part of a waiting queue collecting incoming calls.

  • It's possible to not be a part of this group (unjoin) and only monitor the queue itself. Any incoming call will be displayed here and by this a "preferred" handling for dedicated callers (a.k.a. VIPs) can be realized.
    Operator now just drags'n'drops the call to its own call-handling field for further processing - independent of the calls' order in the WQ.
  • It might be even more easier - if the operator knows (from his experience) the potential destination - he might drag the call from the WQ and drop it immediately at its destination (shown up in his/her busy lamp field or screenshot.png call journal).
  • another new feature is transferring a call to a busy extension. If a caller insists on being forwarded (and does not care of having to wait), the operator can drag a call to the busy destination. The call will show up in its parked call list, being indicated with a screenshot.png red traffic light. The caller gets MoH. Once the destination becomes free, the traffic light turns to green and call is transferred automatically.
  • If an immediate call switching is not possible and the calls need to be parked, a timer will be started upon parking which highlights parked calls on timer expiry. By this it is ensured that the operator does not forget about previously parked calls.

Contact Search

Investigation about a potential destination can be done either within the PBX only (which might mostly be used for incoming calls from external) or via LDAP.

In both contact databases one can search for specific attributes (screenshot.png name, longname for PBX; pre-defined screenshot.png LDAP-attributes on central phone book) or even full-text (which is set as default). Means giving only parts of the destination may match and by this speed up search.

If defined in PBX and indicated to dedicated extensions, operator can also screenshot.png search for extensions belonging to a dedicated group.

Of course searching for numbers only is possible, too (rumours are telling that there shall be operators which act like a "changing phone book"). Last but not least, all contacts may be managed and searched using the Busy Lamp Field.

Busy Lamp Field

The screenshot.png busy lamp field (BLF) was newly introduced in OperatorV9 to ease management of higher amounts of contacts. By this, presence of company (PBX) extensions can be shown and retrieved at a glance.

Operators can configure their BLF personally by sorting any entries in rows, columns, set labels or even define sub-directories (we called it Sub-BLF) depending on e.g. the extensions' function or membership to a department. Any change in the BLF-configuration is stored locally within the user account at C:\Users\<user>\AppData\Roaming\innovaphone AG\innovaphone Operator\swbusyfield.txt .


Once an operator needs to contact a destination, several options have been introduced to the extension contact fields:

  • send an innovaphone-instant-message to the users phone (e.g. when this guy is in a conversation but needs to be informed asap about any issue)
  • generate an email

If the operator could not reach(forward a call to) an extension, the message or mail will be setup using a template screenshot.png indicating a callback notification including the callers number.

PBX-user management

Sometimes it may be required for the operator to change the proprieties of a PBX-object. These can be

  • call diversions
    It's possible to manipulate the call-diversion of any extension. The operator can set/reset/change a call-diversion, as well as screenshot.png break through an active call diversion.
  • presence
    A user screenshot.png may have a different presence then the one set in the PBX (absent, busy,...). The operator can change the user's presence and even give an explaining note via the OperatorV9 console - which then is displayed on the caller's phone display when trying to reach this user.

Of course the ability for manipulation can be screenshot.png restricted by the PBX-administrator for dedicated operators, using a configuration menu at the operator.

These features and changes are also described in the related documents available on our link_intern.png web

Important Objects

Objects for configuration

The fish-help.png operator configuration is described in the wiki and will not be repeated here. However we will now have a closer look at three PBX objects, that are usually created when installing the operator.

screenshot.png Overview

Operator object

The operator object is the extension assigned to the operator phone. Registered at it you will normally have at least one physical IP phone. The operator software will create a SOAP connection for this object to control the registered phone, in order to accept and create new calls. If there are more than one phones registered at this object, you can specify the Device (Hardware-ID) to use by the operator software. The operator object can be registered on every PBX (i.e. master or slave), it is only required that it is assigned to the same PBX as the Waiting Queue it will monitor.

Waiting Queue

As already discussed, the WQ object is needed to collect all calls meant to be handled by operators. The WQ object will distribute the calls to the available operators.

Query User

During the configuration of your operator software, you will have the possibility to enter a Query User object name. It is not mandatory to use this object, however it is strongly recommended. This object is used to create a SOAP connection, in order to search PBX users and to manipulate PBX user data (like Call Forward - and Presence info). Since you want to be able to see and change user settings on all locations, this object must be fish-help.png present on all slave PBXes.

If the Query User is an active group member, it can collect group informations from all members of this group. These infos enable the operator software to search for PBX users by group.

As can be seen in the screenshot.png picture, we have created a soap group for the Query_User. By putting all other users in this group, the operator will be a able to use their group infos for searching. In the example, User4 is not in the soap group. As a result, his group settings are not taken in account at the operator.

In case you don't want to use this searching feature, the soap group is not needed. In this case it should also not be created, since every group with active users will create additional CPU load for the PBX.

It was mentioned previously that the Query User object is optional. If you don't create this object, the operator software will use the Operator object instead. As a result you will have to replicate all Operator objects on all slave PBXes and make them all active members of the soap group. Therefore it is recommended to use this Query User object, since it will result in a much simpler and easier to understand configuration.


Operator in multi-PBX scenario

innovaphone Operator software is able to be operated in multi-PBX setups as well.

Depending on the use case, some different/additional setting are necessary:

Instead of using the standard-user for the single PBX in operator setup, one needs to use here the query user. As this is replicated over all PBXs and known there, it's able to query for any informations.

Additionally to the local users, PBX objects of slave PBXes need to be part of the query group. Otherwise no query of slave-user-data will be possible.

Of course it might be sufficient to have only dedictated operators per location each without possibility of handling calls from other locations. In this case above mentioned settings may be obsolete.

Overflow handling

The operator can monitor just one WQ. However you sometimes want the operator to handle other calls. In such cases, you must make sure these calls are somehow forwarded to the waiting queue the operator monitors.

If for example, surplus calls from a second queue (e.g. a remote location) shall be handled to take load from the initial operator, the special options and call forward attributes of the WQ object can be used. By using the option Max Call/Operator(%) you can define a percentage of acceptable calls per operator (e.g. 200% -> one operator can handle maximal two calls). With help of a Call Forward Busy (CFB), you can now reroute surplus call to the primary WQ. The operator will see the last diversion information on his screen, in order to handle rerouted calls as needed.

To forward calls to another operator if there is no operator available for a waiting queue, you can set a CFNR to the auxiliary waiting queue on the original waiting queue.


Live Debugging

The Operator software will give you some hints if something is configured wrong. You can see these hints in the status line at the bottom of the application window. It is also possible to save the error log to a file by clicking the icon in the bottom left corner of the application window.

Below you find possible errors and their causes.
  • Error: Initialize failed, HTTP-Status 401: Unauthorized.

The Operator software was not able to establish a SOAP session to the PBX. Check if the User and Password in the configuration of the Operator software are correct. Also check if the user-object has sufficient rights to login at the PBX via HTTP (at least cf-grp must be configured at the fish-help.png User Object Rights setting).

  • Warning: Lost PBX contact: ... Session-ID='Not OK'

The Operator software was not able to contact the PBX in order to monitor the users. Check if the Query User in the configuration of the Operator software is correct. Also check, if the user is replicated to all Slave PBXs (set the PBX attribute to empty in the Query User Object).

  • No connection to PBX / no display in any action-field

The V9-Operator requires a OpV9 Licence (=1). Existing OpV8 licences need to be replaced by OpV9 lics.

  • No calls are displayed at all:

Wrong PBX-group configuration - depending on the group assignment of the operator to the waiting-queue-group, calls will be signalled either in the WQ-section or in the operator-section (difference to V8)

  • No calls are displayed in the operator-section:

check if Alert-Timeout in WQ =0

  • No calls are displayed in transfer-list visible / no recaller-indication

check if PBX-recall-timeout is > 0

  • "Operator connect for SOAP" needs to be active in WQ
  • No query of all users in Master/Slave scenario possible

Query-User name needs to be used as user for the operator, the Slave-PBX objects need to be members of the query-group


It's possible to generate traces (permanently or on-the-fly) by activating the trace option within the file menu / file / misc.
One can access the directory where traces are stored by clicking the AppData-button. This tracefile is named swtrace.txt.


Beside the trace files for support tasks it might be helpful and therefore required to provide the operator config file to innovaphone support.
It is located in the same directory as the traces and named swconfig.txt.

Personal tools