This document describes data structures that are used for reporting data. 

Data types and formats 

Data generation and storing

File naming

Data is exported in CSV-format, one csv-file per export type per day.

Export files are named useing following pattern: <date>_<orgname>_daily_<exporttype>.csv

The resulting filename is 2020-12-12_exampleorg_daily_calldetails.csv, which contains calldetails export of date 2020-12-12.

There are two options for data generation: daily and intraday

Daily

• All daily files are created at 0300 UTC, containing data from previous day.

Intraday

• Export files are created as 00:15 UTC of current day

• New data is added to the same file every 5mins.

Timestamps 

All timestamps are in UTC time, unless specifically stated otherwise. 

Phone numbers 

Phone numbers are stored in varchar columns. Numbers are normalized to E164 (+35850123...). Prefixing the numbers with plus-sign varies.

Export file retention

When using Enreach provided SFTP service, generated data export files are removed after 30 days.

Call data exports

Call data is aggregated to two different structures:

• Raw call event data is available for

  • DirectCalls

  • ServiceCalls

  • ServiceCallDetails

• Calculated data for calls are

  • Calls

  • CallDetails

DirectCall contains calls made directly to (and by) an individual user. Same logical call can also exist in ServiceCall data in two cases: 

• User’s incoming calls are handled by BeneCC work number queue. In these cases, ServiceCall.email is that of the targeted user. 

• ServiceCalls where Queue name is null can be left out of standard reporting 

• User’s incoming call is transferred to BeneCC. In these cases, ServiceCall.email is that of the targeted user, and Queue name is the first service pool call overflowed to. 

• Incoming DirectCalls where corresponding CallId exists in ServiceCall and Queue name is not null should be left out of combined reports 

DirectCall 

A single DirectCall entry is created for a call targeting a user directly. It is a simple structure, containing only a single row with no complex sub-event structure that is required for service calls. 

Export name: daily_directcall.csv

ServiceCall 

A single ServiceCall entry is created for each logical call. 

In current BeneCC use case, entry is first created with Ongoing result type when call connects to the system but is not yet completed. Result type is updated when call completes. 

For reporting use, fetching calls with non-Ongoing result modified since last fetch should be effective. 

Export name: daily_servicecall.csv

ServiceCallResultTypes 

ResultTypeId is calculated once when call completes. Result is calculated directly by finding a single latest event of types 102=QueueScheduleClosed, 201=UserAnswer, 204=UserTransfer, 300=QueueTransfer. 

ServiceCallDetail 

Each ServiceCall can have several individual events describing the progress of the call.  They are the primary way of performing reporting, as they provide the most detailed info available and provide the flexibility for different kinds of needs. 

Export name: daily_servicecalldetail.csv

ServiceCallEventTypes 

EventTypes represent different events that occur during a call
 

CallConnect (1) 

Logged when call connects to the system. 

Queue name is non-null if call was made to a number configured to a real queue. 

Email is non-null if call was made to a number configured to a user. 

Reason field in BeneCC use describes the type of the attempted target: PersonalWork for users, ServiceQueue for queues. In addition, Reason can also signal an error, for example if call was attempted to an unknown number NotInController is logged.
 

CallDisconnect (2) 

Logged when the entire call is disconnected and can be treated as complete.  

Queue name and Email are always null. 

Disconnect usually occurs when the caller disconnects either before or after the call is answered, or the answering user disconnects the call. The system itself can also disconnect the call for example when service is closed, and the relevant prompt has been played. 

For BeneCC, reason field describes the disconnecting party: local for system disconnects, remote for disconnects triggered by a remote party (either the caller or the answering user). 
 

QueueArrive (100) 

Logged when call is accepted and arrives to an individual queue. Allocation to agents is then attempted if available. 

Queue name is always the queue call arrives in. If Email is non-null, call arrived to a personal queue with logged queue name. 

For BeneCC, reason is always null.
 

QueueReject (101) 

Logged when queue rejects the call instead of accepting it. The event is not currently used for BeneCC-originated data.
 

QueueScheduleClosed (102) 

Logged when call connects to a specific queue that is closed for some reason at the time (usually outside of service hours). 

Queue name is the queue that was targeted but is closed. 

Email is always null. 

For BeneCC, reason is always null.
 

QueueOverflow (103) 

Logged when call overflows from one queue to another for some reason. 

Queue name is the attempted overflow target. 

Email is always null. 

For BeneCC, reason describes the technical reason for overflowing. 

• NoAvailableProviders: No users are available for allocation 

• QueueFull: Maximum queue length was reached 

• QueueTimeout: Maximum queueing time was reached 
   

QueueAllocateUser (200) 

Logged when queue allocates the call to a user. Call can be allocated to multiple users at the same time. 

Queue name is the allocating queue. 

Email is the allocated user. 

For BeneCC, Reason describes the type of allocating queue: PersonalWork for personal queues, ServiceQueue for real queues. 
 

UserAnswer (201) 

Logged when user answers the allocated call. 

Queue name is the allocating queue. 

Email is the answering user. 

For BeneCC, Reason describes the type of allocating queue: PersonalWork for personal queues, ServiceQueue for real queues. 
 

UserDisconnect (202) 

Logged when user disconnects the call from UI (BeneDesk). Disconnects from terminals are not logged as separate UserDisconnect events but simply in CallDisconnect. 

Queue name is the allocating queue. 

Email is the disconnecting user. 

For BeneCC, Reason is always null.
 

UserReject (203) 

