Just last week an important component of our website went down for no apparent reason. We have not touched the programming for over a year and a half. It’s the portion, designed in a programming code called PHP that allows editors to secure articles from our website for production in their newsletters, magazines, and in-house publications.
For us, this is a very useful marketing tool.
When we notified the company that manages our server, their response was typical of many technology firms. “They are working on the issue.”
Domestic or off shore, this type of response always tends to get me worried, because from the perspective of the customer, this means either of two things. The first is that they are actually not working on the problem and might even be off skate boarding in the streets, or that they can’t figure out what’s wrong. (Either way, I’m left without a speedy remedy.)
In this case it was the latter. Someone on staff did a review of our account and thought they could do things a better way. After messing around with the programming, they screwed up the site. When we were alerted by an editor that the site was down, we contacted the company. Their response: an email pointing the finger of blame at us.
I made a phone call explaining the situation. The site went down, yet we’ve not touched the programming at all. Besides, we had paid for back ups.
After 28 minutes on hold, I was told they would research the problem even further.
Once again we received an email a day later telling us that we’ve got our settings wrong, and that’s why it’s not working. Duh! Better yet, it’s up to us to fix our own problem.
I couldn’t believe it. We were again being blamed for their mistakes.
This type of dialog went back and forth for over three days until the CEO of the company emailed that they could restore our server for “only” $100. Restore it? It’s their problem, not ours.
The final phone call eventually ended up with a senior manager that said she would look into the issue. Two hours later an email arrived that everything was fixed. It appeared that our rights were changed BY THE ORIGINAL TROUBLE SHOOTER making all the “improvements.”
You might be thinking, why not move your server to another firm?
Like many customers, we don’t see enough differentiation from one firm to another, its design and people. IT’s next evolution has to be a strategy to enable a structured approach to design so that troubleshooters can identify and act in a fashion that’s consistent with other trouble shooters.
Larry Ellison tried this with Oracle 9I. He found that everyone who purchased his sophisticated software made so many modifications to the core of the product that customer service went nuts trying to solve basic issues.
Can’t run a business like this. So he developed a handful of basic products and said, here they are; don’t alter them at the core, or they won’t be serviceable. The result was that customers had what they needed while maintenance improved just because the engine was still an engine.
In this case, besides the techs blaming the customer, a no no, the lack of a consistent approach caused a whole chain of events including the CEO getting involved in what was not a CEO issue: especially for a $100 ticket and a customer that’s been loyal for 7 years.