Webcast Support Automation for a Federal Research Institute

“Give users a better way to report their error information, remind them of the common fixes, and reduce the correspondence load on the video support team by empowering viewers to solve their own issues.”

I treated that charter as a business brief rather than a feature request. The success measure was not a prettier form. It was a smaller ratio of support capacity consumed per webcast broadcast, and a shorter clock between the moment a viewer reported a problem and the moment they were watching again.

Before sketching any interface, I ran structured interviews with the video support staff and read through the archived support inbox. Two findings emerged quickly. First, the volume of tickets was not the real problem. Second, the failure mode was consistent: frustrated users almost never provided the browser, operating system, or player error state that the team required to diagnose anything. They wrote a short complaint, hit send, and waited.

The existing help page did tell users what information to include. It did not matter. By the time a viewer landed on the help page, they were already annoyed and scanned for a contact address rather than reading instructions. The result was a predictable cycle of three or four email exchanges per ticket before a single meaningful troubleshooting step could be taken. That cycle was the cost center.

Reframing the charter in those terms changed the solution space entirely. The goal was not to write better instructions. It was to remove the user’s obligation to write anything at all.

The concept was a single support page that did three jobs in sequence. It offered a sample stream that viewers could test their own playback against in real time. It surfaced the most common fixes directly next to the player, so the viewer encountered them before reaching the contact form. And when the viewer did submit a request, the form silently captured the player state, the browser, the operating system, and any JWPlayer error code already in memory, then attached that payload to the ticket.

The viewer had to make one decision: describe what they were seeing. Everything else was inferred. That shifted the burden of data collection from the human at the worst possible moment, when they were frustrated, to the system at the best possible moment, when all the diagnostic information was already present in the page.

I spent time in the JWPlayer API documentation to confirm that the events and error codes I needed were exposed to the page. They were. I could subscribe to the player’s error event, read the code and message, and pipe both into hidden fields on the support form via jQuery. Browser and operating system strings were trivially available through the user agent. Bandwidth and quality level were exposed through the JWPlayer quality and levels APIs. The conceptual solution was technically cheap, which meant the real work was going to be integration, content management, and testing rather than R&D.

Once the wireframe was approved, I carried the approved structure into the live NIEHS content management system. The front end came together quickly because the concept had already been proven in the interactive prototype. The real work lived on the back end, where I extended the existing ColdFusion form handler to accept the new system information payload, store it against the ticket record, and surface it to the video support team in the format they asked for during the review session.

I kept the visual treatment deliberately aligned with the existing NIEHS design system. The support page was not an opportunity to redesign federal web standards. It was an opportunity to change what the page actually did while honoring its institutional look and feel.

Before shipping, I authored a NightwatchJS regression suite against the form. The tests verified that the system information fields were being populated by the JWPlayer API under the supported browsers, that form validation behaved correctly with and without the optional email field, and that submissions routed to the right backend endpoint.

I left that suite in the repository for future developers, not because it was required but because this was a government web property that would outlive my engagement. The tests were an insurance policy that the diagnostic capture would keep working through future CMS upgrades, JWPlayer version bumps, and unrelated feature work.

A solution that cannot be measured cannot be defended. Before launch, I worked with the video support team to wire analytics into the flow and to instrument the Jira workflow so that we could track mean time to resolution for every inbound webcast support ticket. The baseline was unambiguous: prior to the redesign, the average webcast support ticket took 1 hour and 43 minutes to close from first contact to confirmed resolution.

After launch, that same metric dropped to 28 minutes. A 73% reduction in mean time to resolution, attributable not to adding staff or buying software but to eliminating the round trip of asking users for information they could not competently provide. The video support team was no longer playing interrogator. They were receiving pre diagnosed tickets and replying with solutions.

Several months after launch, I ran a long term feedback session with the video support team to verify the gain had stuck. Their assessment was consistent. They were spending less time asking for information and more time closing tickets. The quality of their own day to day had improved, which meant the solution had cleared the highest bar any internal operations change can face: the team that uses it every day preferred the new state to the old one.

Mean time to resolution dropped from 1 hour 43 minutes to 28 minutes, a 73% reduction delivered without adding headcount, without replatforming, and without asking viewers to behave any differently. The video support team reclaimed hours of weekly capacity that had been lost to back and forth correspondence and reallocated it to higher value content production.

The diagnostic capture pattern, the inline troubleshooting, and the in-context test player remain in production today and have endured through multiple CMS refreshes since the original engagement. The regression suite I authored at launch continues to defend the integration against future platform upgrades, ensuring the operational gain compounds rather than decays.