Turning a browser tab into a contact centre desktop application

The situation

The project folder contains no explicit problem statement. What it documents consistently are the problems it was built against: missed task notifications, unreliable audio device selection, headset buttons that did nothing, and sessions dying silently after network interruptions or token expiry. Whole documents are devoted to individual faults of this kind.

That agents previously used the contact centre interface in a plain browser is the obvious reading — but it is not stated in the project, and remains an inference.

The approach

At the core is an Electron application that loads the existing web interface in an embedded window and adds native capabilities around it. Three layers cooperate:

• An injected monitoring script runs inside the page, hooks into the telephony SDKs, and reports every event that matters — reservation created, accepted, rejected, activity changes, disconnects, token expiry — plus a heartbeat.
• A bridge forwards those events as the only sanctioned channel between web page and desktop process.
• The main process responds with native behaviour: an always-on-top notification window with accept and reject, per-channel ringtones, taskbar flashing, a detachable control widget for mute, hold and hang-up, a wrap-up timer, and headset call control.

Around that: multi-layer connection monitoring with automatic reload or re-login, audio device enumeration with stored preferences, session tracking, and daily rotating log files. Plus the operational side: automatic updates, a remote log pull — the application polls a queue and uploads a diagnostics archive on request — and a rollout script that migrates per-user installs to a per-machine install.

Where it could have gone the other way

Self-healing is deliberately subordinated to call safety.

The application heals aggressively: heartbeats, staleness detection, forced reloads, re-login. The obvious design lets that fire whenever the connection looks unhealthy.

Instead the code explicitly refuses to reconnect while an active task or an active call is in progress: a detected stale connection is logged and skipped if either is present.

The reasoning is simple and correct: a connection that looks dropped is annoying. An automation that hangs up a live customer call is unacceptable.

That this balance was hard-won rather than accidental shows in a single changelog: five successive fixes to over-eager recovery logic — reload loops, false token-expiry detection. The other side of the same trade-off.

The result

Around 30 hand-written source files, roughly 10,100 lines, six connected systems. The version reached 1.0.58 — dozens of released builds rather than a single delivery. Operational logs run well past the last commit, so the application was in active use long after development ended.

Limits stated openly: no automated tests — quality assurance is manual and log-driven, visible in a folder of sample logs and detailed per-fault documents. Windows in practice, even though other targets exist in the build configuration: sound playback, volume control, installer and rollout are all Windows-specific. Single tenant — the sign-in URL and the status mapping are hard-wired. And the binaries are unsigned, which the documentation records along with the consequence: warnings on launch.

One structural dependency remains and is inherent to the approach: the injected script hooks undocumented objects of the web interface. A platform update can break the integration.