The Ticket Says “The Conference Room Isn’t Working.” Now What?

By Sam Kennedy

Part 1 of our series Troubleshooting with Lena

A support ticket comes in that just says the conference room isn't working. That's it. No device name, no error message, no description of what the user tried, no indication of whether the problem is the display, camera, microphone, conferencing system, control system, or something else entirely.

Anyone who has worked in AV or UC support knows what happens next. The ticket isn't really the beginning of the resolution. It's the beginning of the investigation. Someone now has to figure out what the user actually means, and that's where a seemingly simple support request can consume a surprising amount of time.

Figuring Out What “Not Working” Means

Traditionally, an administrator or help desk technician has to start narrowing things down. Is the display on, and is it on the correct input? Is the conferencing system running? Is the camera responding? Is there audio? Is the network available? Are the devices online? Has the configuration changed? Does something need to be rebooted? Is there a physical problem?

The technician might need to open multiple management platforms, look at device status, and contact the user for more information. If they can't determine the problem remotely, someone may eventually have to go to the room, all because the original information was simply that it's not working.

The problem isn't necessarily that the user submitted a bad ticket. The user isn't an AV technician, and they shouldn't have to be.

What If the Administrator Could Be Just as Vague?

This is one of my favorite ways to demonstrate Lena. I intentionally don't give her much information. I don't tell her to check the power state of a specific display in a specific room and turn it on if it's off. That's how we traditionally think about automation.

Instead, I tell Lena essentially the same thing the user told the help desk: the conference room isn't working. And I let her start investigating.

That's where things get interesting, because Lena has context about the room and the technology inside it. She can begin troubleshooting the environment rather than requiring the administrator to already know what's wrong.

In one of the demonstrations I regularly perform, the problem is intentionally simple: the display is turned off. The user doesn't know that. The help desk person doesn't know that. All they know is the room isn't working. Lena investigates and identifies that the display is off, and just like that, “the room isn't working” becomes “the display is off,” which is a much more useful problem to have.

Finding the Problem Changes Everything

Think about the difference between those two statements. “The conference room isn't working” requires troubleshooting. “The display is turned off” requires an action.

That's an important distinction. The first requires someone to determine where to begin. The second gives the administrator something specific they can do, and if the issue can be addressed remotely, they may be able to resolve it without anyone ever going to the room.

In our example, once Lena identifies that the display is off, the administrator can have her turn it back on. Problem identified, action taken. No one needed to know the correct device command, dig through a manufacturer's interface, or walk into the room. Most importantly, the administrator didn't need to know what was wrong before asking for help.

Troubleshooting Should Be a Conversation

This is where natural language becomes much more than a nicer user interface.

Traditionally, troubleshooting tools expect the operator to understand the system. You need to know which dashboard to open, which device to inspect, which status to check, which command to run, which data matters. In other words, the software gives you tools, and you supply the expertise.

Lena starts changing that relationship. The administrator can describe the problem the way a person naturally would: the classroom isn't working, there's no video in this conference room, something is wrong with the display. Then Lena can help investigate.

That turns troubleshooting into something much closer to working alongside another member of the team. You describe what you know, Lena helps determine what you don't, and together you work toward the resolution.

Now Think About Who Can Handle the Ticket

This has implications beyond making an AV administrator faster. It can change who is capable of handling the issue in the first place.

AV and UC environments contain a tremendous amount of specialized knowledge. An experienced AV professional knows how the devices interact, knows where to look, recognizes common failure modes, and understands the quirks of different manufacturers. They've seen the same problems enough times to know where troubleshooting should begin. A generalized help desk technician may not have that experience, so historically a basic AV ticket can end up escalating to a specialist simply because the person who received it doesn't know where to start.

But what if Lena can provide some of that context? Now the generalized IT person doesn't necessarily need to already know that they should check the display power state first. They can ask Lena to troubleshoot the room, she can identify that the display is off, and the IT person can work with her to resolve it. The AV expert never needed to get involved.

That's not replacing AV expertise. It's allowing AV expertise to scale.

Save the Experts for Expert Problems

This matters because not every AV problem is difficult. Some are. Some require years of experience, and an understanding of complex signal flows, control systems, networks, device interactions, and physical environments. Those are exactly the problems where you want an experienced AV professional involved.

But a display that's turned off, a device that needs to be rebooted, or a configuration that changed shouldn't necessarily consume the same scarce expertise. If Lena can help frontline IT teams resolve more of the basic problems, AV specialists can spend their time on the problems that actually require specialization.

Instead of every AV issue flowing toward the AV team, Lena can help create another layer of support: general IT working with Lena, and an AV specialist only when it's genuinely needed. That's a much more scalable model.

And Sometimes Lena Can't Fix It

Of course, not every problem can be resolved through software. Maybe the display isn't simply off. Maybe it isn't responding at all. Maybe a cable has been disconnected, or a device has physically failed. Someone may still need to go into the room.

But even in that situation, Lena can provide value, because there's a huge difference between sending a technician into a room with nothing more than “the room isn't working” and sending them in already knowing that the issue looks physical and exactly where to focus their attention.

The technician still has to go, but they aren't starting from zero. The troubleshooting process has already begun.

We tend to think there are only two outcomes: AI fixed it, or AI couldn't fix it. There's an important middle ground. AI helped the human fix it faster.

Autonomy Doesn't Have to Mean Removing the Human

This is why I like thinking about Lena as a teammate. Sometimes she can identify and resolve the problem. Sometimes she can identify the problem and ask the administrator before taking action. Sometimes she can narrow the problem down and tell a technician where to look. And sometimes a complex issue still needs an AV expert.

The objective isn't maximum autonomy at all costs. It's using the right combination of software and human expertise to resolve the problem efficiently. Sometimes the best outcome is that Lena handled it entirely. Sometimes it's that Lena found it and a human handled it. Both can create significant value.

From a Mystery to a Resolution

Let's go back to the original ticket: the conference room isn't working. Traditionally, that sentence creates work. Someone has to turn an ambiguous user complaint into a technical diagnosis before they can even begin resolving it.

With AI-assisted troubleshooting, that workflow can start changing. The user can be vague. The help desk can be vague. Because the system helping them doesn't necessarily require someone to translate the problem into a perfectly constructed technical command first.

That's the part I find exciting. We're moving from tools that require operators to know what to check toward systems that can help operators figure out what needs checking. And once that happens, troubleshooting AV and UC environments becomes accessible to a much larger group of people.

The ticket may still say the conference room isn't working. But that doesn't mean the administrator has to start from scratch. They can simply ask Lena, and start from there.

Next: If This, Then That Isn’t AI
For years, we've automated AV using predefined rules: if this happens, do that. That works extremely well when we already know the problem. But what happens when all we know is that the room isn't working? In Part 2, we'll look at why that question is where the difference between automation and AI orchestration starts to matter.

To learn more or to schedule a demo:
Visit: www.netspeek.ai
Contact: lena@netspeek.com
Demo: Book a live walkthrough