When Does Support Turn into Customization?

I can haz color change plz? I want backgrnd wiv pink sparkles! Music on-load now! When does support turn into customization? How much help should you offer your customers? Mason James takes a look at that slippery line.

It starts so simply:

@BFF says: I <3 your WordPress product so much! It’s saved my career and brought meaning to my life. But I wish the text in this widget was red – not black. Help!

“Oh, I’m happy to help”, you think. Providing prompt, effective support is a big deal and here’s the perfect opportunity to make someone happy. They seem like a great customer already and happy customer are great for business.

It’s only 3 lines of code anyway, so what’s the harm?

@iHazNeeds says: Your product is pretty good, but I really need the sidebar to be on the right-hand side not the left. I’m also looking to display the 5 most recent posts from Category Z. How do I do that?

Ok. Not too challenging. There’s nothing technically wrong with my product, but still, this only takes me a few minutes to do and it really makes for a great showing of the care and attention I provide.

@OMGWTF says: Seriously!? I have been working on this for over 2 hours with no luck. Your “EZ downloads” plugin does’t seem to provide a unique customer portal for my clients!? I’ve already spent too much time on this thing. Please provide me with the exact code to get this working.

You’re kidding, right?

If you provide a WordPress product or service (free or paid) you know that you’re going to have user requests. Some of them are going to be minor changes. Some will be feature requests. Some of them will be incompatibilities with a specific server or other product and, yes, some will even be bugs.

It can be tricky to draw the line between what falls under support and what is a feature request. Drawing that line means you’ll find customers with expectations your policy doesn’t meet. Unmet expectations means disappointment and very often an unhappy customer or no customer at all.

Obviously this all varies depending on what service you offer and what level of support (and topics) you claim to provide.

You could easily claim that none of the three questions above are support requests. They’re all “custom development” and the customer needs to find someone to take care of that for them if they can’t do it themselves. You might not even be wrong in claiming that. But you also might get known around the interwebs for “lousy support” if you don’t assist every now and again.

Then there’s the human element to the whole thing. Maybe their tone is off. Maybe they’re super nice and you like helping them. Maybe this is the 4th question in a row and it’s just gone too far. With each question, you have to decide if the “issue” is for you to support or if it’s something they need to get from somewhere else.

Over at WPMU DEV we support general WordPress/BuddyPress questions alongside support topics based around our products. However, we monitor and track the resolutions for support tickets. They get a higher priority from staff than the general WordPress questions. Additionally, we have a soft guideline of 15 minutes for any sort of custom work or request. It’s not mandatory, of course, but if one of our team is able to mash out a bit of CSS or a quick function that gets a member closer to what they are looking for, we try to assist.

What do you think? Are there times where “support requests” are clearly outside the boundaries of what you can do? By providing a little custom development do you set members up for disappointment down the road when the requests get more involved? How do you handle unreasonable expectations?

Spread the word:

Comments

I’m quite interested in the relationship between commercial support and the support provided by the volunteers at the WordPress support forums. As the lead of a commercial support team, at what point do you think “this isn’t my problem – this guy needs to go to wp.org for that”. Or do you see yourselves as offering a service comparable to what is offered there (thereby picking up the slack maybe?)

Anything that is a clear problem and is repeatable in the default theme (TwentyElven or twelve) that;s when we send ‘em on over to the wordpress.org forums. Or right after a new version comes out and people are finding bugs or conflicts.

I also send people over to the docs all the time – things like the Permalinks page, for example. Users sometimes feel that permalinks are a theme issue because.. well, they show up in the theme right? ;)

I think I need to link to this below every “Start New Topic” form :-). Our general policy related to support is quite simply; We have none. We’re learning as we go, and we’re constantly looking at how we can find the sweet spot in terms of giving support, and motivating people to figure it out themselves.

