stevedoria.net

After setting up and testing network monitoring software for one of our co-lo sites, it became apparent that mx.messaging.sprintpcs.com was rejecting connections from the monitoring server. I used typical methods, which include using telnet to connect to the SMTP port while analyzing the connection with a packet sniffer, to determine that the problem was with Sprint’s messaging server. It is fairly obvious that mx.messaging.sprintpcs.com closes the connection immediately after the initial TCP connection handshake. Another person shares his experience with this problem, and he can only wish that others fare better than him.

Dealing with Sprint’s front line technical support is pretty wearisome. The experience parallels the “our computer must be right (and you must be wrong)” scenario that was popularized throughout the 80s. One support representative stated, “You’re doing too much to send out text messages and making it hard for yourself.” I expressed my opinion that I would be better served by a person who did not see difficulty in resolving the problem. I was later contacted by a network engineer with knowledge of Internet protocols and using SMS over their SMTP server. He was better equipped to investigate the problem on their side, and he was very capable of helping me with any issues on my side. He actually introduced me to SenderBase, a spam monitoring service that is supposedly used by many large ISPs to minimize spam. The problem was ultimately resolved, and I continue to be a content Sprint subscriber.

One thing that I relearned from the front line technical support representative is the need to treat every problem with some attention. Because a problem seems typical, it is easy to resort to scripted responses. This might be a knee-jerk reaction that is rooted in a combination of both laziness and misplaced pride. Over the phone, the front line technical support representative sounded very authoritative with years of experience in her position and required some persuasion in forwarding my trouble ticket to a network engineer. Only through a more careful investigation can a problem be found to require a new solution.

I, too, served on technical support’s front line. Control of the conversation is very important. Effort needs to be made by both parties in keeping the dialogue from degenerating into a shoutfest. After all, in the typical case, the technical support representative accepts outbreaks from the outraged client as part of their job and simply shrugs it off at the end of the day. With a reasonably calm voice, it is almost always better to seek out solutions and keep communication open when forced to do so over the phone. Talking with a phone representative should always support the underlying objective of trying all available options, which is inhibited by frustration and raised voices.

This entry was posted on Tuesday, June 13th, 2006 at 6:25 pm and is filed under - blah -. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed.