A toolkit for a contact center that had none.
A high-volume government contact center on Cisco UCCE: about 20 Windows servers plus CUCM, Finesse, CUIC and VVB. Checking health meant signing in to each server. One problem call meant hours of log hunting. The IVR was a black box, and weekly schedules lived in spreadsheets.
- Platform
- Cisco UCCE 15 · ~20 Windows servers · CUCM, Finesse, CUIC, VVB
- My role
- Design, build and rollout
- Output
- 6 web tools on one shared agent
- Built with
- PowerShell · C# · IIS · SQL · Cisco APIs
The rules I had to build within.
No software installs
Only what the security team allowed: PowerShell, static HTML and JavaScript, ASP.NET handlers, and one service compiled from source on site.
No stored Windows passwords
Agents run as SYSTEM. The one appliance account is encrypted with DPAPI and used lockout-safe: one try, then pause.
No listening ports
Servers push their data to shares. The central side never signs in to a server and never calls into one.
How it fits together.
Health Check — every server on one page.
An agent on each server reports every minute; the Cisco appliances are read centrally over their APIs. One page shows Windows services, CPU, memory, disks, event-log errors, clock drift, pending reboots, router state and which side is active, with alarms and 30 days of history.
Before, checking the platform meant a remote session on each of twenty-odd servers, and nobody could say what the state had been at 6 PM yesterday.
Call Log Collector — one case, every log.
Pick servers, log types and a time window, and get one zip per case with a merged event timeline. Find a call by number, call key or GUID, then trace it through router, peripheral gateway, CVP and VXML logs, following the extension and call IDs it discovers along the way. Appliance logs come through the Cisco log-collection API.
Before, investigating one escalated call meant visiting every server by hand and reading four log formats side by side.
- 10:02:11CVP-A · call start · IVR App A
- 10:03:40ROUTER · label returned → precision queue
- 10:03:41PG-1A · OPC offered to extension 4021
- 10:03:42PG-1A · JTAPI ringing
- 10:05:02PG-1A · JTAPI device out of service
Likely cause: the agent's phone lost its registration mid-call.
Customer Journey — what callers actually do.
A flow map of each IVR application, built automatically from the application's own call flow, so new branches appear without anyone uploading anything. It shows how many callers pass each step, where they hang up, no-input and no-match rates, transfers and durations, joined with the historical call records. Caller numbers are masked and salted.
The business could finally see the IVR as callers experience it, and decide menu changes from evidence rather than opinion.
Then I rebuilt the agents.
The first agents were PowerShell tasks starting every minute. On memory-starved servers they went quiet for hours and log requests waited minutes. I measured it, then replaced them with one small Windows service per server, compiled on site from source, that does health, log collection and IVR reading, and continues from the old agents' state.
Figures to be replaced with measured production results.