inContact Developer Discussion

[logos]

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.

[MarkR]

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

[logos]

That would be grand, thanks.

[avallega]

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

[logos]

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!

[BrettC · Accepted solution]

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

[logos]

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?

[BrettC]

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.

[logos]

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

[TimHarris]

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