Howto:IQM CallBack requests

From innovaphone wiki
Revision as of 18:14, 24 February 2020 by Kwa (talk | contribs)
Jump to navigation Jump to search

Some Call-Center (CC) handles a lot of mostly simple standard requests.

For example Customer who request an appointment. During heavy traffic those requests “on top” of the normal workload causes a not brilliant quality of service during those periods. For example during the morning the CC is very busy and should not answer to specific standard requests, while those jobs can be done perfectly during afternoon because there is no or less traffic. So the CC prefers doing a call back to those customers in periods with low traffic. Or generally spoken the CC simply prefer call back certain request then answer immediately.

So the caller should hear a voice menu and enter his phone number for being recalled. This information should be stored by the system and processed from the agents when they have time; manually they should decide when recall the customer.

You can name that even as a kind of advanced “please call me back” feature.

iQM in collaboration with a XML can do that “out of the box”. Continue reading to discover how.


Applies To

iQM version 2.00 or higher (build 8130)

Tested with WIN7 (because of network drive mapping bugs in windows not clear if working in all MS-OS)

Tested with innovaphone PBX version 10, should work even with version 9.


More Information

First question: why must the caller indicate his phone number (and not the system retrieves the number from the PBX)?

Well this is not a technical problem, it is easy to modify the XML script and take the number of a caller (eventually prompting it and request confirm). But remember that the CC wants to be sure that the number indicated is the correct one. Consider also that often the calling number is not the one where a callback is required. So additional questions would be necessary and confuse the caller. For example because the caller calls with the mobile phone, but want be recalled on the fixed phone at home or similar. Therefore in this version it is realized in this simple way (but this can be modified easily in the XML script).

In this description the PBX part is skipped, so is not described how the distinction in calls is done, that depends and can be realized in many mode. For example there is a special number you can call for that feature, or in a previous Queue a menu ask if you want to leave a request of this type, or in the PBX there is an overflow configured and if there are many incoming calls they will be forwarded, or there is a call forward no answer or a Boolean object can be switched or similar.

Note that the sample file contains all the audio prompts, but of cause in your setup the wordings will be different, so the files are not really usable and you have to record your own (see installation hints). To explain and understand better we separate the two phases of the process, the call from the customer (the “request”) and the processing from the Agent (the “processing”).

the customer (caller) menu

The customer (caller) job is entirely done using a XML script.

If a call came to this XML the caller will hear the following sample messages, for better understanding we indicate a possible theoretical short wording of the message (in brackets is indicated the name of the prompted voice file):

Step1: Wellcome

(Track101.) “Wellcome to…”

Step2: Request of action

(Track102.) “For a recall please enter the phone number and confirm with hash”

The script waits until the caller ends his selection with hash.

Step3: Prompting

(Track103.) “Your phone number is” + spelling of the indicated number

Step4: Confirming phone number

(Track104.) “If the number is correct confirm with hash, if you like to modify the number press star”

Step5: Thanks

(Track106.) “We have recorded your request and will recall (process you order) as soon as possible, thank you for your collaboration”


Please note that the indicated flow is just an example, feel free to modify the script and prompts.

There is a security general time out in the script, so the script will force a release after 300 seconds if the caller won’t release.

If a caller will not confirm the entire process (giving up during the menus or not confirming with hash) no job is created for the agents.

If anything is going fine the script writes a file in a subdirectory “/DATA” where the filename is the indicated number.

That is what basically the XML script does; so as long your PBX is running even the service will work (even if the iQM server is down). The rest of the job is done by the iQM server and Agent Software. The files are empty, therefore the number of files is the theoretical limit for the number of jobs queued (forget it).

the iQM Agent processing

Once a caller has done a request the iQM server will read out the file form the CF and store it internally. All enabled agents can see how many recall-jobs are in the queue:

IQMIVR03.png

In the example no job is pending. To open the Job window just press the relative symbol in the agent view main menu near the counter (like opening all the other windows in this application).

If the agent opens the Job window without jobs in queue he will see this empty window:

IQMIVR04.png

If instead a Job was in the queue it will be loaded and displayed automatically:

IQMIVR05.png

If a Job is loaded it is reserved for that agent and so blocked for other agents. A loaded job shows the number to recall and date and time when the request comes in.

The agent can now recall with a click the number indicated by the customer. All agents see even how many jobs are still open and how many jobs are “in work”, so loaded from other agents. Once a job is loaded it can be put back to the job queue (for example if the called number is not answering, or the agents found out that this job is not a good idea for himself to recall). Returned jobs will pass at the end of the job queue, in this mode a new job request will not assigned again the same one.

But typically the number is called, to do this the agent press the relative key and his phone set will automatically call the number.

Pressing next job from stack means go further and load the next job; this operation will clear the actual job and load the next one. If the agent called the number that is done immediately, if not a warning triangle is displayed. That means warning, you clear a job without previously calling the customer:

IQMIVR06.png


If the agent confirms the clearance (clicking on the warning triangle symbol) the job is cleared and the next one is loaded.

The entire described behavior (more complicate to describe than to do) is designed to allow a quick standard reaction; normally the agent will load a job from the stack, call the customer, and the load the next one etc. If a customer is busy or not the one desired he will return the job and request the next one etc.

If the agent request to the next job from the stack and there is no one the Job window without jobs in queue is displayed (the first in this description).

Here a sum up of the job window:

IQMIVR07.png

1.. Number of jobs waiting for process in the iQM server

2.. Get next job from the job stack

3.. Return actual job to the Job stack

4.. Warning, customer was not recalled (confirm job cancel pressing on symbol)

5.. Call customer

6.. Number of jobs in process by other agents

7.. Number to call

8.. Date and time when the customer enter the request


If a job is cancelled erroneously but the call was done, the agent will find the call in the call history of his phone (last 100 calls are stored in the innovaphone phone set) and/or in the myPBX call list. If the customer was not called and the agent confirmed erroneously the cancellation, the call can be retrieved in the special iQM server job log file.

Note that an eventual reporting will fail in this case, because DTMF dialing is not recorded in the reporting tool.

The counter for IVR jobs is a two digit counter, therefore “99” means 99 or more jobs open. So if there are for example 150 Jobs open the counter will show 99 till only 98 are open.

Log file

Build 80266

In the older builds a log file was written each time a entry in the messed call list or in the Call Back Request list was deleted.

From Build 80266 on also the new entry and each call will cause e line in the log.

The file name is “iQM_IVR_Log_YYYY.csv” and it will be automatically created if not present in the directory of the log files. The path is the one indicated in the setup of the iQM server for data (default = user/appdata/roaming). For each year a new log will be created.

Example: “iQM_IVR_Log_2020.csv” stores the log data for the year 2020.

The file is a CSV text file, the separation character can be set in the iQM setup, if no character is defined space will be used (not recommended because Agent Names could contain spaces too).

Each record (line) contains the following fields:

• Timestamp

• Source (CB/MC/US)

• Action (CAL/NEW/DEL)

• Status (CALLED/NOCALL/FROM or nothing)

• Number

• User (if any)

• Stored (Timestamp if any)

Source CB = Call Back Request, Source MC = Missed Calls (form the missed call list), Source US = user, the indicated agent put in this call manually in the CBR list

Action CAL = Number was called, Action NEW = New Entry, Action DEL = Deleted

Status CALLED = the number was called, Status NOCALL = the number was not called, Status nothing for new calls

Example 1:

20/02/2020 09:21:57;MC;NEW;;0451234;;

Day 20/02/2020 at 09:21:57 the number 0451234 call the queue and gives up, a new entry in the missed Call List was written.

Note: If this number will call again no new entry will be written in the log, but in the missed call list the user see that this number has called twice.

20/02/2020 09:22:48;MC;CAL;CALLED;0451234;Laura Toffali;20/02/2020 09:21:57

A minute later at 09:22:48 the Agent Laura Toffali called the number 0451234 from the missed call list, note the entry timestamp was 20/02/2020 09:21:57

20/02/2020 09:24:44;MC;DEL;CALLED;0451234;Laura Toffali;20/02/2020 09:22:48

At 09:24:44 the agent Laura Toffali delete the entry with the called number 0451234, last call at 20/02/2020 09:22:48.

Example 2: The entry was just deleted from the agent Laura without calling back:

20/02/2020 09:21:57;MC;NEW;;0451234;;

20/02/2020 09:22:48;MC;DEL;NOCALL;0451234;Laura Toffali;20/02/2020 09:21:57

Example 3:The call was stored in the missed call list but no further action up to now was done by the agents:

20/02/2020 09:21:57;MC;NEW;;0451234;;

Example 4: The call back request (IVR) was used; a new call back request was stored, the user was called and after immediately deleted:

20/02/2020 09:54:54;CB;NEW;;333123;;

20/02/2020 10:10:30;CB;DEL;CALLED;333123;Laura_Toffali;20/02/2020 09:54:53