Logged either when user rejects the allocated call actively or the allocation is cancelled for some reason. 

Queue name is the allocating queue. 

Email is the allocated user. 

For BeneCC, Reason describes the reason for reject in more detail: 

• Timeout: Maximum allocation time was reached. 

• CallDisconnected: Call disconnected during allocation. 

• GenericUserRejected: User either rejected actively or was found to be unreachable for example due to terminal being busy. 

• OtherConnected: Another agent answered the call (for simultaneous allocation).
   

UserTransfer (204) 

Logged when answering user requests a call transfer using the UI (BeneDesk). Both internal and external transfers are logged identically, later events describe where the call was actually transferred to. 

Queue name is the queue. 

Email is the transferring user. 

For BeneCC, Reason contains the transfer target number.
 

UserPark (205) 

Logged when answering user parks the call. 

Queue name is the allocating queue. 

Email is the answering user. 

For BeneCC, Reason is always null.
 

UserUnpark (206) 

Logged when answering user unparks the call. 

Queue name is the allocating queue. 

Email is the answering user. 

For BeneCC, Reason is always null.

UserOnHold (207) 

Logged when answering user places the call on hold. 

Queue name is the allocating queue. 

Email is the answering user. 

For BeneCC, Reason is always null.
 

UserUnHold (208) 

Logged when answering user retrieves the call from hold. 

Queue name is the allocating queue. 

Email is the answering user. 

For BeneCC, Reason is always null.
 

ExtQuery (250) 

Logged when the system queries an external system for routing information, for example to check if the customer should be routed directly to a prioritized queue. Actual query functionality is implementation-specific and related to a custom project. 

Queue name is logged if the query is caused by a queue configuration 

Email is logged if query is caused by user configuration 

Reason describes the query result. Value can vary by implementation, standard values are 

• OK: query receives an acceptable result 

• NOT_FOUND: no results found
   

ExtTarget (251) 

Logged after an ExtQuery event to describe routing targets received in response. Possible targets are queues, users and direct numbers. 

Queue name is logged if target is a queue 

Email is logged if target is a user 

Reason contains a semicolon-separated list of detailed information: 

• nbr: stored if target is a direct number 

• values: received target number (not necessarily normalized) 

• example: nbr=+358501231234 

• pr: if multiple targets are received, their relative priority (0 being the highest) 

• values: positive integer 

• example: pr=0; 

• req: whether to wait for target for time specified in parameter ttl. This only applies to user targets 

• values: bit 0/1 

• example: req=0; 

• ttl: how long requirement is valid. Currently used in combination with req flag to require a specific user 

• values: positive integer, second 

• example: ttl=30;
   

QueueTransfer (300) 

Logged when the call is transferred out of the system. 

Queue name is always null. 

Email is always null. 

For BeneCC, Reason contains the transfer target number.
 

QueueTransferConnect (301) 

Logged when externally transferred call connects to the external system (e.g. the transfer was successful). 

Queue name is always null. 

Email is non-null if transfer targets a number mapped to a known user. 

For BeneCC, Reason contains the target number.
 

QueueTransferCancel (302) 

Logged when external transfer is cancelled or fails. This occurs if the original caller disconnects during transfer, or if the transfer target rejects the incoming call. 

Queue name is always null. 

Email is non-null if transfer targets a number mapped to a known user. 

For BeneCC, Reason contains the detailed reason for cancel or reject: 

• CallDisconnected: Original caller disconnected the call 

• GenericUserRejected: Targeted user rejected the call 

SupervisionStatus (320)

Supervision status for the call has been changed.

Reason contains supervisor name and status

<status>:<supervisor name>

Possible values for status: SilentlyListening, Whispering, Participating, Exited, Entered.

IvrSelection (400)

Logged when caller has made (DTMF) IVR menu selection or entered some longer collected input.

StartBlockingPrompt (401)

Logged when prompt playing that prevents allocation to agents has been started.

WrapUpStarted (410)

Logged when agent wrap-up time started

WrapUpTerminated (411)

Logged when agent wrap-up time was terminated

CallbackCreated (500)

A callback request was created from the call

Queue is the last queue before leaving callback requests.

Reason contains Id of the Callback list the requests were created.

CallsExtended

Combined table consisting of both the Direct and Service Calls and with some measures already calculated at the call level. Contains usually one row per callid.

 Export name: daily_calls_extended.csv

CallDetails

Contains call details related to users and service queues with some measures already calculated. Contains usually multiple rows for each callid.

Export name: daily_calldetails.csv

Classification data exports

Classification data is exported in three different datasets

• Classifications

• ClassificationTags

• ClassificationSchemas

Classification 

Classifications for calls or external events. 

Export name: daily_clasification.csv

ClassificationTags 

Tags for individual classifications. 

Export name: daily_clasification_tags.csv

ClassificationTagSchemas 

Schema information for classification tags. 

Export name: clasification_tag_schemas.csv

Callback data exports

CallHandling (callback)

Table consisting of combined presentation of callback request / attempt information.

Limitations to CallHandling -exports in cases where callback process is handled within Dynamics or Salesforce

• Information from callback attempts are not reflected in these data exports.

• Requests are closed automatically when they are moved from Enreach Voice services to Dynamics or Salesforce.

• All callback requests are handled / closed by the same user (Salesforce or Dynamics Integration user)

 Export name: daily_call_handling.csv

CallbackAttemptType

Types of attempts that can be created. Different meanings for reporting/informational use, two main logical types (closing and not closing).

CallbackRequestType

Different types for callback requests