Wrangling Telecom Techs & Customer Service

First, have your facts in order: If you are having trouble with your voice/data service or phone system, it’s important to have good info. Particularly if it’s one of those ongoing problems that is hard to nail down and get fixed. Keep a basic trouble log. Include date and time of issues, a description of the problem, any temporary fixes, any info provided by vendors who worked on it and anything else you think is relevant. For one thing, it will enable you to cross reference to any traffic/error log info you may get. And the info is very valuable to techs that show up to work on the problem. It also provides you a record of things you can look back on over time to evaluate your system and vendor performance.

When you call in a trouble ticket:

1. Get a ticket number
2. Ask for an ETA
3. Ask how to follow up and with who
4. The second they miss the ETA, follow up and keep them honest
5. If they are dropping the ball in any way, don’t hesitate to escalate to a manager

Carrier and PBX techs are a squirrely bunch. Whether they are there to repair your voice/internet service or install new service, they want to fix/install things fast and move on to the next job. All too often this leads to passing the buck (ie, the well know exercise where the PBX tech points at the Carrier tech and vice versa) or perhaps just not checking their work completely. Thus it’s common for them to leave before things are truly 100%. My advice: Don’t let them leave! Thoroughly test everything you reasonably can: main numbers, toll frees, faxes and POTS lines, voicemail functions, internet speed, etc. Even check some of the things you think aren’t affected. It’s much easier to get a tech to stay a little longer than it is to get them to come back.

When you do get into a finger pointing situation where nobody will take responsibility, get them together to hash it out. Have techs from the various vendors meet on site to work through the problem. If you can, give them a couple days to prepare and collect data (eg, pull error logs, monitor/test circuits). Often times facing such a meeting motivates them to find a fix (sometimes they won’t admit it, the problem just mysteriously goes away) and avoid the meeting altogether. But if they do meet, in my experience, they almost always get to bottom of the problem.