With each passing day, I am amazed at how content society is with the level of customer service (or the lack thereof) citizens of this planet receive. I was brought up to provide the highest level of customer service at all times. This, likely is due to my first job being located on a posh retail area in Chicago Illinois. Here, appearance and perception was always seemingly more important that the actual situation.
Mistakes happen. Miscommunications happen, and will happen as long as humans are involved. However, customer service is about how those situations are handled and hopefully resolved.
I’ve recently interacted with several very unique and diverse entities where I was left either scratching my head or turning another grey hair. At times, I was speechless, yet verbally repeating the situation to the customer service representative in an attempt to have them agree that how they were handling the situation didn’t make sense. Yet I was rarely rewarded.
The Email Alert for everywhere but where I am
A major online job search service offers an email alert feature that sends an email with the latest job offers that matches your criteria. The criteria for the saved alert limits opportunities based on keyword criteria, geographical range, age of offer, etc. This is a very common feature that has always provided somewhat accurate results.
Recently, after a website redesign, I noticed that the emails received contained a majority of offers that were not in the geographical location selected. Thinking it was human error on my part, I tried a couple times to recreate these saved searches/alerts. When I continued to receive inaccurate alerts, I contacted customer service, explaining the inaccuracy. The received response, obviously scripted, explained how to create a saved search/alert. Needless to say, I decided to drop the seemingly hopeless issue.
I recently dealt with a major web hosting service, attempting to transfer a client site to their servers.
While preparing the site, I encountered a problem with email being generated from a simple script. After contacting customer support and after a day or so, I was told that a mail queue was blocked. The customer service rep then communicated that the issue was resolve by clearing the queue. I asked how the queue was cleared, by resolving the problem email, or deleting the queue. After some delay, I was told that the queue had been deleted. I expressed my dismay and concern that if these had been production-level emails, that this would have incurred a possible loss of sales (my client has a lead-generation site). I also inquired whether any monitoring was implemented on these servers, to which the reply was “no.” However, I was then sold on the option to move my site onto newer servers, for free, that had proper monitoring installed. It was also communicated that I would eventually be moved to the newer servers. I agreed to the move, in hopes that the issue would be resolved.
After alerted to the successful move of the site, I began my testing, only to incur some new error messages related to authentication. When I contacted customer support, I was told that, indeed, it was necessary to use authentication when sending email via a script on this server. So I asked how I should do that. The response was to use the “PEAR” PHP module, and told where to find information on this on the Web. Now, I’m not a technologist, but technology has never stopped me. So I obtained the information (from the Web) then added the appropriate code to handle authentication. When I received a cryptic error message, I again contacted support to determine the problem. After a couple days of support back & forth, it was determined that the “PEAR module was not (and would not) be installed on the server. When I then again asked how I was to send email using authentication, I was simply told that I had to use authentication.
I elevated the situation to a supervisor, trying to get some resolution to the issue. After some research, he suggested that my site be moved to a different server that did not require autentication. When challenged on the prior issues with mail queue and the eventual move to newer servers, he said there was no such plan to move sites. I cautiously agreed to the move.
Now on the new server, I attempted to start testing the email capability. Unfortunately, I was unable to even get that far before I discovered a new problem. Apparently, included files, which are used throughout the site, were generating error messages. The message referred to “parent paths.” Frustrated that, yet again, a different server had a unique configuration, I contacted support.
One thing I haven’t mentioned as of yet. Because this account is on a Window server, support for Windows is much less responsive than their award-winning Linux platform. So each inquiry or response would take on average 12 hours to see the next response. At this point, we’re 18 days into the original issue.
As the response was taking too long for my taste, I started taking measures in my own hands. I began changing the way I included files. About a third of the way into that change, I received a response from support that they had just turned on parent paths. <sigh>
Within a day, I tested the email script functionality. All was set to go live with the site on the new servers. OR so I thought.
We started the domain transfer from the old host to the new host. While these transfers take 24-72 hours (worldwide), my experience is that you typically see the change sooner, like after 12-18 hours. At the 6 hour mark, I saw the site pointing to the new servers. Shortly afterward, the site generated an error, as though the site didn’t exist. Again, I contacted support. After another 24 hours, it was finally determined that the hosting service’s nameservers had a corrupt pointer to the site. The suggested solution was, yes, you guessed it, to move the site to a newer server.
I immediately transferred the domain back to the original hosting service, then contacted support to request that the account be closed.
All in all, 3 weeks of support interaction, 36 hours in client website downtime, wasted resources, efforts and a plethora of frustration from the incompetence of a presumed quality service provider. The only satisfaction I received from this situation was the closure of the account.
I am a huge fan of operationalizing processes. Typically, you get a more effecient results. However, what about quality? You cannot operationalize the handling of human issues. You cannot provide a solution, whether it’s useful or not, and expect to say you provide quality customer service. Each need to be handled as they are, unique opportunities to serve, retain or obtain a customer.