Hello,

I was just wondering has anybody already raised and answers were already received from Genesys/Developer why the Forecast Offered is showing as decimal numbers and not as a whole numbers. Interval wise, even if there's minimal volume, it should still results to when and what interval the calls is mostly received.

While nOffered is whole number, as call volume should be, then why in forecasting, Offered is different in format and scattered in most intervals, even showing less than 0.

At least in Multi-Cloud, the result is in whole number as it should be, and FTE requirement is just either .5 or 1, whereas in Pure Cloud, is a lot different.

Is this already part of any enhancement or near future development, I wish it can be looked into, thank you.

Time series forecasting does not produce whole numbers. We produce results with a reasonable amount of precision. '...even showing less than 0' - if you mean a value of 0.something, then that is more than 0 and also valid.

Hello,

I was just wondering has anybody already raised and answers were already received from Genesys/Developer why the Forecast Offered is showing as decimal numbers and not as a whole numbers. Interval wise, even if there's minimal volume, it should still results to when and what interval the calls is mostly received.

While nOffered is whole number, as call volume should be, then why in forecasting, Offered is different in format and scattered in most intervals, even showing less than 0.

At least in Multi-Cloud, the result is in whole number as it should be, and FTE requirement is just either .5 or 1, whereas in Pure Cloud, is a lot different.

Is this already part of any enhancement or near future development, I wish it can be looked into, thank you.

Hi Jay, but how can it be that the system would predict we are going to get 0.2 for example of an interaction when the historical data is never in decimal form. You either have a whole interaction or none. My worry is that the system is generating a forecast of decimal interactions for planning groups with low volume, when it should actually predict when a whole interaction will take place. So rather than 1 interaction spread across two hours between 8am and 10am, it should say we think you will get 1 interaction at say 9am. Then the AHT can be applied to a whole interaction and not a decimal? 

Time series forecasting does not produce whole numbers. We produce results with a reasonable amount of precision. '...even showing less than 0' - if you mean a value of 0.something, then that is more than 0 and also valid.

Hello,

I was just wondering has anybody already raised and answers were already received from Genesys/Developer why the Forecast Offered is showing as decimal numbers and not as a whole numbers. Interval wise, even if there's minimal volume, it should still results to when and what interval the calls is mostly received.

While nOffered is whole number, as call volume should be, then why in forecasting, Offered is different in format and scattered in most intervals, even showing less than 0.

At least in Multi-Cloud, the result is in whole number as it should be, and FTE requirement is just either .5 or 1, whereas in Pure Cloud, is a lot different.

Is this already part of any enhancement or near future development, I wish it can be looked into, thank you.

I will answer with a very simplistic scenario of a simple equal weighted average time series forecast. Obviously we support more than 3-dozen time series forecasting methods.

Goal: utilize a simple average time series forecast method that looks at the past 6w of historical data.

Let's just look at one interval to keep the example brief:

Interval: 0900 to 0915

Historical volumes: 17-Mar: 5; 24-Mar: 7; 31-Mar: 6; 07-Apr: 8; 14-Apr: 7; 21-Apr: 7

Average volume: (5+7+6+8+7+7)/6 = 6.667 (rounded to three-digits of precision just for this example)

Any other time series forecasting has the potential of producing non-whole numbers. The math is mathing.

Hi Jay, but how can it be that the system would predict we are going to get 0.2 for example of an interaction when the historical data is never in decimal form. You either have a whole interaction or none. My worry is that the system is generating a forecast of decimal interactions for planning groups with low volume, when it should actually predict when a whole interaction will take place. So rather than 1 interaction spread across two hours between 8am and 10am, it should say we think you will get 1 interaction at say 9am. Then the AHT can be applied to a whole interaction and not a decimal? 

Time series forecasting does not produce whole numbers. We produce results with a reasonable amount of precision. '...even showing less than 0' - if you mean a value of 0.something, then that is more than 0 and also valid.

Hello,

I was just wondering has anybody already raised and answers were already received from Genesys/Developer why the Forecast Offered is showing as decimal numbers and not as a whole numbers. Interval wise, even if there's minimal volume, it should still results to when and what interval the calls is mostly received.

While nOffered is whole number, as call volume should be, then why in forecasting, Offered is different in format and scattered in most intervals, even showing less than 0.

At least in Multi-Cloud, the result is in whole number as it should be, and FTE requirement is just either .5 or 1, whereas in Pure Cloud, is a lot different.

Is this already part of any enhancement or near future development, I wish it can be looked into, thank you.

Thanks Jay, I understand the logic but should the system after performing its calculations then round up any number to the neareast whole number.

In your example you  cannot have .667 of an interaction in reality, so you it makes sense to round that number up to 7. 

For my issue I have numbers as small as 0.2, 0.3, 0.1, 0.5 spread across a 2 hour interval and the system should then once its calculated determine when a whole interaction will be delivered and then you can build your plan around those whole numbers. In return my Intrday suggests that I will offer 11 for say yesterday which is correct, but the intervals show 0 and when you hover over it, it then shows the 0.2, 0.3 (as its rounded down to zero) etc and any number over 0.5 it rounds up to 1. If i was just looking at the intraday it would show 2 interactions vs. the voerall saying 11 as the other 9 interactions are all decimals below 0.5.

I will answer with a very simplistic scenario of a simple equal weighted average time series forecast. Obviously we support more than 3-dozen time series forecasting methods.

Goal: utilize a simple average time series forecast method that looks at the past 6w of historical data.

Let's just look at one interval to keep the example brief:

Interval: 0900 to 0915

Historical volumes: 17-Mar: 5; 24-Mar: 7; 31-Mar: 6; 07-Apr: 8; 14-Apr: 7; 21-Apr: 7

Average volume: (5+7+6+8+7+7)/6 = 6.667 (rounded to three-digits of precision just for this example)

Any other time series forecasting has the potential of producing non-whole numbers. The math is mathing.

Hi Jay, but how can it be that the system would predict we are going to get 0.2 for example of an interaction when the historical data is never in decimal form. You either have a whole interaction or none. My worry is that the system is generating a forecast of decimal interactions for planning groups with low volume, when it should actually predict when a whole interaction will take place. So rather than 1 interaction spread across two hours between 8am and 10am, it should say we think you will get 1 interaction at say 9am. Then the AHT can be applied to a whole interaction and not a decimal? 

Time series forecasting does not produce whole numbers. We produce results with a reasonable amount of precision. '...even showing less than 0' - if you mean a value of 0.something, then that is more than 0 and also valid.

Hello,

I was just wondering has anybody already raised and answers were already received from Genesys/Developer why the Forecast Offered is showing as decimal numbers and not as a whole numbers. Interval wise, even if there's minimal volume, it should still results to when and what interval the calls is mostly received.

While nOffered is whole number, as call volume should be, then why in forecasting, Offered is different in format and scattered in most intervals, even showing less than 0.

At least in Multi-Cloud, the result is in whole number as it should be, and FTE requirement is just either .5 or 1, whereas in Pure Cloud, is a lot different.

Is this already part of any enhancement or near future development, I wish it can be looked into, thank you.