I think the paragraph “Fixes for bugs and reported issues with the item” should contain (at least for WordPress plugins) the mention that “Authors are required to fix bugs and reported issues” only if the plugin did not suffer major customizations from the buyer’s side. I had a couple of buyers who made some major customizations and improvements after they have bought one of my plugins and then they required bug fixes on their code, telling me that basically I have to provide support, since it’s my plugin.
This is an important factor to consider when speaking of “bug fixes”. I think the goal of the document there is to keep it short and sweet (so people actually read it), but maybe we could link to a Wiki that expands on the definition of a “bug” and how it can be properly verified for both WordPress and non-WordPress items.
5. Avoid providing unnecessary refunds when buyer says I bought an HTML template thinking it was a WordPress theme. An author clearly states in his item title and details what the product is so it is buyer’s fault as he didn’t read the description. Wow, what a coincidence here
The problem is most of these cases are usually honest mistakes. We live in a “click first, read later” world now.
Here are the main points that make this way better than before:
Authors with items on ThemeForest and CodeCanyon will be able to choose whether or not they support each item (on an item-by-item basis).
There will be no prescribed turnaround times but we want to give authors the ability to set expectations clearly with buyers. We’re still working on exactly how to do this but it will likely be in the form of a setting that authors show to buyers.
Yes authors who don’t “opt-in” will be at a disadvantage to competitors who do, but this isn’t really different than the current system, where all items have a “Support” tab which states whether the author provides support or not, and then if an author currently says they provide support, they’re expected to provide it (or otherwise would be participating in “false advertising” which isn’t currently allowed).
Yes Envato is going to set the cost for support, and also take a 30% cut. But authors now have the choice to not participate, whereas before, it was going to be mandatory across the board.
Things that still need to be ironed out:
1) Giving authors the ability to issue refunds automatically, for both the item purchase and any additional support packages purchased (solves the “help, I’ve been taken hostage by an unreasonable customer” situation).
2) How “Author Vacations” plays into everything. If an author is advertising and selling support, but then takes a 6 month vacation, obviously that isn’t going to fly, so some type of reasonable parameters need to be figured out.
3) What happens if an item is deleted by the author or by Envato. Do purchased support packages get refunded to the customer? And if so, will Envato issue a charge-back to the author for the loss?
So there’s still some important unanswered questions. But based on phase 2, I’m definitely optimistic.
Additionally, DOTonPAPER’s comment about customers not reading details is spot on. For the support forum I work with, we recently changed the forum’s homepage to prominently ask for some specific details about the customer’s environment to help us solve issues faster (simple things like “what browser and OS are you using”). And only 1% of all customers actually include the information we ask for. So some brainstorming needs to be done to figure out how we can effectively communicate support policies to buyers. Maybe the best solution for this is to send the buyer to a “purchase confirmation” page where they can review the support details and “accept the terms” before they’re allowed to actually make a purchase.
Authors with items on ThemeForest and CodeCanyon will be able to choose whether or not they support each item (on an item-by-item basis).Great move, hope this stance will not be changed any time in the future!
I think Envato really came through big time on this. Authors get to keep their freedom, with the chance to make additional money. Sounds pretty sweet to me. And the best part in my opinion are the planned efforts to clarify support expectations.
I don’t really hire freelancers, but I do have experience with “partnerships”, and my advice would be to only get involved deep with people you trust. Not always easy when you don’t really know the person to begin with, but you could task them with some very small jobs to start and then see how they deliver. Then once you’re confident you’ve found the right person, you can feel confident handing them something much bigger.
^ +1 Hogash,
Although Envato made some progress with helping buyers learn about support expectations via the new “Support” tab, they didn’t take it far enough in my opinion. You know that little confirmation alert that says “You are about to purchase xyz, do you want to continue?”. There should have been another alert for non-supported items that says “Support is not included with this item. Would you still like to purchase?”.
And there could be a warning for supported items as well: “Support is included with your item. Click here to learn more about the support this author offers” (with link to item’s “Support” tab).
But let’s face it, making it this simple is bad for business, as it would cut down on impulse buys.
Fabio’s “multiple tickets get answered last” system is a brilliant system, as it gives everyone a chance to have their questions answered, while also preventing the bad apples from monopolizing support. But unfortunately, this system wouldn’t work under the new “72 hour” support policy.
Here’s a breakdown of the typical support question:
1) Basic, reasonable “how to” questions – 20%
2) Hold my hand questions (aka “do it for me”) – 40%
3) Reported bug (aka “please personally research how I botched the implementation”)
And here’s how they apply to the new support system:
1 – Now required with new support
2 – Can be rejected as it’s considered custom work
3 – Once the botched implementation is verified (95% of all cases), can also be considered custom work and therefore rejected.
So in the end, creating a mandatory system that only covers #1 above, and technically excludes #’s 2 and 3, the amount of actual progress made is minimal.
So much amazing talent here! “Hard Reject Monster” my favorite so far. I always wondered what that reviewer looked like
Support for this item is offered here:http://codecanyon.net/item/thumbnail-gallery-wordpress-plugin/294024/support