topic Re: .DAT files in inContact Developer Discussion

.DAT files

logos — Thu, 24 Sep 2009 16:00:04 GMT

I keep hearing about .DAT files that provide extra functionality that would be most handy... how does a developer get a list of these DATs and what they offer? I know that there is at least one for ONTRANSFER and another for speech recognition.

I'm sure some of these tools can help solve many of the problems we developers face or give us ideas for new funtionality. I'd really like to know what the platform can actually DO.

Re: .DAT files

MarkR — Thu, 24 Sep 2009 21:09:55 GMT

I will see if I can get a list from our product team.

Re: .DAT files

logos — Thu, 24 Sep 2009 22:19:43 GMT

That would be grand, thanks.

Re: .DAT files

avallega — Thu, 01 Oct 2009 12:59:22 GMT

I will definitely need this for my "transfer" script.

Also, if you can update your incontrol documentation to include details on what the "ontransfer" does.

Thanks

Alejo Vallega

Re: .DAT files

logos — Thu, 01 Oct 2009 15:31:47 GMT

Do we have any action on this yet? I'm set to start creating a new company's set of scripts, and really want to know what is available to me so that I don't waste time with workarounds for things that are built in!

Re: .DAT files

BrettC — Thu, 01 Oct 2009 22:23:10 GMT

The actions available within inControl are stored in a local file named "incontrol.dat". inControl has been designed to display the actions from other .dat files stored in the inControl folder. From time to time our customers present some unique challenges that are best solved by introducing a new action. Most of the time new actions are made available to all users, but some have been set aside for use primarily by our Professional Services team. For a variety of reasons, these actions are not made generally available, but can be shared with customers who demonstate a specific need. Those actions designed primarily for internal use are not necessarily documented documented at this time.

ASR.DAT

Description:

Contains the actions required for automated speech recognition.

Availability:

Upon request & purchase of ASR

Actions:

ASR, ASRSQL, ASRMENU, ASRYESNO, ASRDIGITS, ASRNUMBER, ASRCURRENCY, ASRALPHANUM, ASRDATE, ASRTIME, ONUNIVERSAL

CONCATWAV2.DAT

Description:

Merges two separate audio (.wav) files into a single audio file.

Availability:

Upon request

Actions:

CONCATWAV

CUSTSPEC2.DAT

Description:

Appends very limited information to the contact's associated long distance record. This information is only useful to customers who access their monthly LD invoices electronically (since that is the only place where the data is found).

Availability:

Upon Request

Actions:

ADDCFR

QUE.DAT

Description:

Places a contact_id into a centrally managed queue (NOT an ACD queue). When the 'added' contact_id reaches the top of the queue, the system signals the script that invoked the ADDQUE.

Availability:

Upon request

Actions:

ADDQUE, REMQUE

TRANSFER.DAT

Description:

On event action that fires with an agent has transferred the call to another agent.

Availability:

Upon request

Actions:

ONTRANSFER

FROM2.DAT [Upon Request]

Description:

Specific to email scripts. Enables user to set an alternate "from" for email responses from the agent.

Availability:

Upon request

Actions:

FROMADDRESS

INCONTROL.DAT [General Availability]
All other actions

Re: .DAT files

logos — Thu, 01 Oct 2009 23:18:21 GMT

Ooooo, QUE.DAT is sexy. Too bad my predecessor didn't have that, he poured quite a bit of effort into a workaround.

Provided it works like I think the description says it does, that is. I envision it as something I coulduse to enque calls for a single agent, say if they were busy and the caller selected to 'wait for agent to be free'. Could you elaborate on this one for the audience at home?

Re: .DAT files

BrettC — Fri, 02 Oct 2009 15:26:31 GMT

ADDQUE is used to place a contact into an inContact-supported queue (not related to ACD queuing). The parameters of ADDQUE are as follows:

Name

The name of queue to use (keep in mind, this is NOT an ACD queue)

Contact

The contact_id that is to be signaled when it reached the front of the queue

Max

The number of concurrent contacts to be used by the queue

Priority

Add this contact to the top or the bottom of the queue

An example usage is as follows:

1. A caller dials into inContact (and thus, a script)

2. The script plays an appropriate greeting, places the caller into the special queue (via ADDQUE) and then plays hold music.

3. < ACD stores all the queue contacts>

4. When the queued contact_id reaches the front of the queue, it is signaled (thus firing the ONSIGNAL action of that script). Upon ONSIGNAL, the value “SP1” is set to “QueueSignal” so the script knows the source of the signal.

5. The script then fires the TRANSFER action and completes the transfer.

6. The script can remove the contact (using REMQUE) at any time, or it will automatically be removed when the contact ends.

This example is, of course, just one application of ADDQUE. This is a viable solution when multiple contacts need to be queued in an non-ACD fashion. ADDQUE is useful in very specific and specialized situations, but most inContact customers would never have a reason to use it.

This is not a good solution to allow a caller to wait for a single agent to become available. Such a solution doesn't require a centralized non-ACD queue. You would want to play hold music to the caller and periodically invoke AGENTSTATE to discover if a given agent has become available. There is no way to receive an event when a specific agent has become available ... you have to poll.

Re: .DAT files

logos — Fri, 02 Oct 2009 15:36:19 GMT

Well, poo on not being able to have individual agent queues :P But thanks for the info!

Re: .DAT files

TimHarris — Fri, 02 Oct 2009 15:44:26 GMT

Tyler,

We do have Agent Queues and you can place contacts in queue for the agent directly. If you queued them at a higher priority than your inbound skills than you could ensure the caller was the next to be received by the specific agent. You would still want to check the agents state like Brett suggested above to ensure the agent was there and periodically to ensure the agent didn't leave them in queue since the agent could stay in a unavailable state after a call.

Thank you,

Tim

Re: .DAT files

logos — Fri, 02 Oct 2009 16:13:22 GMT

Actually, what I'm looking to do is 'park' calls so that an agent can pick and choose which caller to talk to - ie, a q that they can personally manage to deal with more than one caller at a time, popping and pushing calls into the q.

(eg) agent is on phone with caller. another call comes thru the IVR that requires that agent specifically. An icon lights up in myagent to inform the agent that another call is waiting for them. They can then use a custom menu option to park the call (ie, put it into the personal q) and then pick up the other call (or possibly listen to a menu to choose amongst several callers), deal with the caller, then unq the next call from their personal q

Re: .DAT files

WesChipman — Fri, 02 Oct 2009 17:13:41 GMT

I've actually parked a call. You're right on track with the Custom Menu. I did it by tying it to an icon on the MyAgent window using an Indicator action in the script. When the agent double clicked it it spawned a chat script (so it wouldn't use a voice port) that sent a Signal to the call the agent was on. Attached to the On Signal event I waited a few seconds so the agent could get the next call they wanted then re-queued the caller with a custom priority that was very high for that specific agent they were talking to previously. Then when the agent is done with the new call, the call they parked will be the next one they get. Doing it with multiple calls and a menu may be tricky, theoretically it may be able to be done but I would be apprehensive to try it without a table to accurately keep track of the active calls.

Re: .DAT files

logos — Fri, 02 Oct 2009 20:17:43 GMT

Yah, that was what I was hoping to use the QUE.DAT for instead of a table of some sort for q management.