Support Customers by Helping Them Help Themselves

If there’s a single, overarching theme that seems to resonate with product builders it is the pain point of support. Some despise it, but I’ve come to sincerely appreciate the support interactions I’ve had through SearchWP. It’s shown me how to be more patient, more understanding, and through that make SearchWP a better product in and of itself. When you’re building something it’s far too easy to get tunnel vision and make decisions that confuse customers more than enable them. Support interaction exposes those weak points very quickly if you’re willing to listen.

That’s not to say that all support is a wonderful experience, however. In an ideal world a support ticket (or however you handle it) is a last resort for customers. That’s why we spend so much time on documentation, examples, and UI refinements right? It’s great when customers are able to use existing resources to get up and running quickly instead of going through the process of reaching out for one-on-one support. While that interaction is nice, and can often attach sentiment to using your product, it’s also a speed bump for your customer no matter how fast you are to respond.

For me support is a major part of product development, it’s something that can (should?) be iterated upon consistently based on the needs of customers en masse. I’ve noticed a trend lately that has exposed a few things for me. First: I need to ramp up my documentation. There are hooks I’ve been meaning to document for weeks and I really need to be more disciplined and get that taken care of. The second issue was reducing the number of repetitive support tickets.

Support system

I really enjoy using bbPress as a support system for SearchWP. It was trivial to extend permissions check to take into account whether the customer had an active license which is backed by Software Licensing in Easy Digital Downloads. As an aside: if you’re building a WordPress plugin and need a licensing system I cannot suggest EDD enough, it’s been wicked awesome to use on many levels.

This isn’t about permissions checks though, I wanted to find out how I can use all of the knowledge accrued in the support forum to help customers who may be experiencing issues that have long been resolved in a past thread. That may indicate that my documentation could use some help, but I recognize that and plan to make a concerted effort with that as well.

Reducing repetitive tickets

Existing support threads are in some ways just as important to documentation I’m finding. I’m not sure if it’s because customers are used to documentation being too technical in nature or lacking altogether, but I can infer that at least some support threads are started without searching the docs, the knowledge base, or the forums themselves (for which there is a huge search box right at the start).

Then it hit me: I built a search plugin and I’m not using it to full potential. Why not encourage (read: force) customers to search the pile of documentation before opening a ticket?

Of course it couldn’t be abrasive, if a customer wants to open a ticket that should not be locked behind a walled garden of any sort. But I’ve got to imagine that if a customer were shown some sort of existing reference that tackles their issue they would be happier to help themselves instead of waiting for me to reply, no matter how fast I could possibly do that. With certain customers it’s never fast enough so the more I can do up front the better, I thought.

The idea: instead of showing the ‘create topic’ bbPress form the customer is instead shown a live search box encouraging them to use a few keywords to describe their issue. SearchWP takes over and shows the most likely candidates for a solution whether it be from the documentation, the knowledge base, any of the extension pages, or the forum content itself. That offers some probable, specific resources for this customer to look at prior to creating their thread and therefore opening their ticket.

When (literally) half a dozen very similar tickets came in over the course of a few days, I felt it necessary to try and implement something like this using the tools I’ve been working on for the past year. To my surprise it took under and hour and I think my customers will be better off for it.

Using SearchWP Live Ajax Search to pre-search bbPress forums

I’ve been using SearchWP on SearchWP’s site since the beginning, but this is actually my first time dogfooding SearchWP Live Ajax Search (documentation) so I went ahead and got that up and running. Out of the box SearchWP Live Ajax Search automagically enhances search forms generated by WordPress’ get_search_form() but I didn’t want that in this case so a quick filter disabled that:

add_filter( 'searchwp_live_search_hijack_get_search_form', '__return_false' );
view raw gistfile1.php hosted with ❤ by GitHub

My goal to integrate this custom ‘pre-search’ functionality was to keep it as simple as possible. bbPress makes that easy because like WordPress it has a ton of hooks you can utilize for tasks like this. My first step was to hide the topic creation form itself, which I did by simply wrapping it in a div, allowing me a reference point to hide and show it easily:

