Hey Andrew,
I like the idea of this, but I have a few questions regarding what qualifies a dispute. Also, just to make sure I understand properly, this 'Under Dispute' will display in the members Profile AND Product page? Here are a few questions I have:
- If a member purchases a product, has problems/errors trying to install it, and is not getting a response from the developer for support.. Is that grounds for a dispute?
- With the above said, does 'communication' between the developer and see more purchaser in any way constitute grounds for a dispute?
- I personally do not think a member can start a dispute for a product that does not work properly due to other 3rd party modules installed. Do you agree?
- There should be a set time period before a member can initiate a refund for a product purchased. Example, if a member purchase a product, product is failing for whatever reason, the member should have to wait at least XX days before submitting to PayPal (example) for a refund. How many days do you think that should be?
- As said above, the developer should be held responsible to respond to emails/forums from purchasers regarding assistance with installation and/or errors that renders the product or site non-functioning. Do you agree? If so, what should the response time be?
I have some more, but will start with those questions.
1) The developer should only be at fault if the product is faulty (i.e., the errors are because there is a mistake in the SQL statement, which is the fault of the developer), or if they promised to provide installation support when purchasing the product. I do think all developers should be required to support their products, though, but a dispute should only be considered when the problem is actually because of the developer, not the customer.
3) This would fall under a problem that was caused by the customer, not the developer. But it does raise some interesting questions. Developers should state any known incompatibilities with other products. I think there should also be an option to list a product as either a module (no core file changes), mod/modification (core file changes), or template. Purchasing a mod should display a warning that the product may not be compatible with other mods.
4) I don't think a customer should immediately file a refund request. The only people who should be doing that are those bottom-feeders who rip-off developers, and those lot should be permanently suspended with their IP blocked. I would wait at least three days to give the developer time to respond to any questions/requests for support.
5) I usually give developers at least three days to respond to problems (respond, not to actually fix the problem), more if it's the weekend. If the problem is their fault, and not the customer, they should be held responsible to fix all problems, or provide a refund and discontinue selling the product. I want to give developers ample time to respond, but also need to think of the customers and potential customers involved.
Here's an after-thought: Products which are faulty and do not even install should not be allowed to remain for sale, and should be hidden until the problem is fixed. Keeping these products available will only hurt people.
I like the idea of this, but I have a few questions regarding what qualifies a dispute. Also, just to make sure I understand properly, this 'Under Dispute' will display in the members Profile AND Product page? Here are a few questions I have:
- If a member purchases a product, has problems/errors trying to install it, and is not getting a response from the developer for support.. Is that grounds for a dispute?
- With the above said, does 'communication' between the developer and see more
1) The developer should only be at fault if the product is faulty (i.e., the errors are because there is a mistake in the SQL statement, which is the fault of the developer), or if they promised to provide installation support when purchasing the product. I do think all developers should be required to support their products, though, but a dispute should only be considered when the problem is actually because of the developer, not the customer.
2) You'll have to explain see more