Sometimes the biggest improvement isn’t optimizing the process. It’s eliminating the thing everyone assumed was permanent.

In late 1996, a temp agency placed me at CampusMCI, a college-focused ISP division of MCI Communications, as a call center support operator. I’d spent two years translating print to web for a gaming magazine I co-founded.

On my first day, I learned that each shift started with a photocopied hot list of known problems. I sat down at a VT terminal and started taking calls.

On my first break, I asked the floor supervisor, “Have you considered doing this paperless? You’d save paper and have something you can edit in real time.” She said they hadn’t. I asked if I could demonstrate something on my workstation.

She said: “Sure, go ahead.”

And that’s how the daily floor notices went digital.

It proved popular enough that a spare PC was allocated to host the pages. I started building call scripts for Tier-1 issues: winsock.dll failures, PPP authentication, modem negotiation. Step-by-step visual guides with branching logic that showed the CSR exactly what the caller was seeing… on an Intranet webpage in 1996.

Before the guides, certain calls could only go to a few people on the floor who had the settings panels memorized. After the guides, anyone could take them.

Requests for improvements started coming in. I moved the tools onto OS/2 Warp, using REXX, Java applets, and IBM’s native web server. That stack was deliberate: the applications could migrate to AIX, giving enterprise IT a straightforward code handoff if they wanted to formally adopt the system. I soon had a team assisting me in my work.

I added a shared support mailbox so CSRs could answer emails without stepping on each other. Account lookup tools. Then a call disposition form where CSRs clicked a few buttons after each call, feeding a Java applet that gave floor management real-time visibility.

Suddenly three calls about a modem not answering in Georgia weren’t just three calls. Together, they signaled that someone needed to contact the onsite team before the problem spread.

Those efficiencies helped protect our location through successive call center closures. At least three times while I was there, equipment from closed locations was consolidated into ours. That continued after I left.

I went from temp to the end of the Tier-3 escalation chain leading a team of five in about eighteen months, and it started with a question on my first coffee break.

The instinct in any operation is to optimize what’s already there. Better photocopies. Faster distribution. Neater binders. But sometimes the thing you’re optimizing around is the thing that needs to go. And the person who sees it might be the one who just walked in the door, because they haven’t learned to accept it yet.

Listening is one of the more critical diagnostic skills you can practice.

At one company I worked with, the support team kept getting tickets for their fax modem banks… busy signals, dropped connections, intermittent failures across the document ingestion system. The issue could last for hours if not longer at times.

And every time it happened, the team would review the hardware. They would check the intake software that controlled the modems, restarting the software controllers. They would pull logs and look for errors. Even testing equipment by running extensive self-checks. They usually found nothing wrong.

Then the problem would go away on its own, and apparently this had been going on for months.

One day it happened while I was in the room. I listened to the troubleshooting for a few minutes and asked one question:

“Has anyone called the number to hear what it’s doing?”

Blank looks.

I picked up a phone and dialed the line. Fast busy tone. Beep beep beep.

“The problem isn’t here. It’s at the exchange. Call the telco.”

An hour later the carrier opened a service investigation and found intermittent hardware failures on their end.

Months of tickets. Hours of internal troubleshooting per incident, and the final fix was simply getting it to the right people. Granted one of the guys asked me later how I knew what that kind of beep meant. I referenced past work at an ISP (oh, the skills you pick up over a career).

The instinct when something breaks is to look inward. Check your code, check your hardware, check your config. But sometimes the problem isn’t in your domain at all. And no amount of expertise applied to the wrong layer will get you there.

The diagnostic that matters most is often the simplest one nobody thought to run.