Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Service Observe

Status
Not open for further replies.

AMDGB

Technical User
Sep 17, 2002
8
GB
Please help

Is there any way that service observe can be set up for a line manager to have access to their team only.

For example: we have 10 teams all sharing the same COR hierarchy. Each team manager needs to be able to listen to their team but not to any of the other teams?

I have looked a the COR structure and beleive I cannot however I thought I'd double check.
 
Go to the specified COR and see if you have a fourth page where you can set up service observing restrictions between COR.

This can depend on your software version.

Plan your work............Work your plan

[afro]

 
Have a look at page 4 (on R8 system anyway) of the COR form, I think you'll need a seperate COR higherarchy per manager, with page 4 altered to allow the manager's COR permision to monitor their teams hierarchy of CORs.
 
I setup different access codes for each manager, then had them dial a VDN which directed them to a vector routing table, depending on the serurity code entered. I put the agent id's in separate vector routing tables (vrt) to segment wo can observe whom. If the manager had the right security code, and the agent was in the specific table, then service observing was allowed. The vrt entries had the FAC and agent id for each entry. Managers had to enter the FAC and agent id to get a match.
 
Nice one, wdurkin! Lots of work, nut nice idea!

Kind Regards,
Maarten Copini


-Please let fellow members know if their post was of any help-
 
I did exactly the same thing using VRT's on a call center. It also worked like a charm. I actually set up 3 or 4 vector routing tables with different 7 digit numbers as the first entries in those tables. These are security codes. The caller is routed to the correct table depending on which security code they enter. Different groups have different codes.

The next entries in the VRT's are three Question marks (followed by the observed agents). These are widcards for the 2 service observing option feature codes. We always use feature codes that start with a * or # in our switches, but they will not work with this method, you have to use totally numeric feature codes for these two features. They can be of any length so you wouldl only need 2 ?'s for 2 digit codes. Those are followed by the agents station or login ID. Service Observe is assigned a DID, which is a VDN that sends the callers into a Vector. This Vector looks like this:


step 1: collect 7 digits after announcement xxxx (enter security code)
step 2: goto vector 50 if digits in table 1 (route to step correct table according to match on security code)
step 3: goto vector 51 if digits in table 2
step 4: goto vector 52 if digits in table 3
step 5: collect 1 digit after announcment xxxx (no match do you want to try again, press 1)
step 6: goto step 1 if digit = 1
step 7: disconnect after announcement none
step 8: stop


Example Vector 50

step 1:wait time 0 secs hearing ringback
step 2:collect 7 digits after announcement XXXX (enter access code followed by agent id)
step 3:goto step 8 if digits in table 1 (checking for access code + agentid)
step 4: collect 1 digit after announcment XXXX (no match try again?)
step 5: goto step 2 if digits = 1
step 6: disconnect after announcment XXXX
step 7: stop
step 8: route to digits with coverage n
step 9: goto step 1 if unconditionally
step 10: stop

The VRT's look like this:

VRT 1 service observing table 1 sort n (very important that this be set to n)

1: 1234567 (security code for this table)
2: ???6001 (agent ID's that can be service observed)
3: ???6002
4: ???6003
5: etc

This quite secure. A caller has to know the security code, the service observing feature codes plus the agent id in order to get anywhere. Only problem with all of this is that there are a limited number of VRT's and this can use up a lot of them.

Paul Beddows
Avaya System Design
TELUS (telephone employess living under stress)
Vancouver, Canada
paul.beddows@telus.com
 
Bellows

- good point about the FAC for service observing. We had to change our FAC for this, as it had to be all numeric. I changed it to 196 for 'listen' only and 197 for 'barge in'. In my vrt entry, I used 19? plus the agent id, for each entry. This enabled me to use the same vrt table for both kinds of service observing. We decided not to use barge in for now, but the programming is set up for both.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top