QM lets each agent have his/her own page, where they can see the current flow of calls they have just answered and launch external CRM web apps.
This is quite useful, because the agent can:
- see their own status, i.e. whether they’re logged on or they’ve been disconnected;
- see their last calls, including information like Caller ID, duration and waiting times;
- see from which queue the call is coming, even if they lost the announcement message;
- launch external web apps - like CRM software - that might be automatically linked to the Caller-ID or other information input by the caller
- read the messages broadcasted to him
- start a new conversation calling a phone number
- have a subset of AGAW information
- track information about the current call on QA forms
Also, it is possible to use this page in order to:
- Log the agent on and off to Asterisk and/or a specific queue
- Pause and un-pause the agent, entering the pause activity code if needed
- Set the outcome code for each call
To avoid excessive consumption of system resources on big centres, only the most recent part of the log file is processed and so only a few calls are shown.
In order to use this feature, a user must be configured as having the same login as the Asterisk agent string (e.g., "Agent/101") and it must hold the key AGENT. Our suggestion is to use the same set of credentials the agent uses to login to the Asterisk system.
When the agent logs on - you can try this by using the demo account Agent/101, password 999 - s/he sees a reduced home page like the following one:
As of release 12.10 the Agent page includes a Home button that allows to get back to the above agent web page at any stage (no security key or property are required to enable this feature) and one or more reporting options selectable by queue, report type and durations.
This block of reporting functions is made visible for agents by enabling the SSAREPORT key within the user configuration/administration page (Cfg Users tab), which can be reached by selecting the Edit users link form the main QueueMetrics administrator Home page. An agent can run a report based only on the queues and reports assigned to him/her. The agent does not have a Search button enabled, so s/he is not able to access any kind of Custom Reports. The reporting can be run directly from the agent web page.
See section Section 21, “Editing QueueMetrics settings” for further details.
By clicking on "Show inbound calls", the agent is led to the inbound calls page:
This page tells the agent that he’s logged on and shows the last calls he has handled. This page lists also a subset of AGAW information related to the logged agent. In this case we see that there is an ongoing conversation and many previous calls.
On top of the page a field tells the agent whether s/he is:
- Logged on: ready and able to take or make calls;
- Logged on queues: followed by the list of queues the agent is dynamically logged on through the Add Member button;
- Logged off: the agent has voluntarily left or has forcibly been disconnected by the queue system;
- On pause: the agent has asked for a pause from the queue system;
- Undetermined: whether there is no relevant information to tell the agent status in the last part of the log file.
The fields the agent can find in the call list are as follows:
- Entering at is the date and time the call entered the queue system;
- Waiting is the waiting time before being connected to the agent;
- Talking is the talking time for that call. If the call is ongoing, the time will be estimated and written in red.;
- Caller ID is the call’s identification, if available;
- Queue is the queue handling the call;
- URL is a clickable link that opens a third party CRM app. The agent opens the third party CRM app by clicking on it, or QM can open it up automatically the first time the URL is presented. If the URL contains bracketed placeholder sequences, they are expanded (see below)
- Status is whether the call is ongoing or terminated;
- Transfer is the extension the call was transferred to (if any).
- Outcome is the call outcome that the agent can set for this call. This must be set within a maximum timeframe of 30 minutes from the moment the call enters the queue; after this given period the call outcome cannot be added as the icon is no longer present.
- QAForm This icon allows specific agents to access the QA form for the call, but only if such agent holds the QA_TRACK key.
After the call list table, if enabled by configuration as explained in Section 21.16, “Configuring system preferences”, a table lists the AGAW information related to the atomic queues the agent is working on. For more information about the AGAW subsystem, please refer to Section 11, “The Agent Awareness subsystem (AGAW)”.
To avoid hammering the QM server with excessive work, only the last piece of the log is analyzed. This parameter can be fine tuned by the system administrator in order to maximise usefulness without creating an excessive server load (see Section 21.16, “Configuring system preferences”).
Whenever an agent receives a call, s/he should press the "Reload" button on the page in order to see the incoming call. If you use a SQL storage mode, you can enable Section 8.4, “Auto-refreshing the agent’s page: Active Polling” in order to have the page reload automatically when a new call is detected.
The page reloads automatically every two minutes in order tomaintain the user logged on in QM.
Each time the call history changes, and if there is an URL associated to the call shown on top of the list, a new window will automatically be opened pointing to the specifig URL. This feature could be disabled modifying the value associated to the configuration key realtime.agent_autoopenurl as specified in Section 21.16, “Configuring system preferences”.
URLs are passed to the Queue() command in Asterisk, or - if missing - they can defined in the QueueMetrics queue configuration as a default. They can include a set of placeholders that are expanded with the details of the call being handled, as in the following table.
| Placeholder | Meaning |
|---|---|
[A] | The agent’s numeric code, e.g. 101 for Agent/101 |
[U] | The call’s Asterisk UniqueId |
[S] | The Server ID (for clusters) |
[Q] | The name of the queue |
[T] | The timestamp of the call |
[C] | The caller-id, if present |
[D] | The DNIS, if present |
[I] | The IVR Path, if present |
[O] | The outcome code, if present |
[P] | The position in the queue, if present |
[M] | The attempts, if present |
The buttons on the agent’s page can be used to log agents on and off, to dynamically add or remove them to one or more queues, to dial a phone number, to pause and unpause them and set the call status. Each button could independently be enabled or disabled changing the associated key value in the configuration. When pressed, each button will open up a pop-up window asking for details:
As of QM release 12.10 it is possible to set input validation for both the agent code and the extension. As an example, by setting the key realtime.agentRegexp=1\\d\\d you are defining that the agent code must start with a one and cannot be more than 3 digits, while by setting the key realtime.extensionRegexp=\\d\\d\\d\\0 you define that the agent extension must be four digits and must end with a zero. Please note that the backslash in the regexp has to be written as \\ in the configuration.properties file.
Once the user clicks on Run, the command will be sent to the Asterisk server and the page will be reloaded. It is possible that on very busy machines the commands may be delayed a few seconds, so that it is necessary to reload the page manually in order to check that the command has run successfully.
Please note that for this to work it is necessary that Asterisk has been configured to manage Agent actions - it will NOT work on an Asterisk server that’s not been specifically configured to work with it!
See section Section 24.10, “Enabling Agent’s page actions” in order to set up this feature.
If you want to have agents logging on, it is mandatory that the underlying Asterisk agents are defined without a password.
It is now possible to allow agents to run specific reports directly from the agent page. These new features are available as of QueueMetrics version 12.10 and are already enabled for the included sample agents. In order to configure other agents having the same functionalities available, the following steps need to be implemented:
- Assign a queue (or a set of queues) to the agent
- Assign a new report to the agent
Assign the SSAREPORT key to the agent
- To assign a queue to an agent, select Edit queues from the Home page, select the Assign reports to agents icon, select the check-box next to the chosen agent. Save to confirm.
- To assign a report to the agent, select Edit reports from the Home page, select the Assign reports to agents icon, select the check-box next to the chosen agent. Save to confirm.
- To assign the SSAREPORT key to the agent, select Edit users, select the pencil icon, add the key to the User keys field. Alternatively, it is possible to assign the SSAREPORT key to all agents by editing the agents class by selecting Edit users from the Home page, select the Show classes button, select the pencil icon of the Agents class and add the SSAREPORT key in the Keys field.
This new block of reporting functions is made visible for agents by enabling the SSAREPORT key within the user configuration/administration page (Cfg Users tab), which can be reached by selecting the Edit users link form the main QueueMetrics administrator Home page. An agent can run a report based only on the queues and reports assigned to him/her. To assign queues to an agent you have to select the Edit queues link from the QueueMetrics administrator Home page and select the Assign reports to agents icon next to the queue you want to assign. This will take you to the page where you can simply assign the queue to the chosen agents.
When assigning reports, the same criteria applies as assigning queues, where we access the report configuration page from the Edit reports link on the administrator Home page. Selecting the Assign reports to agents icon takes to the page where you assign the selected report to each agent.
An administrator can also assign the maximum amount of time that an agent can have available, when viewing historical reports from the agent web page. The key default.ssarMaxReportPeriod is defined within the configuration.properties file. If this key is not present within this file, then the default time is 15 (days).
When an agent runs a report, the agent does not have a Search button enabled, so s/he is not able to access any kind of Custom Reports.
It’s possibile to have a maximum of four buttons fully customizable in the realtime agent’s page. These buttons could be used to:
- Open a new browser page
- Dial a predefined extension.
By changing some configuration settings, each button can be:
- Enabled/Disabled globally
- Have a custom label assigned
- Have an URL specified. If [A] or [U] are specified inside the URL, QueueMetrics will expand it with the numeric Agent code or with the Unique Call ID of the last call processed (if present, otherwise Unspecified will be used).
- As an alternative to the URL, have two Asterisk call legs specified that will be dialed when the button is pressed. The placeholder [A] is exanded - if present - with the numeric Agent code.
The image below shows the buttons in action.
To have more details on the configuration settings involved, please read the Appendix D, System preferences.
In the following example, the first two buttons will open an external web page; the third one is disabled and the fourth could be used to start a call to the secretary. When a button is associated to a dial action, when pressed, it will be highlight in yellow as shown in the picture below.
Please note that buttons will be hidden if there is not at least one button enabled. To have more details on the configuration key details, please read Appendix D, System preferences.
In default mode, QueueMetrics asks for an agent to push the Reload button on the agent’s page in order to refresh the page. This was needed to avoid hammering the server with hundreds of requests at once.
Since QueueMetrics 13.04, it is possible to have the agent page reload automatically when running the Row Cache; and you can therefore have a screen-pop that is completely automated. The idea is that a very lightweight transaction is run to check whether there is new data that might involve the agent; if there is, a page refresh is performed an all data is recomputed.
The following preferences must be set in configuration.properties:
realtime.useActivePolling=true realtime.ajaxPollingDelay=5 realtime.useRowCache=true realtime.agent_autoopenurl=true
As this setting depends on the Row Cache - see The Row Cache the section called “RAM cache inspector” - is is mandatory that you use a SQL-based storage type.
![[Tip]](images/icons/tip.png){kind=icon} | Tip |
|---|---|
to confirm that Active Polling is working, look at the date and time value on the bottom right corner of the agent’s page. When Active Polling is working, you should see it change every few seconds. |
QA forms - described in detail in Section 13, “Advanced tracking of agent and grader performance” - can be used on the agent’s page in order to gather generic information about the current call. They may act as a kind of embedded database of calls that is accessible for reporting within QM itself.
In order to turn on the filling of QA forms by agents, you need to:
-
Make sure your agents hold the
QA_TRACKsecurity key. You might consider adding it to the Agents class. - Create special QA forms to be used by agents. You can use security keys to make sure that your agents have access only to the forms they are supposed to see, versus forms used for "proper" QA tracking by QA specialists
- Create form items made of multiple-selection or "Yes/No" questions
- In agent’s forms, all or most questions will be non-scoring, as you are gathering information and not evaluating an agent’s behavior
- QA forms can have multiple sections that turn on or off based on the answers to other questions. Questions can also be made optional.
- You can associate free-text comments to QA items by clicking on the pencil icon on the right-hand side of the question
Running a large set of agent pages may impose a significant burden on a QueueMetrics system. The best way to run them is to:
- Use SQL or CLUSTER storage types
- Set the lookback period to the minimum usable period - you control this by setting the realtime.max_bytes_agent property to the number of seconds it must look back. For example, if your agent shifts are of 6 hours, you could use a number between 22000 and 25000.
- Turn on row caching - this allows QM to keep cached and pre-processed copies of objects it needs to run the Real-time and Agents Page. This may offer a significant speed up, ofter by an order of magnitude, and will reduce database load. You turn on this feature by setting realtime.useRowCache to true.
- If you use Active Polling, try and increase the polling delay.
- Tune Java memory for maximum performance - see the Advanced Configuration manual.
- Consider AGAW as an alternative to running thousands of agents pages at once.