Please note that some seconds of difference in the timestamps are possible because of processing delay.

Example 5: Call back request without calling back but deleted by the agent:

20/02/2020 09:54:54;CB;NEW;;333123;;

20/02/2020 10:10:30;CB;DEL;NOCALL;333123;Laura_Toffali;20/02/2020 09:54:53

Example 6: The call back request was registered but no agent calls back or delete the entry:

20/02/2020 09:54:54;CB;NEW;;333123;;

iQM server

If the iQM server is able to access to the CF directory automatically in the main view appear the symbol that the service is on (2).

IQMIVR02.png

The first counter (1) shows the number of files loaded (1 in the example), this is the same number that all agents will see in their local view.

The counter on the right side of the symbol (3) shows how many jobs are actually open by the agent. So if in the example an agent take the job the counter (1) goes to zero while the counter (3) switch to one.

The counter (4) is a total counter, each time a job is canceled this counter (in the example 112) is incremented.

A supervisor can so check the real situation at a glance, how many jobs open and how many in processing.


Installation and setup

The xml script plays pre-recorded files and stores the caller input on the CF in a file located in a subdirectory /DATA. The name of the file is the indicated number, the content of the file the eventual second number (the order number or similar).

The iQM server read out the file in the CF, stores it in the PC memory and delete it on the CF. If the iQM server program will be terminated the jobs are stored on the hard-disk and loaded when iQM starts-up again. The time period for reading the CF as well the deleting is done extremely slow (5 seconds between requests), because the CF can be a very slow device if operating in small devices. This is not a real limitation because the timing is not a real problem for this feature. Usually also there are not a lot of files on the CF (situation just possible if iQM is off). Being the XML always on while the PBX runs even if the iQM is offline the jobs are not lost. The iQM read out max. 99 files and leaves the rest on the CF; they will be read out if the files are processed (cleared). The reading out is done respecting the time of arrival, so the oldest first, even the processing is respecting the time of arrival.

The XML has to be installed on a partially fixed path, here an example:

http://x.y.z.w./DRIVE/CF0/iQM/iQMIVR.xml?$_pbxcoder=g711a

As you see in the string all voice data are coded in G711a, so even the calls must be in this format. The advantage is that the best voice quality in IVR is often not really good. There is typically no “remote” access, the line and the XML are in the same network. If not, you have to change the option and record all prompts in any codec (or convert it).

The path has to be the one indicated because iQM simply search in this directory (or better in the path and subdirectory /DATA) if there are “job” files). The “/DATA” directory has not be configured manually; it will be generated automatically by the script itself.

After creating the directory copy the XML and all other files in the directory iQM.

You will see all the Track files indicted previously and also the prompt files for the numbers (0 to 9, star and hash, observe the file name for example _09.g711a for the “9”, create those files). Create the VM object in the PBX, remember that there is no license necessary to do that.

Now you have to create the voice files, the names and conceptual content is indicated in the description of the call flow.

The silence.g711 file is in the package while the file for prompting the numbers (0 to9, star and hash) has to be recorded.

While the Track files can be recorded using the track recording tool the numbers can be recorded using that tool to, but you must rename them after recording. Or you use another technology for recording it, see relative link.

Here the list of the required filenames (contend should be obviously):

_1.g711a

_2.g711a

_3.g711a

_4.g711a

_5.g711a

_6.g711a

_7.g711a

_8.g711a

_9.g711a

_star.g711a

_hash.g711a


There is a text file, “prefix” that should be edited with a text editor before copy them on the CF. The “prefix.txt” file contains a prefix for recalling. Of course the caller indicates his number, but for recalling him it must be inserted a prefix (typically the “0” for the trunk line).

Now you can try the XML, follow the prompts and create a job, if anything works fine files in the /DATA will be created files. The half of the work is done.

NOTE: From Build 80081 on no more drive will be mapped, the access to the compact flash is done via http.

The input is similar to the voice recording pcap access. See examples displayed in the setup window.

User manual

Simple, Help yourself.

Being a very individual solution a general user manual (in many languages) is not possible. Even describe all possibilities as done in this description will just confuse an agent. Therefore you must adapt an eventual description on your real setup, voice prompts etc. Anyway you can user the pictures in this article if you like.


Download

XML available soon...

Related Articles

Howto:Queue_Monitor_-_Overview

Howto:Universal_Track_Recording_Tool

Howto:Creating_fine_announcements_and_music_on_hold