I have a background as a community manager for online gaming forums, and if you’ve given support to pre-teen gamers, doing WordPress support is a breeze :-) As long as people take the time to type out their issues and ask questions related to our products I’m happy to help them out. That being said…. It’s not my job to learn our customers BuddyPress/WordPress or some 3rd Party Plugin or theme. People tend to just keeping asking questions as soon as they’ve found someone who knows his way around WP. No matter how nice these people are, overtime you’ll give the message to new and existing customers that anything goes, and you’ll end up spending a lot less time on your forums and keep valuable content for others locked on your forums (instead of BP/WP.org)

All the code snippets we provide for our Infinity Themes are placed as Gists on GitHub as well, so over time we can hopefully build up a library of snippets of commonly asked theme changes. The trick for us is to make it somewhat worth the effort to go the extra mile giving support. All in all it CAN be a really rewarding experience giving good support and I believe that having a friendly support policy will lead to a friendlier community with hopefully people helping others in the long run (like on WPMUDev)

I totally agree with you when it comes to 3rd party products. Even that can be confusing when there is a problem for the customer though. You say it’s the issue lies with the 3rd party plugin, but the plugin developer says it’s due to your theme. The customer is left in the middle with know idea who is “right”.

I’d say 3rd-party compatibility policy is important right after a support policy. I love your idea of keeping the code snippets on Github and may have to steal that one. :) Friendly support definitely lends itself to a friendly community most of the time ;)

While it’s a fine line I always struggle with this as I am biased to which customizations I’d like to take the extra few steps and help solve. If it’s something that I find fun or interested I sometimes find myself going the extra mile. Sometimes this turns into a whole afternoon when it was meant to be a few minutes and quick answer.

I think it’s best to stick to your support policy in the end whether it be 5, 10 or 15 minutes, etc. If something is outside of what your able to provide support for let the user know and move on. Seriously though, be strict with this.

If you keep providing the “additional support”, that’s outside what you are actually able to provide, users will start to expect this from you in the future.

Another great tip here is to not just give them the right answer but teach the user as well. As an example I’ll often point a user to a Firebug or Chrome Inspect tutorial if they ask “How do I change the title color to sparkly pink?”. I’ll show them the correct CSS and then in the future they hopefully can do this on their own. Otherwise there is no motive to learn and quick answers that can be taught are always asked again and again.

I totally agree with the “teaching folks to fish” philosophy of providing the tools for success rather than just an answer. Actually, I should have my response that points folks to FireBug should be saved in TextExpander… ;)

Which is another great point. Those of us who love working with WordPress have found this by actually learning it ourselves. Giving folks a nudge to learn it themselves potentially creates a future awesome contributor to the community.

If it’s a *common* customization request,s then that sort of thing is perfect for a tutorial – especially if someone can follow the directions and get the same result every time.

One place where we drew a line was changing the overall dimensions of the theme. While it seems fairly straightforward, there are a lot of divs inside other divs before you get to the content and sidebars, and it turns out anyone who has every asked wanted something slightly different. It would quickly snowball into a large tutorial covering different variations.

And that;s something that is custom, outside the scope of theme support. ;)

Showing a user how to use the theme is support. Showing how to use the available functions is also support.

Writing code for them to give additional functionality is not support – it’s dev work.

Andrea’s idea about making a tutorial is something we practice at ClickWP too. I’ve been publishing tutorials on the blog and slowly but surely putting together a WordPress knowledgebase – http://clickwp.com/knowledgebase.

We are a support company and our promise to our customers is that we are a ‘one stop shop’, so we do take care of customizations but we limit it to a certain number of hours per month. I think one thing that keeps it sane for me is that we only offer monthly plans, unlike some theme or plugin where you may pay once for lifetime access.

I’ve seen a few conversations recently about creating a central spot for more user-based documentation. Think codex but with more hand-holding. WordPress.com has some great stuff, but it would be cool to have community-generated content that all professional WordPress vendors could tap into.

Imagine, when the WP UI changes, one image gets updated and everyone’s got the right image again. Oye the pains of updating screenshots….

I really dislike a trend I’ve seen lately that doesn’t make past support requests easily accessible. People learn from others’ questions. I’m heavily involved in the ThemeHybrid community, and so many of the questions are repeats.

