Subject: RE: [Simple] Data model - attempt at summary (Groups)

From: "Boyer, David G \(Dave\)" <[email-masked]>
Date: Fri, 22 Oct 2004 11:16:33 -0400

Paul -

[inline]
> 
> 
> 
> Boyer, David G (Dave) wrote:
> 
> [snip]
> > The
> > call center object is unique in that sense and also may have unique
> > contact URIs
> > so that no member's contact information is exposed.  
> Calling this entity
> > a <person>
> > is confusing.  I keep using the word entity to describe this, more
> > generic
> > than person I guess.  If we call it an "entity" - an entity could
> > represent a person, 
> > a group (in the sense of something unique in it's own right), an
> > application, a bot,
> > etc.  Just seems that what we are talking about here is more than a
> > person.
> 
> Applying presence to call centers presents some unique challenges:
> 
> - Attempting to represent every call center agent as part of the
>    presence status would generally not be considered acceptable
>    to the call center management, it would present performance
>    problems, and it wouldn't provide any utility to an outside
>    watcher.
> 
If the group represented every call center agent this would be
a "list style group", something the <person> model doesn't support.
If the call center group was a meta object that, in a sense, summarized
the capabilities of available agents, the watcher would know what
forms of communications were available to it, but not the specifics
of a given presentity.  As an example consider the case where a call
center, at a given point in time, has 50 agents available for
a voice consultation and 30 for IM communications.  Through the merging
operation of the Composition process, the voice services of the agents could
be replaced by a single service URI that provides a single point
of contact for all voice capabilities, similarly a single URI could
be used to provide indirection to the call center's IM capabilities.
A voice and IM pivot could be used to accomplish this.
I realize this wasn't Johnathan's intent when he proposed the merging
step in the data model, but it represents what the call center would 
want in this case.  A single contact URI for voice services which
is resolved to a specific agent when a watcher requests a communication
to the call center.  

> - as you mention, the call center can have special kinds of
>    capabilities that shared equally by all the agents in the
>    call center. These groupings are often called "skill groups".
>    If you are going to expose the call center via presence, you
>    may want to expose each skill group as a separate presentity.

Good idea.
> 
> - The status of a skill group can't be represented accurately
>    by the status attributes currently defined. For instance
>    availability vs idleness is not even close to binary - it is
>    statistical - measured by something like average wait time.
> 
Call centers have very sophisticated agent routing rules that take into
acount many things (customer priority, customer history, specific
product info, etc).  This is basically an availability calculation
that might be able to be performed when Privacy Filtering is done.
Granted it is pretty advanced filtering.

> In spite of these problems, I think it will eventually make 
> sense expose 
> the status of call centers via presence. But I think that can be a 
> follow-on activity.

You are probably right that this needs to be a follow on, but it
is probably good to think through some of the issues at this point.

Dave

_______________________________________________
Simple mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/simple

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 22 Oct 2004 16:02:46 -0400

David - more inline comments.

	Paul

> a "list style group", something the <person> model doesn't support.

This could be represented by treating every call center agent as a tuple 
(service) of the presentity representing the call center or skill group.

But there are limitations to that approach - it doesn't fit the model. 
For instance you can't represent the person attributes of each agent, 
which would include things like language capabilities and possibly 
extensions for subject matter expertise.

I don't think this is a problem because the call center would never want 
to expose addresses of individual agents.

> of a given presentity. 

Yes, that is what I intended.

 > As an example consider the case where a call
> a voice consultation and 30 for IM communications. 
 > Through the merging operation of the Composition process,
 > the voice services of the agents could

You seem to be assuming that agents only do one or the other. In some 
cases that may be true, but it need not be.

In fact the capabilities can be dynamically determined by an algorithm, 
such as:
- Agent 1 can only do voice - max of one call at a time
- Agent 2 can only do IM - max of 3 sessions at a time
- Agent 3 can do one voice session or up to 5 IM sessions,
           but not simultaneous voice and IM
- Agent 4 can do up to one voice plus one IM session, or
           two IM sessions without voice. A session with
           voice may also include IM.

The capability of each agent needs to be recomputed each time something 
changes. This might be by the agent's UA, or by something in the call 
center router. These results can then be rolled up in a manner such as 
you suggest, though there may be more combinations and so more contacts.

But the value of doing this is questionable. In a loaded call center 
agents will not remain available for long, and so the rolled up state 
will typically not show availability long enough to be useful to a 
watcher. You just can't expect to call a call center and get immediately 
routed to an agent. Even when agents are available it is possible that 
you will be sent to an IVR first to gather some information.

It is probably more practical to represent the combinations of 
capabilities that are potentially available, together will an 
availability indicator of some sort that indicates expected wait time.

Related to this is a potentially serious problem in using presence with 
a call center: real callers are entered into a queue, so as time passes 
they are more and more likely to be assigned to an agent. Presence 
watchers on the other hand are simply waiting for a time when they can 
call and not have to wait. They aren't queued, so those who call without 
watching keep going ahead of them. There well may never be a good time 
to call.

To deal with this one might consider doing something special with 
watchers - enqueuing them, and reporting better availability to those at 
the head of the queue. But this presents all sorts of ugly problems, and 
seems like a generally bad idea.

> is resolved to a specific agent when a watcher requests a communication

I don't think this is a merge operation among publishers at all.

I think there must be a special call center router that assigns callers 
to agents. It could be a proxy, but with an algorithm much different 
than a standard proxy.

And it *could* use presence published by the agents to guide this. But 
in that case I don't think the presentities that the agents publish to 
are the same ones that the are available to users to subscribe to. The 
relationships are much too complex for that.

> Granted it is pretty advanced filtering.

See comment above.

> is probably good to think through some of the issues at this point.

As you can probably tell, I have thought about it. But I decided it is 
sufficiently special purpose that I couldn't justify delaying the 
current work to deal with it. (In any case I wouldn't be allowed to get 
away with that.)

I think the current work provides sufficient mechanisms to be adapted to 
call centers, at least enough for awhile. Once the existing work 
stabilizes there will be opportunities to do more.

	Paul

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 31 Oct 2004 23:07:02 -0500

Stepping back a bit, there are really two rather different uses for call 
center presence:

(1) for management purposes, so that some algorithm or manager can add 
resources, send people home, whatever. Here, there are no problems with 
exposing information or interaction with call priority.

(2) for outside callers

Given queueing and other factors a means to prioritize calls, as Paul 
pointed out, I see much less relevance to exposing call center details 
to callers. Aggregate information, such as updates on waiting time, 
would be more useful. That way, I can place a call when my likely queue 
time is lower. Obviously, this has all the problems of 
quality-of-service routing - suddenly, everybody jumps in when the queue 
drops below 10 minutes, leading to oscillations.

Henning