Estimate Shifts

Owned by XCALLY Knowledge (Unlicensed)
Last updated: Nov 07, 2024 by Product Knowledge
6 min read

 

ON THIS PAGE

 

Estimate shifts

The platform also implements a system for the prediction of shifts. This system is based on artificial intelligence models that implement recursive neural network architectures (LSTM with time series) trained on real call data to optimize the amount of workforce available (by using standard parameters of Erlang C).

This system makes it possible to understand how many resources can be needed on a certain day at a certain time and to configure predictions you need to hook into the customer's database.

Estimate shift allows you to predict how many shifts you need to manage spots, starting from historical traffic (considering service, date and duration interaction).

From Manage Estimate shifts it is possible to create a prediction, entering certain parameters.

As connector you can select which one you want to connect to take all previous data to do prediction or you can select excel file

image (3)-20240327-103148.jpg

 

If you select Excel File then you can indicate:

  • file to import , with three columns (Service, Date, Duration).
    You can create a file like this one

The file format must be: YYYY-MM-DD and hh:mm:ss for the time in 24h format

  • Work time per day: full time of work an employee can work in a day, expressed in hours

  • Target service level: % of managed interactions

  • Target time: seconds within which to respond

  • Maximum occupancy: % of employees' work time to consider

  • Shrinkage: to define for example in a day % break time of employees (so unproductive time)

  • Interval: intervals duration expressed in minutes, minimum 15

  • Custom average handle time: to measure the average time of manage interactions, entered in seconds

 

 

If you select a Connector then you can indicate:

  • Work time per day: full time of work an employee can work in a day, expressed in hours

  • Target service level: % of managed interactions

  • Target time: seconds within which to respond

  • Maximum occupancy: % of employees' work time to consider

  • Shrinkage: to define for example in a day % break time of employees (so unproductive time)

  • Interval: intervals duration expressed in minutes, minimum 15 (granularity calculation to do)

  • Custom average handle time: to measure the average time of manage interactions, entered in seconds

  • Query to be launched for the algorithm, to tell which database data to retrieve

 

Configure the query

To configure the query, in order to integrate for example XCALLY to XPLANY for voice calls, it's possible to use a string like that:

SELECT SUBSTRING_INDEX(lastdata, ',', 1) AS service, calldate AS date, duration
FROM cdr
WHERE lastapp='Queue'

With this configuration, all incoming calls in the queue are filtered on all services.

If you would instead filter only certain services, you can use this type of string to create the query:

SELECT SUBSTRING_INDEX(lastdata, ',', 1) AS service, calldate AS date, duration
FROM cdr
WHERE lastapp='Queue'
and SUBSTRING_INDEX(lastdata, ',', 1) in ('Support', 'Sales')

So with this specific configuration with XCALLY integration, all incoming calls in the Support and Sales queues will be filtered.

Remember that you can use any MySQL database, connecting it with XPLANY.

In fact with all database types, to build the query you need to have 3 columns:

  • service to manage

  • date of interaction, e.g. when the call was made, when an e-mail/sms was received…

  • duration of interaction expressed in seconds.

System always needs these 3 columns to launch the prediction and the query can be launched on all the various channels.

For instance if you want to run a query on the mail service, you can create a query like that:

SELECT MailAccountId as service, createdAt as date, TIMESTAMPDIFF (SECOND, createdAt, updatedAt) as duration from mail_interactions

In this example you have selected all mail interaction, inserting CreatedAt as date and entering in duration the difference between date of first read message and the arrival of last interaction (obviously in the calculation of the interaction manage you need to remove the non-operating hours).

These are only examples and queries can be customised as required, depending on database type.

If you want to explore how to integrate XPLANY with XCALLY database click here

 

Collected data are then loaded into database, which is not a relational one, so it allows fast processing (compared to e.g. a mysql database).

Examples of queries

If you want to get only calls from a specific timeframe you can use one of the following queries.
E.g. this query gets the calls of all the queues from 2024-03-04 to 2024-03-10 (included) and doesn't consider the time the customer waited in queue for the duration

SELECT queue as service, queuecallerleaveAt as date,
        queuecallercompleteAt - queuecallerleaveAt as duration
FROM report_queue rq
WHERE queuecallerleaveAt >= '2024-03-04 00:00:00'
  and queuecallerleaveAt < '2024-03-11 00:00:00'  
  and queuecallerabandon = 0

If you want to also consider the time the customer waited in queue you can use this query:

SELECT queue as service, queuecallerleaveAt as date,
        queuecallercompleteAt - queuecallerjoinAt  as duration
FROM report_queue rq
WHERE queuecallerleaveAt >= '2024-03-04 00:00:00'
  and queuecallerleaveAt < '2024-03-11 00:00:00'  
  and queuecallerabandon = 0

If you want to consider only specific queues you can filter data adding a condition on the queue field. Example:

SELECT queue as service, queuecallerleaveAt as date,
  queuecallercompleteAt - queuecallerleaveAt as duration
FROM report_queue rq
WHERE queuecallerleaveAt >= '2024-03-04 00:00:00'
  and queuecallerleaveAt < '2024-03-11 00:00:00'  
  and queuecallerabandon = 0
  and queue in ('queue_1', 'queue_2')

 

 

Prediction

Clicking on Next, you can select spot for the service for which the prediction is to be applied:

Going on Next, the system shows statistics about prediction

  • Volumes of calls received

  • Average Handle Time (Aht): metric used to measure the average time of manage interactions

  • Fte: number of full time employees considered to be present to manage volume of estimated calls

Clicking on next, you can insert minimum number of employees to consider, minimum and maximum shift duration (entered in minutes) and range date and hour over which you want to make a prediction:

Clicking on next, the system shows a prediction of work shifts:

When you click on Save, the system copies all shifts created in the Scheduling section, from where you can add other resources if necessary or you can solve the scheduling, clicking on Solve Roster to assign unassigned shifts to employees.

Estimate shifts can be a useful tool to compare the prediction with the scheduling designed by the planner. For example it is possible that the planner had planned 8 employees for a shift, while the prediction considers 5 sufficient to still achieve the same SLA (Service Level Agreement), thus reducing management costs.

Moreover when you use forecast and save shifts in scheduling section, you can see a colored bar:

  • green if forecast=planned. So the number of shifts forecast is equal to the shifts entered

  • blue if forecast is not equal to planned (overstaffed). So to figure out how far you are deverging from the forecast (e.g. for the forecast the shift was not scheduled, but you wanted to put in at least 1 at a certain time)

  • red if forecast is understaffed, so for example for the forecast 4 employees are necessary, while you have entered only 3


By clicking on Save, from scheduling section, you can try to solve “error” coloured bar. So for example if you have red forecast, you can decide to add manually new shifts to respect the forecast.

 

Historical data

With XPLANY it’s possible to create API to insert historical data in database, which can be used in estimate shifts.
In fact if you have a service with interactions, you can create a plugin on your software (e.g. XCALLY - plugin coming soon) to be able to import data automatically. In this way you will see in this section the imported historical data.

Then you can use this source also for estimate shifts, by indicating in this case Historical data as connector and selecting a time range to consider (From - To)