J
Jacob
Hello All,
I need to report on reply response times in a Call Centre scenario and
wanted to know people's thoughts on the best way to approach this.
Some background:
The call centre mail is hosted on Exchange 2000 SP3. The call centre
staff all connect to common (shared) mailboxes using Outlook 2000
(v9.0.0.3821) in CW mode.
I need to be able to measure and report on:
a) average response time across the whole mailbox (defined as time
elapsed between message arrival and a reply to that message,
aggregated).
b) individual average response times for each call centre operator
(defined as time elapsed between message arrival and a replay to that
message, but only for replies sent by a given operator).
I can think of 2 basic approaches to this. First, create a custom
Outlook Reply form and install it on the mailbox in question and make
it the default Reply form. This form would be a slightly modified
version of the standard reply form, but would have extra VBScript code
hooked up to its Reply button which when clicked would poke the
received time of the current message, the current (reply) time and the
username of the current Windows user into a DB via ADO, and then Send
the reply message as normal. This would get the essential 'reply
response time' metric into a nicely queryable form for reporting.
Alternatively, instead of poking those values into a DB perhaps I
could write them into custom fields on the message item itself for
later reporting - not sure if that would be wise though.
The second approach would be to avoid Outlook forms altogether and run
a script (CDOEX or WebDAV) against the Exchange mailbox itself and try
to calculate response times. This sounds harder to me though as how
exactly do I determine what is a reply to a message? I'm pretty sure I
could use some of the message properties (like 'in-reply-to' or
'thread-index' & 'thread-topic') to locate replies and match them to
their corresponding original to determine the response times, but that
sounds like a very slow, deep search process.
A third way may be to try a WSS event sink on the mailbox, but that
would have the same difficulties as the second method above methinks.
What do you guys think is the best way to approach this? The first
method (Outlook form) seems most likely to address both of my
requirements (the second and third would only sort out (a))... but it
also seems clunkier. All of the customers who the call centre
correspond with are external to the Exchange environment and will have
a wide range of mail clients. If an Outlook form was used I wouldn't
want it being sent out with the replies as a crappy winmail.dat
attachment - the only purpose of the custom form would be to allow the
ADO DB connection at the time of drafting and sending the reply. Oh,
and the call centre operators all use autosignatures if that's
significant...
Is what I want possible, or am I asking for pain?
Thanks for your thoughts and time!
Regards,
Jacob
I need to report on reply response times in a Call Centre scenario and
wanted to know people's thoughts on the best way to approach this.
Some background:
The call centre mail is hosted on Exchange 2000 SP3. The call centre
staff all connect to common (shared) mailboxes using Outlook 2000
(v9.0.0.3821) in CW mode.
I need to be able to measure and report on:
a) average response time across the whole mailbox (defined as time
elapsed between message arrival and a reply to that message,
aggregated).
b) individual average response times for each call centre operator
(defined as time elapsed between message arrival and a replay to that
message, but only for replies sent by a given operator).
I can think of 2 basic approaches to this. First, create a custom
Outlook Reply form and install it on the mailbox in question and make
it the default Reply form. This form would be a slightly modified
version of the standard reply form, but would have extra VBScript code
hooked up to its Reply button which when clicked would poke the
received time of the current message, the current (reply) time and the
username of the current Windows user into a DB via ADO, and then Send
the reply message as normal. This would get the essential 'reply
response time' metric into a nicely queryable form for reporting.
Alternatively, instead of poking those values into a DB perhaps I
could write them into custom fields on the message item itself for
later reporting - not sure if that would be wise though.
The second approach would be to avoid Outlook forms altogether and run
a script (CDOEX or WebDAV) against the Exchange mailbox itself and try
to calculate response times. This sounds harder to me though as how
exactly do I determine what is a reply to a message? I'm pretty sure I
could use some of the message properties (like 'in-reply-to' or
'thread-index' & 'thread-topic') to locate replies and match them to
their corresponding original to determine the response times, but that
sounds like a very slow, deep search process.
A third way may be to try a WSS event sink on the mailbox, but that
would have the same difficulties as the second method above methinks.
What do you guys think is the best way to approach this? The first
method (Outlook form) seems most likely to address both of my
requirements (the second and third would only sort out (a))... but it
also seems clunkier. All of the customers who the call centre
correspond with are external to the Exchange environment and will have
a wide range of mail clients. If an Outlook form was used I wouldn't
want it being sent out with the replies as a crappy winmail.dat
attachment - the only purpose of the custom form would be to allow the
ADO DB connection at the time of drafting and sending the reply. Oh,
and the call centre operators all use autosignatures if that's
significant...
Is what I want possible, or am I asking for pain?
Thanks for your thoughts and time!
Regards,
Jacob