// implement forum pre-search before allowing for topic creation
function searchwp_bbp_theme_before_topic_form() { ?>
<div class="searchwp-pre-ticket-hide">
<?php }
add_action( 'bbp_theme_before_topic_form', 'searchwp_bbp_theme_before_topic_form' );
function searchwp_bbp_theme_after_topic_form() { ?>
<?php }
add_action( 'bbp_theme_after_topic_form', 'searchwp_bbp_theme_after_topic_form' );
view raw gistfile1.php hosted with ❤ by GitHub

With that in place I could use some CSS to set div.searchwp-pre-ticket-hide to display:none on page load, hiding the entire form. With that done, I then needed to implement my pre-search form, which is done by using another bbPress hook:

// output the pre-search form
function searchwp_pre_search_form_markup() { ?>
<div class="searchwp-pre-ticket">
<h3>Create Support Ticket</h3>
<p>Begin by <strong>using a few keywords</strong> to describe your support issue:</p>
<div class="bbp-search-form" style="padding-bottom:0;">
<form role="search" method="get" id="bbp-search-form" action="">
<label class="screen-reader-text hidden" for="bbp_search">Search for:</label>
<input tabindex="101" type="text" value="" name="bbp_search" id="bbp_search" data-swplive="true">
<input tabindex="102" class="button" type="submit" id="bbp_search_submit" value="Search">
<p><em>Good example:</em> <kbd>limit search results</kbd> <br />
<em>Bad example:</em> <kbd>not working</kbd></p>
<?php }
add_action( 'bbp_template_after_single_forum', 'searchwp_pre_search_form_markup' );
view raw gistfile1.php hosted with ❤ by GitHub

As per the SearchWP Live Ajax Search docs, enabling live search on this form requires only the inclusion of data-swplive="true" in the search field. With that in place, the final step is to implement the actual workflow of going from the live results pane to the topic creation form itself (if none of the suggested solutions provided by the live search pan out). That took only a few minutes by customizing SearchWP Live Ajax Search’s results template. To do that you only need to create a new file in a new folder within your theme:


SearchWP Live Ajax Search’s template system will use that file to display your results. Here’s mine:

<p class="searchwp-pre-qualify">
<strong>Please try these resources before creating a new ticket:</strong>
<?php if ( have_posts() ) : ?>
<?php while ( have_posts() ) : the_post(); ?>
<?php $post_type = get_post_type_object( get_post_type() ); ?>
<div class="searchwp-live-search-result">
<p><a href="<?php echo esc_url( get_permalink() ); ?>">
<?php the_title(); ?> (<?php echo esc_html( $post_type->labels->singular_name ); ?>) &raquo;
<?php endwhile; ?>
<?php endif; ?>
<p class="searchwp-nothing-applicable">
<a href="#">Nothing Here Helps, Create Ticket &raquo;</a>
<script type="text/javascript">
$('.searchwp-nothing-applicable a').click(function(){
return false;
view raw gistfile1.html hosted with ❤ by GitHub

It’s quite simple, I’m just iterating through The Loop of results, outputting the link, title, and post type of the resource. I’ve added a heading to help explain why the customer is seeing this live search results, and most importantly there is a button in view that allows them to skip this process and proceed to opening a ticket.

With a little CSS everything comes together like so:


The workflow is actually quite smooth, and customers can check out the most likely documentation/threads that exist to date and hopefully help themselves before having to wait for my reply. If none of the threads do in fact help, clicking the link at the bottom will dismiss the entire pre-search workflow and show the original Create Topic form by toggling the class that was causing it to be hidden.

I’ve seen this workflow put in place as a customer of other services and while the pre-search results didn’t always yield useful results, I’m confident that this implementation for SearchWP specifically should reduce some support volume and in turn be really useful for customers from here on out.

Implementations like these remind me of how thankful I am that SearchWP exists. I know I’m the most biased person on earth in this regard, but in all honesty using this setup I can now set up a supplemental search engine for this search form alone and use the statistics SearchWP tracks to correlate them between the ‘trends’ in support tickets over time. I’ll be able to decipher whether or not this pre-search workflow is getting any traction or not. This level of fine grained control allows you to keep a close eye on how search is helping your site in very specific ways. Enjoy!