[asterisk-app-dev] queue.member and queue.caller status

[Matthew Jordan]

On Wed, Dec 17, 2014 at 12:05 PM, Leif Madsen
<lmadsen at thinkingphones.com> wrote:
> On 17 December 2014 at 13:01, Paul Belanger <paul.belanger at polybeacon.com>
> wrote:
>>
>> On Wed, Dec 17, 2014 at 12:54 PM, Jared Smith <jaredsmith at jaredsmith.net>
>> wrote:
>> >
>> > On Wed, Dec 17, 2014 at 12:38 PM, Leif Madsen
>> > <lmadsen at thinkingphones.com>
>> > wrote:
>> >>
>> >> Off hand though I can't think of any other "states" that a caller could
>> >> get into other than waiting, connected, or onhold.
>> >
>> >
>> >
>> > The one that comes to my mind (and one we use frequently at my job) is a
>> > post-call survey.  After the caller is done talking with an agent, they
>> > get
>> > transferred to a post-call survey so they can rate the service they
>> > received.
>> >
>> The way I'd see that is, queue.caller.delete would be called, since
>> they are now moving outside the queue to another application (survey).
>> However, the argument could be made to keep that in a queue too.
>>
>
> I definitely see that as post-queue functionality. What we're getting into
> here is call flow properties, not queue.caller status. The caller could fall
> out of queue and pick up in any application, survey, etc. At this point that
> would be a separate report (or could be a combined report, but the data
> should be generated and combined from other information, not from the queue
> callers status).
>
> Queue caller status is status while in a queue, and nothing else. Either
> side of the queue (prior to entering such as menu selections, etc, or
> post-queue handling such as exit-survey, voicemail etc) reporting should be
> handled separately.
>

Disclaimer: I have not looked at the queue application :-)

After reading through the comments, two points:

(1) I agree with Leif: you'll probably want to find some place where
you can draw a boundary between your queue application and the rest of
the "system", whatever it happens to be. Anything that occurs after
the queue has handed off the caller to something else should be the
domain of the rest of the system. Where you draw that boundary is up
to you, but StasisEnd is always a good starting point for finding out
when something is no longer your concern.

(2) Another consideration to think about is how configurable you want
your reporting to be. If you go down the path of events - which is
what it appears like you're doing - you are deferring the actual queue
reports to another piece of software. That's probably a good thing.
Granularity then becomes an issue: is taking a post-call survey
something that you want your queue to report? Or should it report (a)
the caller has left the queue and (b) the caller has hung up - and
leave the time delta and its implications up to the software that
interprets the events?

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org