Why hold time in app_queue is calculated in this way?

I’ve seeing in app_queue.c that hold time is calculated in this way:

0.25 * latest actual hold time + 0.75 * previous average, except the whole hold time is used for the first call.*

	if ((qe->parent->callscompleted + qe->parent->callsabandoned) == 0) {
		qe->parent->holdtime = newholdtime;
	} else {
		oldvalue = qe->parent->holdtime;
		qe->parent->holdtime = (((oldvalue << 2) - oldvalue) + newholdtime) >> 2;

The question is: Why hold time is calculated in this way, and not just making the simple average like (last actual holdtime + previous average) / 2 ?

That’s not a simple average; it’s still an exponential average but with a different decay factor.

I imagine that the decay factor was chosen as a compromise between not overreacting to outlyers, whilst still being responsive to changes in traffic during the course of the day.

The “then” part of if is there to give a fast start after a reset.

The use of shifts is a hint as how to do the calculations more efficiently, and avoid division, but I believe the overall effect is (3*previous + latest)/4.

In any case, this has been in the code so long that the original designer has probably retired or otherwise moved on, so the original design rationale is probably lost in history.

1 Like

So, in short, if I understand: this is an archaic way to calculate hold time. Not necessarly the right way, designated by some global or local standard callcenter indicator, or something like that, right?

Your proposal was worse, because it is too sensitive to short term fluctuations. They are both simple IIR filters, whereas your reference to average suggests an FIR filter.

I’m not aware of any standard for computing hold time estimate in real time, so don’t think one can say it is archaic. I’d guess it was considered pragmatic, at the time. However, as I already said, I think it very unlikely that the person who could explain the original design rationale is still around.

I do tend to believe that one could do better, by accounting for queue lengths and also adjusting as agents come and go, but any simple algorithm is always vulnerable to past performance not predicting future results.

Asterisk has provisions for people to jump the queue, which means that people can be pushed back after any initial estimate is given.

I can only remember the algorithm coming up once before as an issue, and that is only in well over a decade. I think that was more about not understanding it, rather than suggesting anything better.

The calculation is done to give a prediction to people entering the queue, not to give a performance metric for management. The latter is better handled by offline analysis based on raw times for queue entry, acceptance by agent, and completion by agent. I’d expect one to compute averages by day of week and hour of day, and probably standard deviations, when doing offline analysis.

1 Like

Thanks @david551

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.