Author Topic: Switching between pause codes has a bug - One MUST un-pause before switching!  (Read 5218 times)

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
Hello,

This is a situation that I think applies to every call center.

1- Employee goes on PAUSE CODE - Break (paid time) for 5 minutes
2- Employee then decides to go on PAUSE CODE - Lunch (unpaid time) - for 30 minutes

So he/she clicks the relative pause codes in the same order as above without using the UNPAUSE button and guess what happens? the system only logs BREAK for 35 minute of paid time. This is an employer rip off or it could be employee rip off :-(

Can this be fixed on an emergency basis since this is really bad and was brought to my attention today.

P.S. Employee should be allowed to switch from PAUSE code to PAUSE code without unpausing because if they unpause they might start receiving calls and there are tons of other reasons why one might want to switch from code to code without unpausing.

Regards,

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
This is by design, so you can change the pause code if you enter it incorrectly.
What you get is that the agent went on lunch for 35 minutes, so when you review such data, you tell them they are over their allotted time.

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
Hello,

I don't think you understood the situation properly. I invite you to do the following on your test system.

1- Login to Queue
2- Press PAUSE and go on a PAID pause code
3- 1 minute after step #2 above, press another PAUSE code - PAID one - without unpausing in between.
4- 1 minute after that, unpause and go ahead check the sessions.

You will only see that the first PAUSE code is recorded and the second pause code is not recorded. That is my issue. This is not about how long an employee takes break or lunch. It's about reporting NOT LOGGING pause code.

Regards,

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
So you would like it to be changeable or not?

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
Of course changeable.

Right now an employee can ONLY go on PAUSE CODE and then he MUST unpause before going on another pause code. If he goes on PAUSE CODE and then changes to another PAUSE code without using UNPAUSE in between the second PAUSE CODE does not get logged as a session.

THIS IS A BUG !!!

I am not sure what other way to explain this. Unless you try what I tried to convey multiple times probably you won't notice the bug. This is a reporting issue.

Regards,

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
From our tests, the code actually gets changed, as expected.

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
From e-mails that I got from Lenz he says that the code changes to the second pause code and doesn't record the first pause code because you want to give a chance to user to fix the wrong pause code. This is wrong behaviour. Why would we want the user to fix their timing?

You have probably not tested this properly.

The system only logs the 2nd pause code if one goes on two pause codes right after each.

I would be interested to know what the overall team consensus is because in e-mails I am getting different answers. You are saying it's working, Lenz tells me it's not working but it's set to work allow agent to fix it's mistake.

Regards

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics
The one that Lenz refers to is the expected behavior, so I am not seeing a bug here.

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
Expected behavior it may be because you coded it but the ration behind it does not suit a real-life situation.

Which employer gives the employee the chance to fix their own billable or non-billable pause codes?

Your team reasoning is that if a user makes a mistake on a pause then they should be able to change it quickly to reflect the right one.

Really no employee expects to be able to fix their pause code mistake. That is what a supervisor is for and that is why it should be brought to the attention of the supervisor. That is how all punch clocks work as well.

I hope this doesn't come as rude to you - as I am trying to help improve QM - but really your ration is not right and there is no use to what you call "expected behavior"/feature.

Regards,

bhenry

  • Jr. Member
  • **
  • Posts: 69
  • Karma: 1
    • View Profile
    • Email
I ran into this situation as well.  What I did to fix it is to unpause the agent first before processing the pause.  I added this to extensions_queuemetrics.conf to replace the old pause section.  It will cause an unpause then pause when the agent presses the pause button.

exten => 22,1,Answer
exten => 22,2,NoOp( "QM: Pausing Agent/${AGENTCODE} with pause reason '${PAUSEREASON}' made by '${QM_LOGIN}' " )
exten => 22,3,UnpauseQueueMember(,Local/${AGENTCODE}@from-queue/n)
exten => 22,4,PauseQueueMember(,Local/${AGENTCODE}@from-queue/n)
exten => 22,5,System( echo "${EPOCH}|${UNIQUEID}|NONE|Agent/${AGENTCODE}|PAUSEREASON|${PAUSEREASON}" >> /var/log/asterisk/queue_log )
exten => 22,6,Hangup

This way the agent does not have to do any manual unpausing between pauses.  Also I have never had a situation where the split second unpause triggered an improper call to be received during a break.

You may need to adjust slightly for your needs.

-Brendan

QueueMetrics

  • Loway
  • Hero Member
  • *
  • Posts: 2999
  • Karma: 39
    • View Profile
    • QueueMetrics

torontob

  • Full Member
  • ***
  • Posts: 155
  • Karma: 0
    • View Profile
Brendan,

Thanks for that. I really appreciate it when someone comes up with a quick solution.

To be honest, I am not impressed with QM official responses either in this thread or in my e-mail requests (where I was asked for $400 to make this irrational behavior a feature - as you can read in this post, only after 4 posts someone gets what I am saying.

I am hoping that QM listens to it's community users for new features or feedbacks rather than going it's own way - as customers will not come back if this keeps going on.

But mucho thanks to Brendan again.