edit, need to drink more coffee so I can read better
I’m thankful for all the awesome people I’ve met here on the Envato marketplaces. Customers, fellow authors and staff
if(sales === 0 && purchases === 0 && firstComment === ‘flagged’) autoDisableEntireThread();
For me, I figure that 70% of whatever they sell the support for is infinitely more money for me than the 100% of the $0 that I current charge for lifetime support. Don’t get me wrong, I’d love to have 90% instead of 70%, but like I said, it’s more money than I’m charging now. Like I said in my previous reply on here, I’d still love to see an actual support system solution implemented here for that 30% cut that they take.
I know lots of authors are comfortable with their own support systems, but when you look at this from a customer’s perspective it’s really a no-brainer in my opinion. For example, when a customer buys 10 items, they’re sent to 10 different support sites, where they have to create and keep track of 10 different logins, and then find and enter their purchase code information for all 10 sites.
The power to never need sleep!
Here’s the big question. When the SaaS customer contacts them for support do they send the customer to you??
Congrats Unodor Definitely wish I was in your shoes!
Wishing you the best Dan. Thanks for the great communication and improving the elite program
doesn’t maintain and run a general WP theme/plugin forum
This is a great idea. What takes up most author’s time is the fact that most customers seeking support have very poor troubleshooting skills. So the public forum could exist for this specific purpose. Some examples:
- Check to see if the customer is using the latest version of the plugin/theme, and provide information about how they can update.
- Teach the customer how to identify conflicts (temporarily deactivate other plugins, switch to TwentyFourteen, etc.)
- Remind customers that purging WP cache plugins often solves lots of issues.
- Identify and communicate front-end console errors to the customer.
- Identify and communicate broken HTML markup (often caused by custom filters).
So nothing specific to the actual product(s), but basic things that will teach customers how to troubleshoot their sites. Because the biggest support burden doesn’t come from the 10 customers who ask only 1 question. It comes from the 1 customer who asks 10. And it’s always the latter who has very poor troubleshooting skills.
Also I doubt authors will implement a “kill switch” for users who “used all their tickets”.
On rare occasion it has to be done. My biggest concern is as of right now, authors don’t have any guidelines or tools for dealing with these situations.
CodingJack said@CodingJack: interesting idea. Do you know if something like this exists out there already?
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.
The general idea is to effectively communicate the difference between a bug and a usage error, and it would need to be specific for different product lines (CC jQuery plugin, WP Theme, etc.). Here’s an example:
I think I’ve found a bug in my CodeCanyon jQuery plugin but am not 100% sure. How can I verify this?
Download a fresh copy of the plugin’s source files (insert link to downloads page here), and test one of the html example files included with the product. If the bug doesn’t exist in the original source files, and only exists on your site, it means something went wrong with the implementation process. For example, if the item works “out of the box”, but doesn’t work once added to your site, something must have gone wrong somewhere when modifying the item’s content/settings and merging the item with your site.
In these cases, the best way to find out what went wrong is to start over from scratch, and test the item frequently as you customize/setup the item. This will allow you to identify what exact step caused the issue, giving you the proper insight as to whether the issue is something simple (url wasn’t written correctly, etc.), or if the issue is more serious (a settings option described in the item’s documentation simply doesn’t work).