Yes, many are not strictly theme questions, but general WP questions, but I never mind helping someone out or at least pointing them in the right direction. plus, after a certain period of time, most of what you need to answer, you can just cross reference where you’ve answered it previously.

I think it’s totally legitimate to set strict limitations on where support stops and customizations begin. But it’s really a nice benefit when a support team goes “above and beyond” their requirements. I think it’s worth pricing the “above and beyond” into the price of the product itself so you can be exceptional in support.

I don’t know why folks would hide past support requests. Our forum history on WPMU DEV is all kinds of awesome for Google searches.

“I think it’s worth pricing the “above and beyond” into the price of the product itself so you can be exceptional in support.”
+1 for this. It probably doesn’t make sense for every company to create solutions for every question/request that comes across the table but being able to “shine” is rewarding for the support team and for the member – everybody wins.

I personally came from 20+ yrs of technical and customer service with tech firms so support for me is the #1 thing. Couple that with the fact we are a small boutique firm working with zero IT staff capable companies all the time. For this reason the line between support request and DIY gets blurred.

We really encourage our clients to buy blocks of time from us and they can use them for anything they want on their site. We have found this to be the best happy medium. It also cuts down on the misc invoices for 1hr here and there. We further encourage clients to go this route by discounting the hourly rate if they signup for a multi-month support contract.

@David – Yes that is the way to do it. Only people with an ongoing support contract get to bug you for help, and small shops or freelancers should be very careful who they extend this offer to.

Some clients may need a retainer or other way to buy time in advance, but I would avoid taking on random requests with a pay-as-you-go deal. What works is setting up long-term contracts with people you want to work with. Those are the ones who can handle the cost and understand they are paying for your availability.

Watch out for people who think a support subscription type of arrangement means they ought to “get their money’s worth” by badgering you as much as possible with trivial requests.

We have them sign a contract that states that we bill in 30min incriments (for base support contracts) or they can pay a higher rate and get 15min increments. So if they try to “get their moneys worth” with tons of requests they will run over. We have one client that pushes it each month, but for the most part our other clients just like having a “safety net” knowing that if WP updates we are there to test the update on their site, or if they have an email issue we can help them. It has been great for loyalty and we are averaging nearly 3 referrals a client that are on the support program vs 1 or less for those that are not.

That’s great! Interesting idea with the rates. Since in a lot of cases support is something we need to provide automatically and without clients necessarily understanding the details (upgrades, security related tasks, backups) I just cover this with an annual or monthly plan and offer a free hour + some discounted hours for support requests. Unused time accumulates as credit toward some % of a big future project.

1. Every event is billable. Be it customization, custom programming, theme support, or anything.

2. If I decide to give free services, I continue to track time and issue an invoice which has a 100% discount applied. This drives home the idea that they are getting something that costs money, but I have chosen to give this to them for free for whatever reason. The value is still present, because they’re still getting a bill that’s magically and graciously taken care of.

If its something small, I may comp it. If its something involved, like moving a sidebar on a theme that doesn’t have a simple switch in the theme options (I mostly use WooThemes themes, and most have that functionality built in, so I just point them to the knowledge base on changing WooThemes template options and close the ticket without a billable event), then that’s going to be a billable event that may or may not be charged.

If they want a full blown private customer portal, that’s going to be a new billable project. Scope document, needs assessment, the whole nine yards.

Nice Nathan. I think what’s most important about your tactic here is that you are always in charge. Sometimes in the freelance world we forget that we are the business owners – not the clients/customers.

At the end of the day whether or not something is actually paid (I like and also use your 100% discount applied idea) it’s important that it be your decision and that it’s one your comfortable with. Definitely keeps down any resentment or feelings of being manipulated when you know ahead of time where your boundaries are on billable services. Thanks for sharing!

Trackbacks

About Mason James

Based in Sarasota, Florida, Mason is an expert at supporting WordPress. He heads one of the largest commercial WordPress support teams on the planet, at WPMU DEV, and has recently launched his own WordPress management and support business, WP Valet.

He's made an art of making people happy with their WordPress experience, which usually involves being nice, listening to their problems, and not complaining about them (to their faces).