Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - hsanchez

Pages: [1]
1
oh well, thanks for the help anyway :)

2
I've done some changes to my app to prevent changing status of offline agents.  Hopefully this fixes things.

It'd still be nice to have QM deal with this in the future though  ;D

3
Well, all calls continue working correctly... the only broken thing is QM now thinks the agent is logged on which messes up 2 things:
- Realtime view: supervisors think there's more ready agents than there really are... bad for me because they think the phone system is broken  :(
- Agent availability reports: bad for agents as it looks like they were sitting around doing nothing for hours

Is there a temporary workaround to make QM "see" the agent logged off again? I tried a bunch of things and I couldn't convince QM that the agent was logged off.  This seems to fix itself by the next morning, but if somebody else is switched around queues while logged off then we're back to square 1.


P.S. I've created 2 new topics under ideas.

4
Improving QueueMetrics / LDAP - Agent mapping
« on: May 25, 2010, 17:49:05 »
We use ldap authentication, but currently agents have 2 logins (Agent/XXXX and ldap).  They use the agent one to monitor their inbound calls, but to run reports and do pretty much everything else they use the ldap one.

My suggestion is to have some agent - ldap mapping, so they can login use their ldap login to monitor their inbound calls.  I know it can easily be done the other way around (get rid of the ldap one), but for business reasons we can't do this.  Something like adding an "agent" field to the users table would be more just fine.  I'm probably the only person on earth who would find this useful, but it seems like it would be trivial to implement  ;D

5
Improving QueueMetrics / Set member priorities
« on: May 25, 2010, 17:47:42 »
We use queue rules to escalate within queues; QM has an AddMember option, I would love to be able to do two things with it:
- Set a priority, my idea is to have some kind of customizable drop down for different penalties (ie. 0 - No Delay, 1 - 1 minute, 2 - 90 Seconds, etc.)
- Have access control to this, only supervisors/managers should be able to move people around.

That way I wouldn't need a separate webapp just to move people around queues :)

6
I've done a bit more detective work...

- Adding AGENTLOGOFF / AGENTCALLBACKLOGOFF entries to the queue log doesn't seem to fix this.  I even had the agent log on and back off (now I'm not 100% sure what's causing this)
- The only stat that's off on reports is Agent Availability, everything else looks ok so far.

7
Realtime Live / Unavailable agents showing up under realtime
« on: May 22, 2010, 02:23:12 »
We've recently switched to dynamic agents and we've noticed that sometimes QM thinks some Unavailable agents are still logged in.  They show up under realtime as ready agents, and running reports counts them like they were logged in the entire time (which is really messing with the center's weekly reports).

I've done some detective work, and it looks like QM assumes an agent is logged on if there's any activity in the queue_log that concerns this agent, for example:

- Agent logs off (AGENTLOGOFF)
- Agent disappears from realtime (as it should)
- Agent is added/removed from a queue (ADDMEMBER/REMOVEMEMBER) while the agent is logged off.  This is what I think is messing with QM.
- Realtime and reports now believe the agent is logged on.

Is there a workaround for this? I would really really really like not to have to go back to static agents just because of this.


On an unrelated note, I'd love to see 2 new features:

1.  QM has an AddMember option, I would love to be able to do two things with it:
- Set a priority, ideally a drop down with customizable names (like 1. Immediate, 2. 1 minute) my users are not the brightest and having a number would confuse them to no end.
- Have access control to this, only supervisors/managers should be able to move people around.

That way I wouldn't need a separate webapp just to move people around queues :D


2.  We use ldap authentication, but currently agents have 2 logins (Agent/XXXX and ldap).  They use the agent one to monitor their inbound calls, but to run reports and do pretty much everything else they use the ldap one.

My suggestion is to have some agent - ldap mapping, so they can login use their ldap login to monitor their inbound calls.  I know it can easily be done the other way around (get rid of the ldap one), but for business reasons we can't do this.  Something like adding an "agent" field to the users table would be more just fine.  I'm probably the only person on earth who would find this useful, but it seems like it would be trivial to implement.

8
Running QueueMetrics / Re: Reporting inconsistencies
« on: September 17, 2009, 01:13:53 »
well, the problem is that this reports different data for the same report, for events in the past (not calls that are still in progress).

For example, a report that runs at 10:00 will show that for 8:00 - 8:15 there were 2 unanswered calls, but running exactly the same report at 11:00 this will show that there was only 1 unanswered call from 8:00 - 8:15... unanswered calls are effectively disappearing from our reports.

I can see data changing for current time periods if a call is still in progress, but I think for older data the numbers shouldn't change.

9
Running QueueMetrics / Reporting inconsistencies
« on: September 15, 2009, 20:17:01 »
We just noticed that QM will show different results for "Unanswered Call Wait Time Per Hour" for a specific time period:

we ran the report at 9:22 and it showed 3 unanswered calls:
8:15, 8:30, 9:15 (1 missed call each)

then the report was run again at 9:26, and it only showed 2:
8:15, 8:30

Needless to say, this is causing a lot of problems :(


Both reports were run exactly the same way (Quick activity reports: today for a specific set of queues).  This was happening with QM 1.4.7, we've upgraded to 1.5.4 and it still shows inconsistencies.

Pages: [1]