To Laurel, and Russell, and Bob, and tweeters everywhere:

The thread that's starting about the BirdBox is a pertinent one and Russell
made some very fine observations about how the BirdBox works, and why it is
set up the way it is.

That does not mean that this service could not be improved. I have been
administering it since it went online (April 1, 1995), which is plenty of
time to learn what works well and what works less well. Some of us are
beginning to talk about changes, and I want to make a proposal to WOS some
time soon for some needed upgrades. It would be really useful to have
input from frequent as well as from not-so-frequent users. If you all
think this is a subject of appropriately general interest, then an online
discussion would be welcome. Comments sent to me offline are invited as
well.

To lead off, here are some of the ideas that have been circulating so far:

1) A password-protected system is really necessary, for the reasons Russell
gives. But there is no reason we could not move the password gate to the
inbox only, so you could not *leave* a message if you did not get the
password right, but could *listen* to the messages without a password
check. This would require rewriting the present program, but could be done
with the existing software.

2) It would also be possible to have the system record incoming messages
even if the caller messed up the password. However, these messages would
be sent to the system operator's private mailbox, and would only be posted
to the public mailbox after screening to make sure they were legitimate.
This improvement may require a newer and more flexible software
application than the DOS-based 1980s one we are using.

3) You may have noticed that the number of "dud" calls -- cases where
somebody connects with the inbox but hangs up without leaving a message --
are increasing. This does not seem to be deliberate, but rather happens
due to more and more people wanting to use the BirdBox for the first time
and getting confused. It *is* confusing, even if you are not especially
technologically challenged. It would be possible to reconfigure the prompt
tree to make the process of leaving a message more intuitive, and simpler.
Here again, a software upgrade would be helpful to accomplish this.

4) The BirdBox only holds twelve messages which is almost a week's worth in
typical traffic periods. That is adequate except for four or five usage
spikes in a year, when as many as 12-15 messages may be left in a single
day. These spikes occur at unpredictable times. Although it is possible
to set the system to a default of saving 15 or even more messages, up to
the limits of the present system's rather minimal memory capacity, doing so
would mean that it would take more time for a caller to listen to them all,
thus tying up the line for longer periods per call, on average. Voicemail
software with more modern features than the one in which the current
program is written could let us save (for example) six days' worth of
messages with a minimum of 12, which might amount to seven or more days'
worth in slow-traffic periods, or 25 or more messages in a rare six-day
period when traffic was heavy.

5) Every blank message that gets left knocks the oldest one off the edge
forever. Newer software packages have the capability of recognizing such
"dud" messages and just not posting them. Better software would also
allow us to save offline in memory more than the alloted number of messages
that are automatically accessible in the mailbox for callers to listen to.
That way any junk messages, or "dud" messages, that got by the password and
the automatic "dud" screening feature could be manually deleted by the
system operator, and the most recently saved deleted message could be put
back to replace it. Saving more messages would also be an important
fail-safe feature. For example, we lost all record of the BirdBox messages
for two weeks in late December '95 and early January '96 when the person
who was doing the transcriptions had a major computer crash. If the
original recordings had still been saved in the BirdBox memory, they could
have been retranscribed. Adding this safeguard would require not only
better software, but also a memory upgrade for the BirdBox hardware.

6) Call volume is increasing. During busy times (evenings and weekends)
the system is functioning at 50%-80% capacity, which is the saturation
point. Result: repeated busy signals and long waits for users. Solution:
add a second phone line. Requirements: new-line installation charge,
increased monthly telcom line fee, adding a second voicemail card, more
sophisticated software, more RAM.

Anyway, these are a few of the options that might be considered. Comments
and suggestions invited, whether you are a BirdBox junkie or just an
occasional user.

And, excuse the length. Thanks!


Hal Opperman
P. O. Box 286
Medina, Washington 98039 USA
halop at accessone.com
phone 206-635-0503