How do you handle irrelevant and out-of-scope requests?

(Leland Fiegel) #1

As a theme shop owner, I’ve noticed an uptick in what I consider irrelevant requests. Some examples:

  • How do I configure the featured images to be full width? (something not seen in demo or mentioned in documentation)
  • Where’s the accent color picker? (again, never mentioned in documentation, there is no color picker)
  • Where are the WooCommerce demo? (there is no WooCommerce support)
  • Why are these two plugins conflicting? (they conflict on any theme, the theme is irrelevant)

Basically, asking questions about features that don’t exist and problems that are product-specific. Despite a clear statement about what’s covered under support, questions like these keep rolling in from prospective and existing customers.

I get the feeling this is something other premium plugin/theme sellers have been dealing with for years. I wrote a quick blog post about why I believe theme buyers have these expectations.

Since I don’t get them very often, I’ll spend a little bit of time researching and send links to relevant tutorials and plugins, and politely explain the sort of question isn’t typically covered by theme (or plugin) company support. But I’m concerned this attitude toward people that don’t respect my support policy won’t scale well, and might lead to more demanding requests if I don’t become a little more curt in response.

This could apply to client projects as well. For example, requests for ongoing support when no maintenance contract is in place.

How would you deal with this?

(Jason) #2

Hey Leland!

So my agency only does custom themes for clients, but whatever nevertheless scope creep is a real thing. It’s especially difficult in an industry where the client doesn’t always entirely understand what they’re asking for. Some of the requests I get, mid project, are the equivalent of pulling in your car for an oil change then, in the middle of the oil being swapped, looking at the mechanic and saying, “Hey, while you’re under the hood, do you mind changing the transmission for me?”

From my understanding you have the two schools of thought. First is that you make the contract and never deviate. The latter is that you have no boundaries (generally a kind, well meaning person) and just let it happen. I think the healthiest answer is to have a plan of how deviation is handled and when. Accepting scope creep should be the exception, not the rule. Especially in projects, if scope creep is very common, there’s probably something wrong with the process.

For this sort of work, I can appreciate that it’s a bit challenging as the lines are being blurred as to whether folks are buying a product or a service as you provide support after the fact. It’s especially challenging if your support is public facing as how you respond to one person sets the expectation for how you’ll respond to everyone. I’d probably take some time to determine some boundaries that make sense for you and your product, and analyze what the benefit of being that strict/loose would be. Loose support draws more customers and may turn a customer into a client (i.e. custom development) but can also become a time eater for you; strict support may turn off some folks, but you can also provide better support to in-scope needs as you’re not as strapped for time.

We do our best to have a plan for how we’re going to support our clients, then follow through and be consistent. If we make slow changes through iteration to our support, that’s fine. We’re always trying to hone in on the best balance of value for the client and manageability/profitability for us.

Hope this helps! Sorry if I got a bit wordy. :sweat_smile:

(Leland Fiegel) #3

No worries! Your insights are much appreciated.

(Ben) #4

On Pro Theme Design I have a message at the bottom of every support page saying that we don’t offer support for customisations - only bugs with the theme, or setting up the theme to match the demo.

I also have a page that lists the difference between support and customisations, and I have a page specifically for customisations that links through to codeable.

If people ask for plugin recommendations or customizations or other things outside of what I offer support for I tend to reply with something like

Thanks for the message. Unfortunately we don’t offer help with customising themes, you can read the difference between customisations and support here: URL. If you want help customizing your theme then you can get a quote for that here: URL.

In this case you could look at doing X

Note the last line. I always try to offer some sort of pointer that will help them - even if it’s not something I offer support for.

(Nate Wright) #5

I would characterise my approach to such requests as “be helpful but don’t solve their problem for them”. Some of my common approaches:

  1. Person needs basic WordPress help: I often point them to a relevant tutorial/help page somewhere like easywpguide and encourage them to keep trying, while making it clear this isn’t a part of normal support. If they become a problem (rapid, repeated requests) I’ll encourage them to find paid assistance somewhere.

  2. Person is asking for something the theme doesn’t provide: I’ll often provide really basic CSS tweaks, with the caveat that this is a generosity, not an expectation. For more significant customisations, I point them to If they exhibit a courageous spirit with code, I’ll often introduced them to the techniques I would recommend they explore to accomplish what they want.

  3. Person is dealing with a plugin conflict that might be my fault: I’ll ask for help reproducing the problem, sympathize with their frustration, but also encourage them to follow-up with the other party. In some cases I’ve had to throw up my hands and say, sorry, I’ve got no idea what’s going on. But usually by then they’ve been heard out and though they may need a refund they’re not angry with me about it.

  4. Person is dealing with a plugin conflict that is almost certainly not my fault: This typically occurs with repeat offendors (shitty themes, page builders, etc). I’ll sympathize with their frustration, but outline the problems involved and explain that the onus is on the third-party.

(Donna McMaster) #6

Likewise I do only custom work, but a colleague who is a project manager drilled the following response into me: “Would you like me to put together a quote for the additional work?”

(Zackary Allnutt) #7

That’s my standard response.

(Zackary Allnutt) #8

I just wrote a big answer to the starting theme business thread, talking about expectations. I think there is a huge problem with expectations in the theme world and at the moment, I don’t know what the answer is, but I there are somethings I’ve done that have helped.

In my ticket system they have to agree to terms before leaving a ticket. See here for what I have written

I have also put up a support policy on my product page asking customer to read before making the decision to buy.

I’ve tried to make it really clear to my customers that I am here to help with theme bugs but I cannot help with anything else.

The biggest problem I’m finding is those who assume that any problem that happens whilst my theme is running means my theme is broken. Because they’ve made this assumption, they wont read any of my troubleshooting guides or do any basic troubleshooting themselves.


  • They’ve named a page and post the same.
  • They’ve installed a plugin that hasn’t been updated in years
  • They’ve got a massive back log of revisions and the server can’t handle it
  • They are using 5000px 5mb images