• First we make the shift-plan that fits best the predicted HR need (by Prophet) (parquet algorithm). If the sum of employees working-time frame (sum of parquets) is less than the calculated HR curve (most of the cases it happens) the parquet algorithm follows the shape of the curve even if the shift-plan stays below the curve.

• Then we let the employees bid with their scores (for about 10 days).
  It can be done from home, too.

• Then comes the roster algorithm that assigns the appropriate employee to the appropriate shifts.

• The result can be analysed: Is there any labour regulation violation?
  What is the satisfactory rate of preference bidding? (What percentage of wishes were fulfilled?)

• After changing the input parameters the roster algorithm can be run again.
  It is a kind of “what if” experiment.

Work distribution curve prediction: Prophet

A new traffic forecasting algorithm, Prophet, is currently being implemented and is available on a separate website for the time being:

After appropriate parameterization, the result will be provided in an Excel file, which can be imported directly into Rostar.
If you want to make a forecast based on traffic data, you can use the so-called
SEC (Simulated Erlang Calculator) to convert the forecasted traffic into a staffing plan.

The next two pictures give you an insight into what is behind the scenes to create these forecast Excel files:

In the figure below you can see the function components used by Prophet to generate the forecast for the selected period. From this, you can turn on or off the “Hosszútávú tendencia figyelése” (Long-term trend monitoring), which is indicated on the graph as “trend”. You can also adjust the extent to which the bottom three graphs are taken into account by changing the “Szezonalitások súlya” (Seasonality weight) setting:

In the next graph, you can see how combining these components produces a function.
In the full year graph, we have zoomed in on a 5-week period. This is exactly where the actual data (marked with black dots) ends and the predicted results begin:

Prophet tutorial video (hungarian):

Simulated Erlang calculator: SEC

If you have made a forecast based on traffic with Prophet, you will also need an Erlang calculation to convert the forecast traffic into a staffing requirement.

That’s what SEC is for, which is not just an Erlang C calculation, but (as the word Simulated in the name implies) will perform one (or more) simulations based on the parameters you set. Then, based on these results, the number of operators needed for a given traffic will be calculated.

SEC tutorial video (hungarian):

Erlang calculator

With this functionality of the SEC we can calculate two types of results:

1. The required number of employees:
   In this case (obviously) the Employees (Dolgozók) parameter is not taken into account, as this will be the result, depending on the other parameters.

2. The Current Success Rate:
   Here the set Success % (Sikeresség %) will be ignored, this will be what we get as the result.

Explanation of parameters:

• Success rate (Sikeresség): This is the percentage of customers handled within the SLA timeframe specified below compared to the total.
• Break in minutes (Szünet): How many minutes per hour an employee is on break. During this time, they cannot handle customers, by definition.
• Employees (Dolgozók): Number of employees.
• Patience (Türelem): The maximum time (in minutes) a customer is willing to wait in line or spend with the IVR. If this time is exceeded, the customer hangs up or leaves the queue.
• Service duration (Kiszolgálás): Average time it takes to serve a customer/Average time to handle a customer in seconds.
• Customer/hr (Ügyfél/ó): Average number of customers handled per hour
• SLA time (SLA idő): The maximum number of seconds a customer is considered to have been successfully handled in a queue.

The calculated results are displayed in the black window on the right:

Calculation of the required staffing

This function of SEC helps you to convert the traffic forecast made by Prophet into a staffing requirement forecast. This calculation is much slower than the calculator mentioned above, as the same calculation will be performed (even multiple times) for each occurrence of traffic.

Both the input and the result are Excel files that can ultimately be imported into Rostar as a staffing curve.

Shift and schedule planning: Rostar

Everyone should do the job that suits their skills and expertise,
when the employer needs it, and in a shift pattern that is comfortable for the employee.

Rostar does this in two main steps:

1. The first is the preparation of a so-called shift plan, which is optimally adapted to the curves showing the distribution of the estimated workload over time, taking into account the available human resources.
2. The second is the „filling in” of the resulting shift plan with the available employees, i.e. the creation of the schedule. The following aspects are taken into account during this process:
   • Compliance with labour regulations
   • Optimal shift plan “coverage”.
   • Optimum work load distribution with respect to the compulsory working hours.
   • Taking into account employee preferences or ensuring an equal morning/afternoon and weekend workload.
   • Managing holidays and other absences won in Shift Wizard .

Rostar tutorial video (hungarian):

Managing absences and training

Holidays and other absences requested and won in Shift Wizard are important input data for the rostering process.

We distinguish between work-related and non-work-related absence types:

• Work-related absence is accounted for in the same way as a shift. The working time is the same as the employee’s base time, e.g. 6 hours, 4 hours for part-time or 8 hours for full-time or, in the case of unplanned sickness, the inherited length of the planned shift. These absences are subject to the same labour rules as shifts.
  The most commonly used work-related absences are annual leave and sick leave.
