Every interaction with every customer, beginning with our first response, has a singular goal: getting to resolution.
Another way we say that is that our customers’ success with our product is our first priority.
We intend to solve our customers’ issues in 3 replies or fewer. A resolved ticket is one that has at least one reply from the customer after the initial contact, and has been marked closed by us. We don’t mark a ticket as closed until it is confirmed resolved, or the customer has not replied after a few days and after we have followed up asking for confirmation.
To get to resolution, we need as much context as possible from our users. There’s a temptation to take two different shortcuts which represent the tension between what is our role as experts and their role as the owner of their web domain.
On the one side is the temptation to ask the customer to “deactivate all plugins,” while on the other is the temptation to jump straight to requesting admin access to their live site.
Both of those extremes are indicators that we are guessing at a solution instead of moving toward resolution.
A common refrain in WordPress support is “have you tried deactivating all plugins?” to resolve an issue. Asking the user to deactivate all plugins is asking them to:
There are times when deactivating plugins is the most effective way to isolate the source of the issue. In those cases, the recommendation should be because we, the experts, know with certainty that this will resolve the issue. We should frame the act as temporary, and a diagnostic tool to confirm our educated guess. Also, reassure the user that if a conflict with another plugin and ours is discovered in this process, we will work to find a workaround for the conflicting plugin or theme.
Advice to deactivate plugins runs the risk of coming across as dismissive or flippant. Instead, it should be educational and empowering to the user. That happens by adding context, and expected outcomes. We tell the user how to most effectively troubleshoot their problem to get to resolution.
Lastly, whenever possible, if a staging site is available, or a full-site duplicate is available, using those for the deactivation process is preferred. When none of those are an option, point the customer to our detailed tutorial on using the Health Check plugin as a last resort. That guide is designed for DIY folks, and not to be sent unless we make it clear that we can’t help them. Cases like privacy regulations that prevent us from accessing their data are the most common times we send that tutorial.
Sometimes the most effective way for a technician to fully understand a problem is to log into the customer site itself. But there are several ways to get that access that do not put the customer’s live site at risk. Whenever possible we want to avoid logging into a live production environment.
Additionally, asking for admin credentials is often an indication that the technician is guessing at a solution, instead of seeking the correct information to resolve the issue.
If no other options are available, then we ask for live site credentials, but with a lot of care and context. Requests for admin credentials should have at least three things in them: