A few weeks ago we released a new proposal for an item support model on ThemeForest and CodeCanyon.
On top of the new model proposal we said we’d come back with more information about pricing and timelines. It turns out we’ll need to come back to you about this later. There’s lots of discussion and change going on in another of our teams around VAT and the business model. As Collis mentioned in his recent post, we’re investigating ways we can alleviate and address concerns around the business model.
While we’re doing that, we’re slowing down our announcement around pricing related to item support and relooking at our timelines to make sure they still work alongside any changes happening elsewhere.
In the meantime we suggest authors start planning for the item support changes including thinking about which of items on ThemeForest and CodeCanyon they will support. We also recommend that authors remove any references to “Lifetime support”, “Unlimited support” or other similar phrases from item pages and in other places that may lead buyers to believe that support has no time limits.
As we said in the original blog post, we are not sure of the exact date but are still aiming to start the new model in the first half of 2015. This is still the case and in addition to coming back to you about pricing and timelines soon, we will be sure to provide plenty of notice to properly prepare for the change.
Thanks for your questions and comments over the last few days. Here are some of the things that have come up a few times.
Buyers doing significant customisations/modifications then requesting support because they think an issue is a bug
This is a great point and something we can request that buyers think about and check as part of the definition about “fixing bugs”.
Buyers putting many questions in one ticket and “overusing” support generally
The reason we think giving buyers guidance on a fair number of support queries rather than hard rules is that a few of the authors in our sub-group said that they did not want to feel restricted about the number of support queries they could supply. So we see the role of the “fair-use of support guidance” is to manage buyers’ expectations about how much support is fair without putting hard restrictions on. Natman’s answer above is how we seeing it being used – as a polite reminder for authors with the minority of buyers who behave this way…authors will now have something they can rely on to bring to the buyer’s attention that is not specific to just that author.
Also, we can specifically mention the behaviour of putting more than one query in a ticket in this guidance section to be clearer about it.
Buyers won’t read it/You need to make it very clear and visible to buyers
Absolutely. There will always be some users who don’t read everything but we know we have to increase the prominence of this information to make it more visible and accessible to buyers at the right times so more do see and read it.
While we haven’t designed exactly how this will work we know that buyers will need to understand what support is and is not during/straight after the purchase process and when they want to request support. For during/straight after the purchase process we are likely to make the definition accessible on the item page, purchase confirmation page, email confirmation and of course on the support tab. For when they request support, it will be made very accessible/visible on the support tab and the comments area.
@ThemesDepots definition was great and the type of detailed feedback we are looking for. We’d love more like this and in particular examples of the types of questions/issues that can bring the definition to life. So for example, questions that are about “customisation” that should not be included or that show that a 3rd-party plugin has caused an issue. Examples of questions that do fall within the definition would be great too.
You may want to define what a bug actually is, because many buyers don’t know. You may also want to mention 3rd party bug fixes(or conflicts) aren’t included.EDIT: I should have continued to read more but still think it should be mentioned
Hey Organicbee…thanks for this. If you’ve got a suggestion on a nice succinct way to define it, that would be great?
How can you quantify these times? And say there’s a problem and a buyer of a support pack is unhappy – do we just forward them to Envato Support or these guidelines? That’ll just make another person unhappy cause they paid extra for something with no quantifiable value – right?
Hi ThemeBeans…the idea behind saying the authors may take time with bug fixes/updates was so that buyers did not expect to report a bug and for it to be fixed immediately. It is to set their expectations and know that the author will also be able to manage their expectations too. We don’t want to be too prescriptive here as each situation could be very different.
Hi everyone – last week we put up a blog post with a revised proposal regarding the support model for items on ThemeForest and CodeCanyon.
There were a few things we said we’d come back to you about. One of them was about the definition of support.
For background, in the item support surveys we examined around 1,050 responses from authors and buyers of what should and shouldn’t be included in the definition of support to help form an initial draft. As we said in the blog, we have since enlisted the help of 15 authors to further craft and finesse this definition. We also asked them for examples of the types of questions that relate to each of the inclusions and exclusions in the definition to help us better understand.
You can see the result here. The idea is that this information or something similar would be made easily accessible to buyers of supported items before they purchase an item and in places they might start to seek support from after they have purchased (eg the support tab, comments).
Now we’re hoping to build on this work even further with you. We’re after 3 specific things please:
- Any comments and possible amendments to the definition of what is and is not included in item support
- Specific examples of questions you have been asked that would fall under each part of the definition (please reference the section, write the question and tell us what type of item it applied to like theme or plugin)
- Comments on the last section “Fair-use of support guidance”
We will be in and out of the conversation to answer new questions as they come up, but we’re mainly interested in reading your comments, examples and the discussion you have together. There will no doubt be a lot of different views and after the discussion winds down, we’ll have a look through the feedback to see if any changes need to be made.
Thanks for your help!
Thanks for your views over the last few days. This is a complicated topic as indicated by the many different opinions shared here. However, after months and months of research, careful analysis, thought and planning, we really do believe this clearer, more sustainable model for support is the best decision for the entire market, both buyers and authors.
There are a couple of key issues that keep coming up that are worth addressing.
Q. What about monetizing updates instead of support (eg with the license, 12 mths support and updates included)?
A: As I mentioned in a previous post, the significant range of update frequency (e.g., 30% of authors say they do updates quarterly or less) and types (basic right through to big new features) is a concern and presents the serious risk that some buyers may not purchase in the first place.
Q. Before the start of the new policy, what if a buyer believed they were buying with access to more than 6 months support?
A: Buyers should be able to trust the item descriptions, but assume that support will get limited soon to 6 months. While we are still trying to work out the start date it is likely to be several months before we get things rolled out, so that’s quite a long scope. Once we hit the start date there will still be another 6 months from then too, which is even further down the track. After that if there are pre-policy buyers who still want support extended further and the author agrees, then that can happen too.
So thanks for the discussion…we’re going to take this off global sticky now and wind it down before we come to you in another thread for discussion on the definition of support that we’ve crafted together with 15 authors followed by pricing later on.
Thanks for your questions and comments over the last day and a half.
One of the key things that keeps coming up is about the monetisation of updates. As I mentioned before, this is something we’re not ruling out in the future but our focus now is helping to improve the economics of support which authors have been telling us is a huge problem for some time.
It’s about to come to the weekend here in Australia but we’ll continue to watch this thread over that time.
Apologies for being away from this thread for a while. Below are some of the key questions that have come in over night (Aust time). I have used specific examples of the questions but slight variations or themes on these questions have come up too and should be answered with my responses to the examples.
Q: One downfall I can see is that if an author deletes a file, I understand that an author would still be required to honour support for a deleted file (I do already) but what if an author calls it quits and deletes everything and moves on?
A: We don’t know how often this will occur or how big a problem it is — we will watch and see how big of an issue this becomes and actively respond once we have more information. We presume the majority of authors will want to act in good faith in relation to this but we will need to keep an eye on it.
Q: What if I opt-out but provide cheaper paid support outside the marketplace? I can do that right?
A: Authors should not advertise support services in their item descriptions without opting-in to the basic level of support. Doing this seems like it would create a pretty bad experience for buyers where they are even more confused about their entitlement to support (or not). Authors can continue to provide customisation and services over and above the basic definition of support in line with the Item Promotion Guidelines.
Q: Why aren’t you trying to monetize updates instead?
A: We are not ruling this out at some point in the future. As I mentioned earlier, our current thoughts on updates are:
Q: What will happen to ratings? Will a buyer only be able to rate during a support period?
A: There’s more to ratings than just support, but yes, support-related ratings would be time-limited like this to help ensure the ratings are relevant.
Hi everyone…thanks for your questions and comments so far.
I’m about to head home for the evening but our Community Team and moderators will be keeping an eye on this thread over night Australian time. If you’ve got a question in the meantime, please have a look through the blog post or the first few pages of the thread to see if we’ve covered it already. Our responses will slow down from here but we’ll be gathering new questions to address when we’re back online.
Please have a good afternoon, evening or day!
@Bebel – thanks for the question.
We have thought about updates a lot…following on from what I meant above.
- Authors update items in many different ways…some only do basic updates and security patches. Others try to continuously add value through new features. Some do both and everything in between.
- Buyers are fearful of having to pay for a basic updates/security patches in the future and some have said they would not buy that item if they had to meaning the author may not get the sale in the first place.
- To get around this, we’d need a major/minor versioning system – major for value-add updates (possibly paid) and minor for basic/security patch updates (possibly unpaid) – this would add a lot of complexity and considering that authors update in very different ways would be hard to manage.
- We consistently hear support is a significant ongoing cost for authors that is mounting with time so we want to address this as a priority but not rule out addressing updates at some point in the future.
Hope that helps.
We considered updates very carefully and will continue to do so over time. Authors update their items in very different ways….some minor, some major, some in between and some all of the above at the same time. They also do them on very different timeframes. Buyers expectations regarding the type and frequency of updates vary significantly too.
....as you mentioned, support is a “cost” of doing business and a significant one for many authors so addressing this seems like a good step in the right direction.