The WRQ call tracking system was built for use by the company's tech support team.  The foundation was a Scopus call tracking system, customized to the point of unrecognizability.  I led the design team, coded the user interface, wrote the database procedures and integrated the real-time CTI code that controlled the phone switch.  This kept me out of mischief for quite a while.

Click on an image below to see a full-size version in a new window.

The Take a Call screen was what support engineers used to take notes, keep status and otherwise track a support issue.  The screen was a sort of master control panel, and could be used for research as well as data entry.  The application allowed multiple instances of this screen to be visible; this allowed engineers to hunt for answers in one window and take notes in another.

The Open Call List screen showed callers waiting in the phone queue.  WRQ was unique in wanting human dispatchers to answer the phone and take the first notes down from the customer.  Customers waited in the queue after speaking with the dispatcher.  You'll notice a Refresh button; the screen wasn't auto-refreshed due to database performance concerns under load.  This wasn't such a bad thing; pressing Refresh repeatedly turned out to be a good way to get rid of nervous energy, sort of like worry beads.

The QMail screen was what agents used to retrieve voicemail messages left in queues.  This might happen if a customer phoned during off hours, or abandoned a call in a phone queue.  The customer's recorded message could be retained indefinitely, and was associated with the support incident and retrievable from the Take a Call screen. 

In the free-thinking place that was WRQ tech support, engineers could self-assign to phone support queues using the Queue Membership screen.  Shift managers would ensure there was coverage, but there was a good deal of free will involved.
 
Pretty busy toolbar, isn't it?  There was a joke going around that I was paid piecework, by the button.  The support engineers loved it though.

The Queue Scheduling screen was where the opening and closing times of the queues were set up.  This helped configure after-hours messages in the phone system.  The queues opened on schedule even if no agents were ready; callers would leave a message in the QMail system and their question would go to the top of the queue.

The Soft Phone was really fun to build.  You could perform all the operations of a multi-line phone from this screen.  The agent's real telephone would light up, dial and so on to match what the Soft Phone did.
 
The first usability test of the Soft Phone was a revelation.  I started out making it application-modal, without really thinking about it.  I knew this was a bad choice within the first minute of the first usability test.  What stuck with me though was how I really didn't know this until that first test.  I've been a believer in early prototype testing ever since.