So, you've posted to the Shopp support forums and you aren't getting any help... What gives? And what do you do about it?
First, please understand we sincerely want you to get the help you need. However, we are not a mega-corporation (which is not such a bad thing) and as such have limited resources (ok, that's not so great). As with any company operating under limited resources, we have to balance how we provide service and support to our customers. We have thousands of customers and deal with hundreds of requests every week. Needless to say even continually adding new resources to our support team, it makes providing the level of service we aim for, to every one of our customers, problematic at best.
If you're finding you're not getting responses to your requests, there are a few things you can do to ensure the quickest responses and a resolution to your request(s).
Give us the benefit of the doubt.
We want to help everyone we can. Trust us when we say that. We mean it.
No guarantees
We provide free support resources such as the documentation and community forums because we cannot guarantee interactive support to everyone - no matter how much we want to.
Where to ask for help
Community forums, community answers - use the Help Desk for customer service and official support.
How To Ask For Help
Be specific.
Be patient.
Be polite.
1. Give us the benefit of the doubt.
By that I mean, please believe that we have a sincere desire to help you and act that way when making your requests. We don't like letting anyone slip through the cracks. We don't want anyone to have problems for that matter. We try to build perfect software, knowing that we are not perfect, and it will be used in imperfect environments. Not getting your requests answered doesn't mean we're trying to make our money and run. Give us a fair chance, and do yourself a favor by following the guidelines outlined here to ensure your request gets answered promptly and accurately.
2. No guarantees
When people mention "support" most people are referring to interactive support via email, forums/ticketing systems or phone. We've posted this in our official documentation for Shopp, but strictly speaking Ingenesis Limited (the company behind Shopp development and support) cannot guarantee "free" official interactive support in all circumstances. We've established a community forum and written extensive documentation (over 100+ articles) in our wiki to provide "free support" resources. We maintain them and constantly make improvements to provide as much self-service support as possible. Often times, interactive support from the official team is ultimately necessary and we try to accommodate as many valid and reasonable requests that we can.
Many people incorrectly assume that because they pay for Shopp they are entitled to support. Buying Shopp brings you into a community with an ethic of support, but does not buy you support itself. Without getting into too many specifics about the fee, it is a distribution fee, or an access fee the gives you access to the wealth of resources for building kick-butt e-commerce sites. To re-iterate, we make no claims to guarantee "free" interactive support for every single request that we receive.
3. Where to ask for help
Our support forums provide a channel to get help from other Shopp users - the public community forums - and is also home to the official interactive support Help Desk. If you are looking for an answer your question from anyone familiar with Shopp, try the community forums. This is perfect for asking how to do XYZ with Shopp's APIs, or discussing new features you'd like to see. Some of our official support team answer questions in the public forums, but we cannot guarantee official answers to every single topic posted - we simply do not have the resources for the volume of discussion happening there.
If you have problems with purchases on the Shopp Store or logging into your account, post a customer service question on the Help Desk. Purchase problems, problems with your update keys, or account login issues should always use the Help Desk.
If you're having problems installing or using Shopp and you're just not getting any answers from the documentation or the community forums or your "How to do XYZ" question isn't getting picked up by the community you might try posting to the Help Desk - but be sure to include all relevant information for the your issue (see below)!
4. How To Ask For Help
You've searched the documentation... (you have searchedthe documentation haven't you?) You've combed the forums, and maybe even posted a few times with no answers. So you're going to ask for some official help... When asking for help from Shopp Support (and even the community at large), we have three guidlines that when followed will pretty much ensure you get a response:
Be specific.
Be patient.
Be polite.
Be specific.
When asking for help, it isn't the loudest squeaky wheel that gets the grease - first and foremost it's the post that has the most detailed information. The number one thing you can do is help to clarify your issue or request with some basic leg work for what you expected to happen, what is actually happening, what you did to make it happen and some details about the hosting setup you're trying to make it happen in:
What version of WordPress are you using?
What version of Shopp?
What plugins do you have installed?
What theme are you using?
If you know it, include the version of PHP, MySQL and web server (Apache or IIS) on your web host. If you don't know those, at least include the name and a URL to your web hosting provider.
Troubleshooting an issue? Include any and all error messages you can find... check the log files, even try Shopp Error Logging.
Trying to figure out how to do something? Be as clear and as specific as you can about what you are trying to accomplish.
Done right, this saves gobs and gobs of time, prevents lots of un-necessary back-and-forth and delays in follow-up. Don't want to do the leg work because it takes too much time? Get ready for delays. The time gets eaten up somewhere, by somebody. If you want your questions to be answered by us in a timely fashion, do some basic legwork and be specific!
Be patient.
Otherwise known as "be reasonable". Even under the best of circumstances, getting requests responded to and resolved takes time. With the volume of requests we receive, you should safely assume you may not see a response for at least 24-hours, possibly more. We are generally available doing support for 8 hours every workday from 9 AM to 5 PM EST (-5 UTC). We don't typically respond to requests over the weekend. That means, if you post on Friday evening after 5 PM EST (3 PM PST or Midnight in the UK) you'll be waiting until 9 AM the following Monday before someone likely even sees your issue (6 AM PST or 2 PM in the UK). Resolving your issues completely depends on the circumstances of the request, so we can't make any guarantees of a successful resolution in every situation.
Troubleshooting issues that lack enough details require us to ask for more information, and that can cause delays in resolution with the back-and-forth required to get all the information needed to solve the problem.
How-To questions that aren't specific enough (insufficient specs) may not see any response at all. We simply can't spend valuable support resource time on divination magic, reading tea leaves or mind reading over hundreds or thousands of miles to figure out what you're actually asking for. (That would be a way cool time-saver though!) Even then, if the how-to is in the documentation or on the forums, are we to be a human Google service for everyone that didn't search the documentation or forums ahead of time? Be reasonable.
Be polite.
This is really a duplicate of our opening plea, "give us the benefit of the doubt". It's important enough to repeat as the underlining guideline to follow in all communication with us. Being rude, demanding, entitled, mean will not solicit a faster response and has the opposite effect on our entire team's inclination to help out.
Keep in mind that providing support at any level is very costly. There are times when people will take advantage of support resources. However unintentional this may or may not be (we give you the benefit of the doubt you're not trying to), it causes an unnecessary drain on support resources - that means taking support resources away from someone else.
The Black Hole of Support
Finally, to illustrate how this all plays out, here's a scenario that demonstrates the cost (and value) of the support we can and do try to provide:
A customer posted on our Help Desk with a problem activating Shopp. They were getting a blank page when trying to activate, no errors immediately visible. After a follow-up asking for more details (errors from the logs) the customer did some digging and found a few errors while activating. It eventually escalated to the customer posting a support plea on Twitter because of the follow-up delays. Responding to the plea for help, and taking personal ownership I investigated the problem. The errors were new, never seen or reported by anyone else. I asked for temporary access to the site via WordPress admin and FTP to get enough access to conclusively solve the problem. After playing around, for about 15 minutes I was finally able to discover that Shopp could be activated with all the other plugins deactivated, pointing to a plugin conflict. Selectively activating and attempting to reactivate Shopp quickly revealed the culprit. After thorough analysis of the offending plugin's code I uncovered a bug that caused a cascade of errors further down the execution stack that triggered the error in Shopp, keeping it from being able to activate.
The cost to us and other Shopp customers in this situation is enormous and much higher than I think any of our customers would give us credit for.
If an error occurs in our plugin because of poor coding in another plugin the end-user (you) have no way of knowing otherwise and claim it is a problem in Shopp. Because we care, and want to support our customers to show we build a good product, in good faith we do all the legwork of research to track down the issue only to find that the issue is caused by an honest (albeit novice) mistake in another plugin.
The reason a situation like this is costly is first and foremost from a perceived loss of reputation. Shopp get's a bad rap for another plugin's issue. Secondly, from desperately public pleas. People that need support, usually need it "now", and when desperate tend to use any channel of communcation they can find to get help. Putting a plea for an issue like this on a social network like Twitter makes it look like we don't support our customers and have to be prodded in order to get any help - even for an issue that is not ours. Finally, the time it takes to research (recreate the error), analyze (find the cause), fix (code the solution) and respond eats up the time and resources we have to spend on improving the project for everyone's benefit. It also means other people have to wait longer for support to their issues. This costs everyone using Shopp not just us.
I don't cite this to vent our problems, but to illustrate the cost and effort we put into support. So, next time you have a problem that you're not getting a response to in as timely a manner as you'd like, you'll understand that there are lots of other requests we are juggling, some are valid (our fault) some are not. We still feel an obligation to handle all of them that we can.
Support Through Twitter
For our customers using Twitter @shopplugin mentions to prompt us for support, please bear in mind that we are not going to use Twitter mentions to do back-and-forth support correspondence. This might, however, be a good way to raise our attention to your issue on our support forums, so that we might address it there.
Please at a minimum include a link to the issue in your Tweet, as it may be difficult or impossible to locate the issue you are referring to otherwise.
I believe from a customers point of view if you pay for a product that makes certain claims it should ultimately be able to do what it claims.. If it does not, then it is not the customers fault and the provider of that product should be responsible for the product working as they claim it will otherwise don't sell the product. It's really that simple..
Being that Wordpress is an open source software with millions of potential combinations of plugins written by hundreds of developers I would imagine it would be quite a chore to take on that sort of support. That being said I believe that is one reason the majority of developers choose to release their plugins as free open-source plugins because they understand they can't possibly offer that sort of support.
Lack of decent customer service across the board with companies these days has made many a bitter customer..
The Sales Policy also states you're not buying support. The GPLv3 license page on this website will give you more info on paying for 'free' software. Especially the "Selling Free Software" link on top of the page is interesting.
There's even more info on it in the FAQs and on the About Shopp page.
As you can see, the information above (about not paying for support) has already been stated on this website (the Shopp site, forums and doc's) on several places.
I sincerely find that the support has been A1 since the start.
When the plugin says it do something it does.
In many situation I had to deal with plugin conflict (no shopp involved) just two random plugin not coping with each other. I scratched my head and dealt with other peoples feedback on similar issues to then posted those issues showing that this problem exist. Thus giving some time back based on my experience to other people that gave their time for us.
Some people just want everything for for free with no sweat. Eating big and getting fat. Eating big and exercising helps to keep a good balance. You pay little and get so much more in the end. Share your problems and solutions for others to find the same issue and get helped.
The guys behind shopp are creating a monster of a program with tons of variable and limitations. And when you add a few other poorly coded plugin (like I could do) then it all breaks. They're program is fully tested on a normal setup. If you're going to do fancy stuff just deal with the facts that the more problem will arise that they never saw. It's easy in the end, simple math...
Sincerely I think the guys do a great job at helping out their clients on their plugin. More and more people are seeing a great potential for shopp and are buying in, thus creating an exponential amount of posts, they hired a couple people (or only one) to help out, they have people that test stuff, help out in the forums and all for free (maybe a candy sometimes) but a great community is the based off a solid product and its here.
If you want good support help out some people with stuff you know and you'll see that a better one will come by and help you when you will need some help.
Most importantly: Before posting your problem do a couple of search on the forums... 90% of the time the answer is there....
From a customer's point of view you are correct. I also believe that a product paid for that does not do what it says should be supported. We have been responsive to hundreds of bug reports and resolved them because the product is not doing what it was supposed to do. We even go to extra lengths of building inter-release patches for those affected by known issues.
Admittedly, the nuance of buying access to a project rather than buying a product is a confusing sales proposition and leads to a great deal of misconceptions and assumptions. Even with that, we're not trying to slyly sidestep responsibility. My original post even details that we go way out of our way to provide support on issues that are not caused by anything we've done or not done. Shopp operates in a "shared environment" because it uses the same resource space in both PHP and JavaScript with however many other plugins our customers may have activated. Due to technical reasons (lack of PHP/JavaScript namespace support as one example) we simply cannot ensure that 100% of the time a badly coded plugin (that works in its own right) will not break something that Shopp does.
The best metaphor I can come up with is a company that has a large cubical farm office with cramped workers in somewhat close proximity to one another: employers are expected to maintain a safe working environment, but if one or a couple workers has a bug (an illness), there is no way the employer could make any guarantees that any other given worker won't be affected by the bug. That's operating in a shared resource environment. In the real world, you could tell those workers not to come in (akin to deactivating a plugin), and that would keep the others from being affected. Unfortunately, we're not the employer in this circumstance. Our customers are. And you're making it sound as if a customer employing a worker (Shopp) expects that worker to work all the time around other bug-infected workers and just keep working perfectly all the time, regardless of keeping the other bug-infected workers working. Sorry, sounds a little Dr. Seuss in there... And if that worker doesn't work, it's not their (the customer/employer)'s fault, it's the worker's and our responsibility to support them because it's the customers perspective that:
...if you pay for a product that makes certain claims it should ultimately be able to do what it claims.. If it does not, then it is not the customers fault... It's really that simple.
Therein lies the problem, it's not really that simple - and that is one of the impetuses of my original posting. To explain the sorts of issues like this that we are coping with. What happens now is that we do as much, if not more support for people running into those sorts of conflicts (not our fault problems) that it prevents us from supporting the people who are having "real" problems (our fault problems).
All we're asking for is some customer understanding, patience, and some footwork ahead of time to make support better for everyone. That seems reasonable enough doesn't it?
Good conversation, please keep it going as it only helps others to more fully understand and helps me to further clarify the nuances of these problems.
Adam and Jon have personally helped me out. It took a few days, honestly it got REALLY close to a roll-out, but when I really needed them before the product/site roll-out, they were available.
It's also true that there are quite a few answers in the forums, worth trolling and searching first.
Obviously, there will be things that required Ingenesis' attention. The truth that any Wordpress developer soon begins to realize is that there are SO MANY plug-ins out there, it's impossible for any developer to develop something foolproof. Also, with shopping cart software - there are so many payment processors who also change how they do things and add features.
So far, I've had the least conflicts with Shopp over competing products and plan to stick it out with the team at Ingenesis as they grow and we continue with Wordpress based e-commerce.
I was finding customer support to be excellent up till the moment I asked why there was no meta tags option for products even through the features page states:
"Search engine optimized shopping pages (product name and category in the title, semantic markup, alt/title attributes set, <meta> keywords/description)"
I have been giving the benefit of a doubt and waiting for some kind of an answer. I still want to use the plugin if it has this feature. However, I have received no response as to why I cannot find a feature that is mentioned on the site as part of the plugin.
It really should not be very difficult to add two additional meta fields to the products page, especially when the plugin claims to have SEO optimized shopping pages with meta tags.
Updated to latest 2.8.6 version of WP and updated to 1.0.16 of Shopp.
After an item is added to the shopping cart, and then click on the remove, the item is remove but does not refresh? Is it suppose too refresh? Also when I add another item, the previous deleted item still appears and the new item does not?
Thanks for the informative post, all good and valid points.
But if you've followed the directions and posted legitimate, polite questions to the Help Desk, and get no reply for 5 or 6 days - what are you to do?
I'm not referring to "how do I?" or setup questions. These are concerns about patches that were supposed to be in the latest versions and missing (causing shipping address to be un-usable), permissions problems (causing admin to be unusable for fulfilling orders), things that I would generally hope and think you would have some concern for.
We all realize that patience is required, but 5 days is an eternity when you've got a client with a store that's not working right and you sprang for the developer license.
I really want this to work, and will continue to try and help others with problems that I might have an answer to, so that I might generate enough good forum karma to get a response.
Your customer service model is completely logical for the type of company that you are. To paraphrase, "We don't have the resources to provide full tech support but we'll do the best we can." I have no doubt that you value your customers and want to help us as much as possible.
But in practice, providing support at your convenience for some requests but not all is the same policy used by companies that don't give a shit about their customers.
Again, I don't doubt that you care about us and you're trying your best. But from my perspective as a customer, that's just what it feels like.
Frankly, you need to do a better job of managing expectations. The "no guarantees" policy is not a viable middle ground between guaranteed support (even if it's paid) and no support whatsoever. By dangling the prospect of support, you make us feel like we're going to get it. And when we don't, it sucks.
Also, the implication in the last paragraph of Jonathan's initial post in this thread is that some requests are "invalid". Ignoring questions that are obvious or have already been answered is not the attitude of company that provides good customer service. In response to your "The Black Hole of Support" scenario, I'll offer this one that happened to me when I was installing a RAM upgrade.
Me: "I inserted the memory into the slot but the computer isn't recognizing it."
Tech Support: "Try pushing it in harder. Sometimes it takes a lot of force."
Me (feeling like a complete idiot): "That worked. Sorry to waste your time."
Tech Support: "It's not a problem. Is there anything else I can help you with?"
That's what I'm talking about! If you offer customer service, you need to offer real customer service - even it it isn't free.
But in practice, providing support at your convenience for some requests but not all is the same policy used by companies that don't give a shit about their customers.
I can certainly understand this mind-frame, but I have to disagree. Just because we feel that valid requests should be answered before requests that are really unreasonable does not mean we don't "care" about our customers. For reference so you don't have to scroll all the way back up, here is what my paragraph stated:
I don't cite this to vent our problems, but to illustrate the cost and effort we put into support. So, next time you have a problem that you're not getting a response to in as timely a manner as you'd like, you'll understand that there are lots of other requests we are juggling, some are valid (our fault) some are not. We still feel an obligation to handle all of them that we can.
Keep in mind that "valid requests" in the context I was speaking of them in that paragraph refers to "our fault problems" as opposed to "not our fault" problems.
"The Black Hole of Support" scenario demonstrates that we still provide support for these "not our fault" requests. And although the scenario doesn't include a full transcript of conversations, we did solve the issue on our dime and afterwards offer to help with other issues.
Frankly, you need to do a better job of managing expectations. The "no guarantees" policy is not a viable middle ground between guaranteed support (even if it's paid) and no support whatsoever.
Your post implicates that you understand that we say we care about our customers, but the policies we've adopted mean we really don't. This is what I primarily disagree with, though I can understand why you might think of it that way.
It is the reason behind my initial post in this topic, to help better set expectations.
The central problem at issue here is priority. Which requests do you (as our customer) think should get answered when it is impossible to answer every single one?
If I were to answer that for our customers I would say the answer is always "you should answer mine, all others be damned". Now that is a crass generalization, but a good number of requests are linked to statements like, "my client wants to launch tomorrow, and I'm just now getting around to this, so if you could answer this today I'd appreciate it". No where do these type of requests imply "I know you're busy with lots of other people". This is where we tend to see a sense of "entitlement" for support, regardless of whether the issue is our fault or not. Does a question like that get answered before one like, "This store is live and Shopp isn't calculating taxes correctly!! Help!"
Just because we have to prioritize "our fault" requests over "not our fault" requests, doesn't mean we don't answer any "not our fault" requests at all. The "Black Hole" scenario even demonstrates this.
We do, however, have to work with an arbitrary threshold of which requests of the "not our fault" nature get answered and which ones don't. My initial posting details how to correctly ask questions that will get noticed by us. So even if the request is a "not our fault" issue, the customer providing more detailed information up front is more likely to get a response over a generic "loaded" question. Less time is spent on back and forth, giving us more time to handle more requests regardless of if they are "our fault" issues or not.
That doesn't sound like we don't care about our customers. To me it's the exact opposite. We care about all our customers and we are trying to find ways to streamline and be as efficient as we can so that we can help more people.
Being demanding about when we are supposed to respond to your request for free support is a bit like cutting in line. Do you want others cutting in line in front of your questions?
Inevitably, we have customers that don't read this topic, or they do read it and still can't synthesize what it means to provide all the information we need when making their request (despite my nice little outline above), or they just don't care. So we run into requests like, "My client wants file uploads at checkout, how do I do that?" Shopp doesn't do this out of the box, and it's a feature we've looked at adding but right now it simply isn't "done for you" but Shopp's architecture is such that anyone with decent development knowledge could do this today. In spite of that though, a question like this is what we call a "loaded question". What often happens is that we try and point people in the right direction to get them started developing it only to have them continue to prod us for "example code" that they inevitably just plug into their project to make their client happy. Requests like this are often further loaded with an additional request, "I'm supposed to launch this site tomorrow, so please answer this as soon as possible". It is this type of scenario that prompted me to write this topic to begin with. Managing requests like this take the vast majority of our support time in the back-and-forth of customers trying to psychologically manipulate us into doing their work for them. Worse yet, it keeps us from being able to answer reasonable "not our fault" requests. This is fully addressed in the "Be polite." (aka Be reasonable) section of my initial post.
So what it comes down to is that when we can't answer every single request that comes in, we have to cut off free support somewhere, and that comes down to finding issues that simply aren't reasonable requests not "invalid", and regardless of "not our fault" issues. They are the issues where they're asking for too much, aren't providing any (or enough) helpful details, or are making a plea/demand for an immediate response. When we say "no" to those type of issues, it allows us to answer more requests overall. It completely illustrates that we do care about all our customers and that our policies are designed to allow us to help as many as possible with limited resources.
So, if we have to let some issues go unanswered because of lack of resources, the ones that don't get answered are the ones that aren't our fault where there isn't enough information to answer or know the right follow-up to ask, or are so loaded that they aren't reasonable to begin with.
We having been kicking around paid support as a way of providing "guaranteed responses". We can't guarantee a solution, because it simply is not possible. We can guarantee responsiveness. One potential outcome with this though, is that people will begin abusing paid support as a way to pay to get a response without doing any legwork. Hopefully, that means we'll be able to afford more resources. But I have no doubt that it will make our threshold for the kind of issues we can't answer in free support that much higher. It becomes a way of paying to cut in line. If this is something the community wants, we'll offer it sooner rather than later, but right now we're still trying to refine our support workflow so we have a system that will bear the additional load, and even provide an infrastructure to better pay our support team. Anyone interested in getting paid for Shopp support (leave a message on the Help Desk).
Finally, if you see issues with our approach, I'm happy to continue discussing it, which is why I've encouraged responses to this topic. It's a great conversation and the support problem is one I am both intellectually intrigued by and have obvious reasons to want to get solved.
So thanks for posting and being thoughtful about your remarks despite my disagreeing with what you've said. It has again helped me clarify our position and reiterate how we're trying to design ways of helping as many people as possible.
I personally think that the support for Shopp has been excellent, and both Adam and Jon have also helped me out when needed.
It's perfectly reasonable to ask customers to read the documentation, try deactivating other plugins to look for conflict, and search for similar issues in the forums, before contacting the help desk, and then be polite and realistic in terms of timeframe for the issue to be resolved.
Also it is only fair that issues that are directly related to bugs in the plugin take priority over issues that might be due to the customer's theme, other plugins, customisation, etc, or "How do I do this" questions.
However if someone has posted a support request on the help desk which is "unreasonable" or does not have enough information, rather than just ignoring it, it would probably be more customer friendly to respond, even if it's just with a standard message advising that more information is needed, that it's not a Shopp issue, or even to refer them to this post or the forums.
That way the customer would feel their query has been acknowledged.
I think Paid Support could be an option if The Shopp Team havent got the resources to be able to do this.
Personally I will stick with Shopp as I think it's the best E-commerce solution for Wordpress out there, and as far as I am concerned so far the support has been above board.
In any case the support has been 200% better than other similar E-commerce plugins I have purchased in the past, which I found very buggy with nearly non-existent support, even for plugin related issues.
Thanks for the support of what we're doing. And you are quite right to point out we need to at least have a quick response requesting more information when applicable. Our re-structure of the Help Desk system recently will allow us to be more responsive in this regard.
Think about it like a retailer; I'll take bike shops as an example because I've worked in plenty of them. In Bike Shop #1, entry-level riders who don't know how to fix a flat tire have a frustrating experience compared to hardcore bike enthusiasts with more complicated questions. In Bike Shop #2, everyone is treated the same.
It's not that the employees at Bike Shop #1 are mean. Rather, the culture of the shop is dismissive of people with questions that are obvious to the employees whose lives revolve around bikes. But most people who buy bicycles aren't serious enthusiasts. If Bike Shop #1 is the only game in town, it doesn't matter. If there's competition, Bike Shop #1 will lose lots of customers to Bike Shop #2.
I think it's a decent analogy to your business, where most WordPress users are the kind of people who might need some hand-holding with questions that seem simple to you.
So I guess it ultimately comes down to what kind of business you want to run. Shopp is a fantastic product, clearly the best available shopping cart for WordPress. But there's nothing proprietary. It's possible that someone else could build a comparable product and offer guaranteed, timely support even for "not our fault" questions. That's the Bike Shop #2 approach and, in my experience, it's a lot more profitable.
I read not all of the posts in this thread - but many of them.
And I totally agree to kadisko's bike shop examples and his statement!
But let me suggest a kind of service and / or business model:
As far as I know Automattic (the makers / founders of WordPress) offer commercial support plans with their Automattic Support Network at enterprise level.
Many other developers and makers of OSS are offering similar models to benefit from their own software development, many of them are successful with their models.
Why not doing the same?
You (Jonathan & his crew) are offering a piece of software, which is (from the shopplugin customers point of view) intentionally made to set up a money making webshop, in which a webshop again is intentionally set up by the shopplugin customers to receive revenue.
For me it in fact is a very fair condition to buy a licence for just U$55. And for me it would also be fair to pay, i.e. an optional monthly or annual support fee, or maybe a fee based on the number of tickets.
This shouldn't be a problem for shopp-customers whose intention using shopplugin is making money with a webshop
[edited] ... should also no problem for developers who are delivering payed software implementation services to their customers ...
There are many more advantages of "commercial services for free and opensource software":
software quality - because the developers can spend more time enhancing and refining the software
service quality - cause the supporters can spend more time taking care of customer needs, requests and tickets
software lifecycle / lifetime - the more professional the software will be, the longer the software will live
Think about implementing some fair and optional "premium support" models - especially for those who are the typcial WordPress users without much programming experiences, and some other models for developers (and theme developers) as well.
Cheers, I finished my beer and it's bedtime ...
Ralf.
.. just an example in addition to my previous posting:
We have sofware company in Germany "oxid esales". They offer a very professional and high quality web shop software at enterprise level, called "oxid esales".
The software is commercial - a "Professional Edition" licence costs about 1990 Euros plus VAT, a support contract is mandatory and it costs about 39 Euros a month (per one named contact person).
But 1.5 years ago they published the free "community edition" - which is free and OpenSource. There is no difference between the professional licence and the community edition except the support models.
For the professional edition you pay 39 Euro a month to get professional support and high responsiveness.
For the free & OpenSource community edition of oxid esales you have two options:
- the free community driven forums
- or you get professional prepaid support, price depends either on time talking to the professional supporters (i.e. 40Euros per 15 minutes), or on an incident base.
They have a very huge and very satisfied customer base - the company now employs more staff then before they published the opensource version ...
I just purchased shoppe and was trying to install it. I am working in WP 2.9.1 and each time I try to activate the plugin after the upload I get the message "The plugin does not have a valid header."
I believe my hosting company works well with the requirements (dreamhost). I also have the unique IP and a certificate for the domain. Any help would be LOVED!
I read through this file diligently and submitted a help request with all the info requested, error message etc. but I didn't hear back, and I can't find anywhere we can check our own submitted tickets. I'm sure it's just me missing something, so please can you point me in the right direction so I can submit a ticket properly?
sticky
How To Get Support
Profile
So, you've posted to the Shopp support forums and you aren't getting any help... What gives? And what do you do about it?
First, please understand we sincerely want you to get the help you need. However, we are not a mega-corporation (which is not such a bad thing) and as such have limited resources (ok, that's not so great). As with any company operating under limited resources, we have to balance how we provide service and support to our customers. We have thousands of customers and deal with hundreds of requests every week. Needless to say even continually adding new resources to our support team, it makes providing the level of service we aim for, to every one of our customers, problematic at best.
If you're finding you're not getting responses to your requests, there are a few things you can do to ensure the quickest responses and a resolution to your request(s).
1. Give us the benefit of the doubt.
By that I mean, please believe that we have a sincere desire to help you and act that way when making your requests. We don't like letting anyone slip through the cracks. We don't want anyone to have problems for that matter. We try to build perfect software, knowing that we are not perfect, and it will be used in imperfect environments. Not getting your requests answered doesn't mean we're trying to make our money and run. Give us a fair chance, and do yourself a favor by following the guidelines outlined here to ensure your request gets answered promptly and accurately.
2. No guarantees
When people mention "support" most people are referring to interactive support via email, forums/ticketing systems or phone. We've posted this in our official documentation for Shopp, but strictly speaking Ingenesis Limited (the company behind Shopp development and support) cannot guarantee "free" official interactive support in all circumstances. We've established a community forum and written extensive documentation (over 100+ articles) in our wiki to provide "free support" resources. We maintain them and constantly make improvements to provide as much self-service support as possible. Often times, interactive support from the official team is ultimately necessary and we try to accommodate as many valid and reasonable requests that we can.
Many people incorrectly assume that because they pay for Shopp they are entitled to support. Buying Shopp brings you into a community with an ethic of support, but does not buy you support itself. Without getting into too many specifics about the fee, it is a distribution fee, or an access fee the gives you access to the wealth of resources for building kick-butt e-commerce sites. To re-iterate, we make no claims to guarantee "free" interactive support for every single request that we receive.
3. Where to ask for help
Our support forums provide a channel to get help from other Shopp users - the public community forums - and is also home to the official interactive support Help Desk. If you are looking for an answer your question from anyone familiar with Shopp, try the community forums. This is perfect for asking how to do XYZ with Shopp's APIs, or discussing new features you'd like to see. Some of our official support team answer questions in the public forums, but we cannot guarantee official answers to every single topic posted - we simply do not have the resources for the volume of discussion happening there.
If you have problems with purchases on the Shopp Store or logging into your account, post a customer service question on the Help Desk. Purchase problems, problems with your update keys, or account login issues should always use the Help Desk.
If you're having problems installing or using Shopp and you're just not getting any answers from the documentation or the community forums or your "How to do XYZ" question isn't getting picked up by the community you might try posting to the Help Desk - but be sure to include all relevant information for the your issue (see below)!
4. How To Ask For Help
You've searched the documentation... (you have searched the documentation haven't you?) You've combed the forums, and maybe even posted a few times with no answers. So you're going to ask for some official help... When asking for help from Shopp Support (and even the community at large), we have three guidlines that when followed will pretty much ensure you get a response:
Be specific.
When asking for help, it isn't the loudest squeaky wheel that gets the grease - first and foremost it's the post that has the most detailed information. The number one thing you can do is help to clarify your issue or request with some basic leg work for what you expected to happen, what is actually happening, what you did to make it happen and some details about the hosting setup you're trying to make it happen in:
Done right, this saves gobs and gobs of time, prevents lots of un-necessary back-and-forth and delays in follow-up. Don't want to do the leg work because it takes too much time? Get ready for delays. The time gets eaten up somewhere, by somebody. If you want your questions to be answered by us in a timely fashion, do some basic legwork and be specific!
Be patient.
Otherwise known as "be reasonable". Even under the best of circumstances, getting requests responded to and resolved takes time. With the volume of requests we receive, you should safely assume you may not see a response for at least 24-hours, possibly more. We are generally available doing support for 8 hours every workday from 9 AM to 5 PM EST (-5 UTC). We don't typically respond to requests over the weekend. That means, if you post on Friday evening after 5 PM EST (3 PM PST or Midnight in the UK) you'll be waiting until 9 AM the following Monday before someone likely even sees your issue (6 AM PST or 2 PM in the UK). Resolving your issues completely depends on the circumstances of the request, so we can't make any guarantees of a successful resolution in every situation.
Troubleshooting issues that lack enough details require us to ask for more information, and that can cause delays in resolution with the back-and-forth required to get all the information needed to solve the problem.
How-To questions that aren't specific enough (insufficient specs) may not see any response at all. We simply can't spend valuable support resource time on divination magic, reading tea leaves or mind reading over hundreds or thousands of miles to figure out what you're actually asking for. (That would be a way cool time-saver though!) Even then, if the how-to is in the documentation or on the forums, are we to be a human Google service for everyone that didn't search the documentation or forums ahead of time? Be reasonable.
Be polite.
This is really a duplicate of our opening plea, "give us the benefit of the doubt". It's important enough to repeat as the underlining guideline to follow in all communication with us. Being rude, demanding, entitled, mean will not solicit a faster response and has the opposite effect on our entire team's inclination to help out.
Keep in mind that providing support at any level is very costly. There are times when people will take advantage of support resources. However unintentional this may or may not be (we give you the benefit of the doubt you're not trying to), it causes an unnecessary drain on support resources - that means taking support resources away from someone else.
The Black Hole of Support
Finally, to illustrate how this all plays out, here's a scenario that demonstrates the cost (and value) of the support we can and do try to provide:
A customer posted on our Help Desk with a problem activating Shopp. They were getting a blank page when trying to activate, no errors immediately visible. After a follow-up asking for more details (errors from the logs) the customer did some digging and found a few errors while activating. It eventually escalated to the customer posting a support plea on Twitter because of the follow-up delays. Responding to the plea for help, and taking personal ownership I investigated the problem. The errors were new, never seen or reported by anyone else. I asked for temporary access to the site via WordPress admin and FTP to get enough access to conclusively solve the problem. After playing around, for about 15 minutes I was finally able to discover that Shopp could be activated with all the other plugins deactivated, pointing to a plugin conflict. Selectively activating and attempting to reactivate Shopp quickly revealed the culprit. After thorough analysis of the offending plugin's code I uncovered a bug that caused a cascade of errors further down the execution stack that triggered the error in Shopp, keeping it from being able to activate.
The cost to us and other Shopp customers in this situation is enormous and much higher than I think any of our customers would give us credit for.
If an error occurs in our plugin because of poor coding in another plugin the end-user (you) have no way of knowing otherwise and claim it is a problem in Shopp. Because we care, and want to support our customers to show we build a good product, in good faith we do all the legwork of research to track down the issue only to find that the issue is caused by an honest (albeit novice) mistake in another plugin.
The reason a situation like this is costly is first and foremost from a perceived loss of reputation. Shopp get's a bad rap for another plugin's issue. Secondly, from desperately public pleas. People that need support, usually need it "now", and when desperate tend to use any channel of communcation they can find to get help. Putting a plea for an issue like this on a social network like Twitter makes it look like we don't support our customers and have to be prodded in order to get any help - even for an issue that is not ours. Finally, the time it takes to research (recreate the error), analyze (find the cause), fix (code the solution) and respond eats up the time and resources we have to spend on improving the project for everyone's benefit. It also means other people have to wait longer for support to their issues. This costs everyone using Shopp not just us.
I don't cite this to vent our problems, but to illustrate the cost and effort we put into support. So, next time you have a problem that you're not getting a response to in as timely a manner as you'd like, you'll understand that there are lots of other requests we are juggling, some are valid (our fault) some are not. We still feel an obligation to handle all of them that we can.
Support Through Twitter
For our customers using Twitter @shopplugin mentions to prompt us for support, please bear in mind that we are not going to use Twitter mentions to do back-and-forth support correspondence. This might, however, be a good way to raise our attention to your issue on our support forums, so that we might address it there.
Please at a minimum include a link to the issue in your Tweet, as it may be difficult or impossible to locate the issue you are referring to otherwise.
Profile
I believe from a customers point of view if you pay for a product that makes certain claims it should ultimately be able to do what it claims.. If it does not, then it is not the customers fault and the provider of that product should be responsible for the product working as they claim it will otherwise don't sell the product. It's really that simple..
Being that Wordpress is an open source software with millions of potential combinations of plugins written by hundreds of developers I would imagine it would be quite a chore to take on that sort of support. That being said I believe that is one reason the majority of developers choose to release their plugins as free open-source plugins because they understand they can't possibly offer that sort of support.
Lack of decent customer service across the board with companies these days has made many a bitter customer..
Profile
The Sales Policy also states you're not buying support. The GPLv3 license page on this website will give you more info on paying for 'free' software. Especially the "Selling Free Software" link on top of the page is interesting.
There's even more info on it in the FAQs and on the About Shopp page.
As you can see, the information above (about not paying for support) has already been stated on this website (the Shopp site, forums and doc's) on several places.
Profile
I sincerely find that the support has been A1 since the start.
When the plugin says it do something it does.
In many situation I had to deal with plugin conflict (no shopp involved) just two random plugin not coping with each other. I scratched my head and dealt with other peoples feedback on similar issues to then posted those issues showing that this problem exist. Thus giving some time back based on my experience to other people that gave their time for us.
Some people just want everything for for free with no sweat. Eating big and getting fat. Eating big and exercising helps to keep a good balance. You pay little and get so much more in the end. Share your problems and solutions for others to find the same issue and get helped.
The guys behind shopp are creating a monster of a program with tons of variable and limitations. And when you add a few other poorly coded plugin (like I could do) then it all breaks. They're program is fully tested on a normal setup. If you're going to do fancy stuff just deal with the facts that the more problem will arise that they never saw. It's easy in the end, simple math...
Sincerely I think the guys do a great job at helping out their clients on their plugin. More and more people are seeing a great potential for shopp and are buying in, thus creating an exponential amount of posts, they hired a couple people (or only one) to help out, they have people that test stuff, help out in the forums and all for free (maybe a candy sometimes) but a great community is the based off a solid product and its here.
If you want good support help out some people with stuff you know and you'll see that a better one will come by and help you when you will need some help.
Most importantly: Before posting your problem do a couple of search on the forums... 90% of the time the answer is there....
Profile
@JDenny:
From a customer's point of view you are correct. I also believe that a product paid for that does not do what it says should be supported. We have been responsive to hundreds of bug reports and resolved them because the product is not doing what it was supposed to do. We even go to extra lengths of building inter-release patches for those affected by known issues.
Admittedly, the nuance of buying access to a project rather than buying a product is a confusing sales proposition and leads to a great deal of misconceptions and assumptions. Even with that, we're not trying to slyly sidestep responsibility. My original post even details that we go way out of our way to provide support on issues that are not caused by anything we've done or not done. Shopp operates in a "shared environment" because it uses the same resource space in both PHP and JavaScript with however many other plugins our customers may have activated. Due to technical reasons (lack of PHP/JavaScript namespace support as one example) we simply cannot ensure that 100% of the time a badly coded plugin (that works in its own right) will not break something that Shopp does.
The best metaphor I can come up with is a company that has a large cubical farm office with cramped workers in somewhat close proximity to one another: employers are expected to maintain a safe working environment, but if one or a couple workers has a bug (an illness), there is no way the employer could make any guarantees that any other given worker won't be affected by the bug. That's operating in a shared resource environment. In the real world, you could tell those workers not to come in (akin to deactivating a plugin), and that would keep the others from being affected. Unfortunately, we're not the employer in this circumstance. Our customers are. And you're making it sound as if a customer employing a worker (Shopp) expects that worker to work all the time around other bug-infected workers and just keep working perfectly all the time, regardless of keeping the other bug-infected workers working. Sorry, sounds a little Dr. Seuss in there... And if that worker doesn't work, it's not their (the customer/employer)'s fault, it's the worker's and our responsibility to support them because it's the customers perspective that:
Therein lies the problem, it's not really that simple - and that is one of the impetuses of my original posting. To explain the sorts of issues like this that we are coping with. What happens now is that we do as much, if not more support for people running into those sorts of conflicts (not our fault problems) that it prevents us from supporting the people who are having "real" problems (our fault problems).
All we're asking for is some customer understanding, patience, and some footwork ahead of time to make support better for everyone. That seems reasonable enough doesn't it?
Good conversation, please keep it going as it only helps others to more fully understand and helps me to further clarify the nuances of these problems.
Profile
Adam and Jon have personally helped me out. It took a few days, honestly it got REALLY close to a roll-out, but when I really needed them before the product/site roll-out, they were available.
It's also true that there are quite a few answers in the forums, worth trolling and searching first.
Obviously, there will be things that required Ingenesis' attention. The truth that any Wordpress developer soon begins to realize is that there are SO MANY plug-ins out there, it's impossible for any developer to develop something foolproof. Also, with shopping cart software - there are so many payment processors who also change how they do things and add features.
So far, I've had the least conflicts with Shopp over competing products and plan to stick it out with the team at Ingenesis as they grow and we continue with Wordpress based e-commerce.
Profile
I was finding customer support to be excellent up till the moment I asked why there was no meta tags option for products even through the features page states:
"Search engine optimized shopping pages (product name and category in the title, semantic markup, alt/title attributes set, <meta> keywords/description)"
I have been giving the benefit of a doubt and waiting for some kind of an answer. I still want to use the plugin if it has this feature. However, I have received no response as to why I cannot find a feature that is mentioned on the site as part of the plugin.
It really should not be very difficult to add two additional meta fields to the products page, especially when the plugin claims to have SEO optimized shopping pages with meta tags.
Profile
@QAISER, please check your topic about that issue.
Profile
Thanks!!! Really appreciate your time.
Profile
Updated to latest 2.8.6 version of WP and updated to 1.0.16 of Shopp.
After an item is added to the shopping cart, and then click on the remove, the item is remove but does not refresh? Is it suppose too refresh? Also when I add another item, the previous deleted item still appears and the new item does not?
Suggestions???? Resolutions????
Profile
Please post a topic in the help desk so that we can work this out with you.
Profile
Thanks for the informative post, all good and valid points.
But if you've followed the directions and posted legitimate, polite questions to the Help Desk, and get no reply for 5 or 6 days - what are you to do?
I'm not referring to "how do I?" or setup questions. These are concerns about patches that were supposed to be in the latest versions and missing (causing shipping address to be un-usable), permissions problems (causing admin to be unusable for fulfilling orders), things that I would generally hope and think you would have some concern for.
We all realize that patience is required, but 5 days is an eternity when you've got a client with a store that's not working right and you sprang for the developer license.
I really want this to work, and will continue to try and help others with problems that I might have an answer to, so that I might generate enough good forum karma to get a response.
Profile
Dear Shopp:
Your customer service model is completely logical for the type of company that you are. To paraphrase, "We don't have the resources to provide full tech support but we'll do the best we can." I have no doubt that you value your customers and want to help us as much as possible.
But in practice, providing support at your convenience for some requests but not all is the same policy used by companies that don't give a shit about their customers.
Again, I don't doubt that you care about us and you're trying your best. But from my perspective as a customer, that's just what it feels like.
Frankly, you need to do a better job of managing expectations. The "no guarantees" policy is not a viable middle ground between guaranteed support (even if it's paid) and no support whatsoever. By dangling the prospect of support, you make us feel like we're going to get it. And when we don't, it sucks.
Also, the implication in the last paragraph of Jonathan's initial post in this thread is that some requests are "invalid". Ignoring questions that are obvious or have already been answered is not the attitude of company that provides good customer service. In response to your "The Black Hole of Support" scenario, I'll offer this one that happened to me when I was installing a RAM upgrade.
Me: "I inserted the memory into the slot but the computer isn't recognizing it."
Tech Support: "Try pushing it in harder. Sometimes it takes a lot of force."
Me (feeling like a complete idiot): "That worked. Sorry to waste your time."
Tech Support: "It's not a problem. Is there anything else I can help you with?"
That's what I'm talking about! If you offer customer service, you need to offer real customer service - even it it isn't free.
Please offer paid support!!
Profile
@kadisco:
I can certainly understand this mind-frame, but I have to disagree. Just because we feel that valid requests should be answered before requests that are really unreasonable does not mean we don't "care" about our customers. For reference so you don't have to scroll all the way back up, here is what my paragraph stated:
Keep in mind that "valid requests" in the context I was speaking of them in that paragraph refers to "our fault problems" as opposed to "not our fault" problems.
"The Black Hole of Support" scenario demonstrates that we still provide support for these "not our fault" requests. And although the scenario doesn't include a full transcript of conversations, we did solve the issue on our dime and afterwards offer to help with other issues.
Your post implicates that you understand that we say we care about our customers, but the policies we've adopted mean we really don't. This is what I primarily disagree with, though I can understand why you might think of it that way.
It is the reason behind my initial post in this topic, to help better set expectations.
The central problem at issue here is priority. Which requests do you (as our customer) think should get answered when it is impossible to answer every single one?
If I were to answer that for our customers I would say the answer is always "you should answer mine, all others be damned". Now that is a crass generalization, but a good number of requests are linked to statements like, "my client wants to launch tomorrow, and I'm just now getting around to this, so if you could answer this today I'd appreciate it". No where do these type of requests imply "I know you're busy with lots of other people". This is where we tend to see a sense of "entitlement" for support, regardless of whether the issue is our fault or not. Does a question like that get answered before one like, "This store is live and Shopp isn't calculating taxes correctly!! Help!"
Just because we have to prioritize "our fault" requests over "not our fault" requests, doesn't mean we don't answer any "not our fault" requests at all. The "Black Hole" scenario even demonstrates this.
We do, however, have to work with an arbitrary threshold of which requests of the "not our fault" nature get answered and which ones don't. My initial posting details how to correctly ask questions that will get noticed by us. So even if the request is a "not our fault" issue, the customer providing more detailed information up front is more likely to get a response over a generic "loaded" question. Less time is spent on back and forth, giving us more time to handle more requests regardless of if they are "our fault" issues or not.
That doesn't sound like we don't care about our customers. To me it's the exact opposite. We care about all our customers and we are trying to find ways to streamline and be as efficient as we can so that we can help more people.
Being demanding about when we are supposed to respond to your request for free support is a bit like cutting in line. Do you want others cutting in line in front of your questions?
Inevitably, we have customers that don't read this topic, or they do read it and still can't synthesize what it means to provide all the information we need when making their request (despite my nice little outline above), or they just don't care. So we run into requests like, "My client wants file uploads at checkout, how do I do that?" Shopp doesn't do this out of the box, and it's a feature we've looked at adding but right now it simply isn't "done for you" but Shopp's architecture is such that anyone with decent development knowledge could do this today. In spite of that though, a question like this is what we call a "loaded question". What often happens is that we try and point people in the right direction to get them started developing it only to have them continue to prod us for "example code" that they inevitably just plug into their project to make their client happy. Requests like this are often further loaded with an additional request, "I'm supposed to launch this site tomorrow, so please answer this as soon as possible". It is this type of scenario that prompted me to write this topic to begin with. Managing requests like this take the vast majority of our support time in the back-and-forth of customers trying to psychologically manipulate us into doing their work for them. Worse yet, it keeps us from being able to answer reasonable "not our fault" requests. This is fully addressed in the "Be polite." (aka Be reasonable) section of my initial post.
So what it comes down to is that when we can't answer every single request that comes in, we have to cut off free support somewhere, and that comes down to finding issues that simply aren't reasonable requests not "invalid", and regardless of "not our fault" issues. They are the issues where they're asking for too much, aren't providing any (or enough) helpful details, or are making a plea/demand for an immediate response. When we say "no" to those type of issues, it allows us to answer more requests overall. It completely illustrates that we do care about all our customers and that our policies are designed to allow us to help as many as possible with limited resources.
So, if we have to let some issues go unanswered because of lack of resources, the ones that don't get answered are the ones that aren't our fault where there isn't enough information to answer or know the right follow-up to ask, or are so loaded that they aren't reasonable to begin with.
We having been kicking around paid support as a way of providing "guaranteed responses". We can't guarantee a solution, because it simply is not possible. We can guarantee responsiveness. One potential outcome with this though, is that people will begin abusing paid support as a way to pay to get a response without doing any legwork. Hopefully, that means we'll be able to afford more resources. But I have no doubt that it will make our threshold for the kind of issues we can't answer in free support that much higher. It becomes a way of paying to cut in line. If this is something the community wants, we'll offer it sooner rather than later, but right now we're still trying to refine our support workflow so we have a system that will bear the additional load, and even provide an infrastructure to better pay our support team. Anyone interested in getting paid for Shopp support (leave a message on the Help Desk).
Finally, if you see issues with our approach, I'm happy to continue discussing it, which is why I've encouraged responses to this topic. It's a great conversation and the support problem is one I am both intellectually intrigued by and have obvious reasons to want to get solved.
So thanks for posting and being thoughtful about your remarks despite my disagreeing with what you've said. It has again helped me clarify our position and reiterate how we're trying to design ways of helping as many people as possible.
Profile
I personally think that the support for Shopp has been excellent, and both Adam and Jon have also helped me out when needed.
It's perfectly reasonable to ask customers to read the documentation, try deactivating other plugins to look for conflict, and search for similar issues in the forums, before contacting the help desk, and then be polite and realistic in terms of timeframe for the issue to be resolved.
Also it is only fair that issues that are directly related to bugs in the plugin take priority over issues that might be due to the customer's theme, other plugins, customisation, etc, or "How do I do this" questions.
However if someone has posted a support request on the help desk which is "unreasonable" or does not have enough information, rather than just ignoring it, it would probably be more customer friendly to respond, even if it's just with a standard message advising that more information is needed, that it's not a Shopp issue, or even to refer them to this post or the forums.
That way the customer would feel their query has been acknowledged.
I think Paid Support could be an option if The Shopp Team havent got the resources to be able to do this.
Personally I will stick with Shopp as I think it's the best E-commerce solution for Wordpress out there, and as far as I am concerned so far the support has been above board.
In any case the support has been 200% better than other similar E-commerce plugins I have purchased in the past, which I found very buggy with nearly non-existent support, even for plugin related issues.
Profile
Thanks for the support of what we're doing. And you are quite right to point out we need to at least have a quick response requesting more information when applicable. Our re-structure of the Help Desk system recently will allow us to be more responsive in this regard.
Profile
@Jonathan:
Think about it like a retailer; I'll take bike shops as an example because I've worked in plenty of them. In Bike Shop #1, entry-level riders who don't know how to fix a flat tire have a frustrating experience compared to hardcore bike enthusiasts with more complicated questions. In Bike Shop #2, everyone is treated the same.
It's not that the employees at Bike Shop #1 are mean. Rather, the culture of the shop is dismissive of people with questions that are obvious to the employees whose lives revolve around bikes. But most people who buy bicycles aren't serious enthusiasts. If Bike Shop #1 is the only game in town, it doesn't matter. If there's competition, Bike Shop #1 will lose lots of customers to Bike Shop #2.
I think it's a decent analogy to your business, where most WordPress users are the kind of people who might need some hand-holding with questions that seem simple to you.
So I guess it ultimately comes down to what kind of business you want to run. Shopp is a fantastic product, clearly the best available shopping cart for WordPress. But there's nothing proprietary. It's possible that someone else could build a comparable product and offer guaranteed, timely support even for "not our fault" questions. That's the Bike Shop #2 approach and, in my experience, it's a lot more profitable.
Profile
Hej there
I read not all of the posts in this thread - but many of them.
And I totally agree to kadisko's bike shop examples and his statement!
But let me suggest a kind of service and / or business model:
As far as I know Automattic (the makers / founders of WordPress) offer commercial support plans with their Automattic Support Network at enterprise level.
Many other developers and makers of OSS are offering similar models to benefit from their own software development, many of them are successful with their models.
Why not doing the same?
You (Jonathan & his crew) are offering a piece of software, which is (from the shopplugin customers point of view) intentionally made to set up a money making webshop, in which a webshop again is intentionally set up by the shopplugin customers to receive revenue.
For me it in fact is a very fair condition to buy a licence for just U$55. And for me it would also be fair to pay, i.e. an optional monthly or annual support fee, or maybe a fee based on the number of tickets.
This shouldn't be a problem for shopp-customers whose intention using shopplugin is making money with a webshop
[edited] ... should also no problem for developers who are delivering payed software implementation services to their customers ...
There are many more advantages of "commercial services for free and opensource software":
Think about implementing some fair and optional "premium support" models - especially for those who are the typcial WordPress users without much programming experiences, and some other models for developers (and theme developers) as well.
Cheers, I finished my beer and it's bedtime ...
Ralf.
Profile
.. just an example in addition to my previous posting:
We have sofware company in Germany "oxid esales". They offer a very professional and high quality web shop software at enterprise level, called "oxid esales".
The software is commercial - a "Professional Edition" licence costs about 1990 Euros plus VAT, a support contract is mandatory and it costs about 39 Euros a month (per one named contact person).
But 1.5 years ago they published the free "community edition" - which is free and OpenSource. There is no difference between the professional licence and the community edition except the support models.
For the professional edition you pay 39 Euro a month to get professional support and high responsiveness.
For the free & OpenSource community edition of oxid esales you have two options:
- the free community driven forums
- or you get professional prepaid support, price depends either on time talking to the professional supporters (i.e. 40Euros per 15 minutes), or on an incident base.
They have a very huge and very satisfied customer base - the company now employs more staff then before they published the opensource version ...
Cheers
Profile
I just purchased shoppe and was trying to install it. I am working in WP 2.9.1 and each time I try to activate the plugin after the upload I get the message "The plugin does not have a valid header."
I believe my hosting company works well with the requirements (dreamhost). I also have the unique IP and a certificate for the domain. Any help would be LOVED!
Thanks!!
Profile
Bobby,
This isn't really the place for support requests. See the Help Desk for official support requests, or ask on the other community forums.
John
Profile
I read through this file diligently and submitted a help request with all the info requested, error message etc. but I didn't hear back, and I can't find anywhere we can check our own submitted tickets. I'm sure it's just me missing something, so please can you point me in the right direction so I can submit a ticket properly?
Best wishes
Emma
Profile
So how long should we wait patiently with our hands folded?
Reply
You must log in to post.