We challenge everyone at Go Daddy to get involved with customer service on a regular basis. For some teams, this is tied to goals and bonuses.
During one of my customer service shadows, I listened to a Customer Service Rep handle a call where the customer reported that his site was slow. I remember empathizing with the customer. That call stuck with me, and it itched in my brain, for weeks.
There has to be a “best” way to handle these types of calls. We need to optimize the flow and get better answers earlier in the interactions.
I checked to see if anyone was working on this and found several teams already were coordinating efforts to deploy new tools, new reports, and new training. I joined the effort and worked to develop and deploy the P3 plugin for WordPress as part of our overall strategy.
Why can’t you just tell me why my site is slow?
There is no single cause of slowness and there is no single cure. This causes frustration on both sides of the phone. I like this analogy to explain how customers feel when looking for support:
I just bought a new laptop that runs Windows. I installed a bunch of software and now it’s slow. Do I call the store where I bought the laptop, or Microsoft, or the laptop manufacturer, or the authors of the software I installed?
Most hosting customers call us first. We need to answer their questions effectively or direct them to the WordPress forums or the plugin authors’ websites for support.
So, what’s the plan?
With permission and some optimism, I set out to see if creating a “best practice” for handling calls related to slow sites was possible. I looked at a week’s worth of “My site is slow” tickets and I noticed most of them were related to WordPress.
This makes sense for two reasons. First, WordPress encourages the use of plugins, and plugins can slow down a site’s run time. Second, we have a lot of customers using WordPress.
Browser vs. Server
Next, I noticed we can quickly and consistently tell when a site is slow because of server slowness or browser slowness using tools like:
We trained our Customer Service Reps to use these tools and we wrote a help article to which we could refer our customers, too.
Plugins vs. Infrastructure
Lastly, we split server slowness into “plugins” and “infrastructure.”
How do you fix infrastructure problems?
One of the most important parts of fixing infrastructure problems is identifying them correctly. We have industry-standard monitoring practices in place for our hosting environment and we are working on more advanced monitoring at all levels of the infrastructure. We’ll save that discussion for another post, though.
How do you fix plugin problems?
WordPress plugins are mini-apps. Unlike apps on your phone or on a computer, plugin code in WordPress is not sandboxed; it has the same run-time permission level as the WordPress core.
Plugins vary greatly in their quality and impact on your site. For a more detailed analysis, see the January 2012 plugin performance test on dev4press.
Our best weapon against Plugin-Induced-Site-Slow-Down (PISSD) is transparency. If we can create a tool that can be used by customers on any site, and shows a consistent correlation between plugins and performance, then we can complete the feedback loop for customers.
We want customers to have the power to quickly choose the right plugins for their site based on features and performance.
Here’s the first version of P3 ever seen. The results were encouraging. We still had months of work ahead of us, though, before it was ready to release.
Taking an Iterative Approach
We decided to use an iterative approach to make this vision a reality. In my next post, I will discuss how we released P3 by starting with the question “Is it possible to know if a WordPress site is slow due to plugins?”
