Custom PC worked in the lab, failed on site – and so did the angry client

The Register's long-running On Call column shares reader-submitted anecdotes from the front lines of tech support, chronicling both the frustrating lows and occasional humorous highs of field work. This week's entry, contributed by a reader anonymized as "Gerald" per the column's tradition of "Regomizing" sources, details a classic mismatch between lab testing and real-world deployment in the Windows 98 era.

Gerald shared a story from early in his career, when he worked for a company that built custom PCs configured as data collectors for enterprise clients. His role involved assembling the systems, running initial functionality tests, and occasionally providing on-site support. For this particular job, Gerald built a new data collector, installed Windows 98, and ran a full suite of lab tests to confirm all hardware and software components worked as expected. With testing complete, he handed the system off to colleagues for on-site installation, as he was already scheduled to complete work for another client elsewhere.

The arrangement fell apart quickly. Gerald was mid-visit with another client when his boss called to chew him out, accusing him of letting a non-functional system leave the shop. The client installing the data collector was furious, claiming the PC was completely unresponsive and costing their business money by delaying data collection operations. Gerald's boss ordered him to drive to the site immediately, despite the 100km distance, to fix the issue and salvage the client relationship.

Gerald made the 90-minute drive to the client's site, where he was greeted by a customer literally hopping mad, berating him for incompetence and poor quality control. Gerald inspected the PC, which was set up on the shop floor connected to all expected peripherals. The system booted normally, all hardware appeared to be recognized in Windows 98's device manager, and a ping to the local loopback address succeeded, confirming basic network card functionality. No external network connections worked, however, leading Gerald to assume a hardware fault that required returning the system to the lab for deeper testing.

As Gerald unplugged the power cord, display cable, keyboard, and mouse to pack the PC for transport, he noticed the network cable was neatly coiled and taped to a support column behind the desk, never connected to the PC's network port. The fix took seconds: plugging the cable into the port immediately restored network connectivity, and all data collector functions worked as intended.

The discovery left both the client and Gerald's boss embarrassed. The client's anger was entirely misplaced, as they had failed to complete the basic setup step of connecting the network cable after the PC was delivered. Gerald's boss had chewed him out without verifying the actual issue, assuming the technician was at fault for a lab-tested system failing in the field.

Stories like Gerald's highlight persistent gaps between controlled lab environments and real-world field deployments. In the late 1990s, when Windows 98 was the dominant desktop operating system, remote support tools were limited, meaning technicians often had to travel long distances to resolve issues that turned out to be simple oversights. The On Call column has documented similar incidents for years, from forgotten power cables to misconfigured wireless networks, all reinforcing that field support teams should always check basic setup steps before assuming hardware or software failure.

The Register invites readers with their own tech support war stories to submit tales for future On Call columns via their contact page. Submissions can range from frustrating client interactions to humorous misunderstandings, all shedding light on the day-to-day work of IT support teams.