• Non-work-related leave is for example unpaid holiday.

The type of absence and the colour coding in the interface can be specified by the user.

Staffing plan import from Prophet

If you have made a forecast with Prophet based on a previous factual distribution, you can import the result directly into Rostar as a staffing plan

However, if the forecast is based on traffic data, you will need to convert the traffic data into headcount using the SEC's staffing requirement calculation function.

Rostar will be able to generate the shift plan using the imported staffing curve.

Creation of shift plan

There are two ways of creating a shift plan:

Automatic:
The staffing plan is made by optimally paving the curve, Using the worker resources as “beams”, respecting the labour rules. On demand, the generated automatic shift plan can be edited manually.

Manual:
The editor allows you to create the entire shift plan manually. Shift beams can be created for any time, any length and any skill (based on years of experience). The placement of the beams is supported by numerous UI functions (e.g. drag and drop).

Scheduling

Schedule parameters:

• Deletion factor:
  The algorithm ends when a worker is found for each shift. The probability of this, i.e. of finding exactly as many workers with the exact number of hours and skills as the shift page needs, is very low. For this reason it is necessary to correct the number of shifts at runtime.
  This is done by the deletion factor. As its name implies, if a shift has been attempted more than a threshold value during the attempts, it is taken out of the “playing field”, quasi deleted.
  This threshold obviously depends on the number of shifts to be assigned. By default, the deletion factor is set to = 1, i.e. if we have 600 shifts to assign, any shift will be deleted after 600 attempts of assignment (emp_id pairing). For example, if the deletion factor is changed to 2, then 1200 etc… This method is based on the assumption that staffing assignments are usually under-planned from a staff resource point of view, i.e. there are more shifts than the human resources needed to staff them.
  The value can be a non-integer number between 0 and 1 (e.g. 0.5, 0.75, etc.)
  Setting this variable to a higher value will increase the running time and improve the accuracy of the scheduling, otherwise the result will be faster but less accurate.
  
• Preference acceptance range:
  The time range within which an ever decreasing „bleed through” of points is interpreted.
• Preference Impact Reduction:
  The fraction of points adjacent shift starts receive during the bleed-through. E.g. if it is set to 50%, then adjacent times within the range will only receive the previous half. 100% is the originally selected time. E.g. if someone bids for 8am with 60 points and the acceptance range width is 1.5 hours and the impact reduction is 50%, then for 7am and 9am 30 points are assigned for 6h30 and 9h30 15-15 points. For shifts further away, it will be 0 because the bandwidth is only 1.5 hours.

After the Save period to database operation, the result of the RoStar scheduling is also “visible” to the CSB (Shift Wizard).

In the view menu, you can also select a larger time horizon (monthly) for a better overview:

Labour regulations: Compliance to labour regulations is checked by the Roster application

• The rest time after the shift (x hours) is less than obligatory.
• The number of consecutive working days (x days) is greater than allowed.
• There is no 1 free Sunday a month.
• The longest consecutive weekly rest (x hours) should contain a whole calendar day.
• The longest consecutive weekly rest is less than x hours.
• Average of longest consecutive weekly rest is less than x hours, etc.

Labour regulation is a must for the Algorithm.
Examples for labour regulations that may differ from country to country.
These can be parametrized e.g. the number of consecutive working days allowed is 6 in Hungary and 5 in Austria and Romania.

Evaluation

If you do not find the completed schedule suitable and need to fine-tune it, you can start again from the Creation of shift plan step.

Manual schedule creation for small groups

The RostEdit application is designed for easy and fast monthly scheduling with shortcuts, multiple selections and continuous rule checking for selected administrators or groups.

Possible users of the application

• Individuals who have previously created rosters in Excel or other applications without rule checking.
• Smaller groups (10-50 people) where employees can be left to plan their rosters with minimal external intervention to increase employee satisfaction.

Use cases

The application has two distinct usage modes depending on the rights of the logged in user:

1. Administrator interface
2. Small group scheduler

Administrator interface:

In this mode, a user with administrator rights can select groups or employees and modify them as desired. It is possible to create leave, normal, import, export, fixed shift and trainings. You can also use the leave editing interface and set critical times (designed to show how many workers are on duty at that time).

Administrator interface:

In this mode, a user with administrator rights can select groups or employees and modify them as desired. It is possible to create leave, normal, import, export, fixed shift and trainings. You can also use the leave editing interface and set critical times (to show how many people are working at the set time).

Small group scheduler:

Similar to the previous mode, but with limited options. Group members, group administrators and users with “observer” rights can access it. Only normal shifts can be created and deleted in the shift editor interface. Here, they can keep track of which shifts are still needed on which day, based on a pre-defined shift plan. In the leave editor mode, they can manage leave only during open periods. Here daily and monthly frames help you to fill in.

Continuous connection

Multiple users can change the schedules of the same group at the same time, therefore the application uses a websocket connection to ensure that everyone sees the same schedule status.