Since when can customers do an MP redelivery by themselves?

[Fionalein]

7 minutes ago, Pamela Galli said:

Well at the very least, if we deactivate something, for any reason, LL should not take it upon themselves to reactivate it, for any reason.

 It should be my choice what to sell, not LL’s.

you already sold it in the past...

[MoiraKathleen]

I'm just curious as to whether there are all these caveats (about which products can be redelivered) in the automatic in-world vendor redelivery systems?  

(And I understand not all inworld stores and/or vendors have automatic redelivery systems, and perhaps some of these situations contribute to why not.)

[Pamela Galli]

8 minutes ago, Fionalein said:

you already sold it in the past...

No, read up: in the past I sold a trans version. Then I changed to a copy version. Now those to whom I sold the trans version I am being forced to gift the deactivated copy version, which is not my choice. 

[Arwen Serpente]

9 minutes ago, moirakathleen said:

I'm just curious as to whether there are all these caveats (about which products can be redelivered) in the automatic in-world vendor redelivery systems?  

(And I understand not all inworld stores and/or vendors have automatic redelivery systems, and perhaps some of these situations contribute to why not.)

Since the Merchant fully controls those inworld vendor systems, they can control re-delivery in a variety of ways: they can remove the product from displaying and from the drop boxes, or list it as an entirely new product/version, or restrict it to "no copy", or just check mark " In addition, prevent the customer from claiming redeliveries." (in the Casper system, I don't know how others work).

Edited November 30, 2018 by Arwen Serpente

[Pamela Galli]

I will just add a cube to the deactivated listings, and remove the actual product. 

[ellestones]

7 hours ago, Grumpity Linden said:

I think we should do the more generic case - allow a merchant to disable redelivery for 1) their entire store or 2) on a per-listing basis.   Otherwise, we may get caught up in carving out a variety of exceptions.  Thoughts? (I don't mean from Dakota, I mean from everyone  ).

i vote for this

[Cindy Evanier]

19 minutes ago, Pamela Galli said:

I will just add a cube to the deactivated listings, and remove the actual product. 

I think the fix is done

https://jira.secondlife.com/browse/BUG-225891?page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel&focusedCommentId=578704

ETA  I think thats the other one now  (1 am I should be in bed)

Edited December 1, 2018 by Cindy Evanier
I'm blonde

[Pamela Galli]

But I don’t see where we can choose redelivery options. 

ETA oh, I see this is not an implementation of what Grumpity described. It only prevents deactivated things being delivered. Which is appreciated, but it’s not good that I have to deactivate a dozen products

Edited December 1, 2018 by Pamela Galli

[Grumpity Linden]

We have fixed the issue with redelivery of unlisted items (BUG-225891).  Additional refinements and updates to the redelivery feature (based on the discussion here and in jira) will be rolling out in the next weeks.  You don't want us doing massive changes on a Friday.  We don't want to do massive changes on a Friday either. 

Have a lovely weekend everyone.  

[Iren Tinkel]

18 hours ago, Grumpity Linden said:

I think we should do the more generic case - allow a merchant to disable redelivery for 1) their entire store or 2) on a per-listing basis.   Otherwise, we may get caught up in carving out a variety of exceptions.  Thoughts? (I don't mean from Dakota, I mean from everyone  ).

I found Jira on this point but cant comment it with my offer. I think there is no reason to create new one? But i totally agree with Grumpity Linden.

Personally for me would be MEGA great - per-listing basis. I offer free updates for some items. Some - no. And I am able to fill requests to update in-world manually. Also I would love if people have chance to do redeliver themselves for items that I update for free.

[Blush Bravin]

Rather than changing the system, which personally I am very happy to see implemented and have wanted it for a very long time, I think merchants need to rethink their method for updating their products. I think if a merchant is updating a product to the point that it's changed so significantly as to warrant charging for the update, then that product should be renamed and a new listing created. The old listing then would be retired permanently but those who bought the old version should be able to have that version redelivered. The same holds true for changing perms on a product. If you're going to sell copy and a trans only version, then make two listings with that indicated in the naming of the product. The copy version would be able to have redelivery while the trans only would not. 

I think having the merchant be able to set the option on or off for redelivery is going to cause confusion for the buyers. There should be a standard that customers can depend on.

[Pamela Galli]

57 minutes ago, Blush Bravin said:

Rather than changing the system, which personally I am very happy to see implemented and have wanted it for a very long time, I think merchants need to rethink their method for updating their products. I think if a merchant is updating a product to the point that it's changed so significantly as to warrant charging for the update, then that product should be renamed and a new listing created. The old listing then would be retired permanently but those who bought the old version should be able to have that version redelivered. The same holds true for changing perms on a product. If you're going to sell copy and a trans only version, then make two listings with that indicated in the naming of the product. The copy version would be able to have redelivery while the trans only would not. 

I think having the merchant be able to set the option on or off for redelivery is going to cause confusion for the buyers. There should be a standard that customers can depend on.

Well of course, but the point is that making these changes takes time, and we were given no notice whatsoever.. if LL wants to do something that is going to potentially require merchants to, say, create a bunch of new listings, it is only fair to give notice beforehand,

[Reid Parkin]

I remember some customers complaining once in the forums that an update was not as good as the original item, and their 5 star review was for the original item. for that reason I usually include all versions when I update. A 5 star rating and review are based on the item bought at the time. The new animation or texture etc. might not be seen as being as good as the old.

I update all the time, but when I improve an item it is because the original was not as good as it could be, and the customer deserves the best quality that it could be. Therefore it is not a gift, but it's improvement (hopefully) - just like your phone gets updated software etc. You don't pay for this but people are working on it constantly.

My customers know I update my items constantly, but many are just shy about asking for an update, or can't find that proof of purchase.

I would like my customers to have lifetime updates, when they want it, and not have to wait for me to do it.

Perhaps give other merchants the option to turn off customer redelivery, or allow us to set our own time frame - which includes indefinite.

If there are time restrictions then for me it will be a feature that I have been waiting years and years for, but will only be a fraction as good.

[Reid Parkin]

Because I tend to spend more time these days updating and improving my items than making new ones, it could take me 12 months to get to an item - I have a long list of items I am updating (actually all my items). It could take 2 or 3 years to get through that list. So, I need this system to have an indefinite time interval or it won't be much good to me or my customers.

[Blush Bravin]

56 minutes ago, Pamela Galli said:

Well of course, but the point is that making these changes takes time, and we were given no notice whatsoever.. if LL wants to do something that is going to potentially require merchants to, say, create a bunch of new listings, it is only fair to give notice beforehand,

I agree. This is a major change for some and not so much for others. A heads up would have been great and prudent in this situation.

[ChantellexMarie]

As someone who runs a business real life, I can sympathise with Irene's point of view, but I have to say the following.

If I made a product and didn't clearly state by my own terms and conditions what is and what isn't acceptable for a replacement of new for old, then as a responsible business owner I would go in favor of the customer if I didn't have valid grounds to refuse.

When dealing with my suppliers I expect top quality customer service from them, I won't tolerate any kind of drama or nick picking from them, as I won't do it with them.

I recently dumped a supplier because they got all drama queen about a mistake they made on a quote as they didn't charge enough for it.

So in Irene's case on SL, it is your own fault for not creating a new listing with each version number / update, so take it on the chin and make it clear the current versions will not get anymore updates.

Then create a new listing, different name, different version number, different look, can still use all the same scripts and anims and carry on from there.

In the world of business you can't cry over spilled milk, you simply adapt and move on with more knowledge and better business practices, sometimes you get lucky and make a profit, other times you have to cut your losses and move on, but great customer service is what helps to keep you in business.

1st rule of life, never presume anything, and always value your customers, pays big time in the end.

[Pamela Galli]

3 minutes ago, ChantellexMarie said:

n the world of business you can't cry over spilled milk, 

We understand that practices change. What I am requesting is at LEAST give us a heads up when you are aware what they will be, so we can prepare. LL doesn’t really do that. Over and over they implement some change — without notice —- without consulting end users, going live, without user testing. Then we point out the unforeseen problems created. Then people come along and tell us to grow up. Rinse repeat. 

[Iren Tinkel]

It is nice when someone teaches you how to run own business lol.

Making new item with just a few changes, setting new name and new price - oh yeah, it is respect to customer. People need to buy almost same item paying full price. And yes, no any respect to customer to offer update paying price difference. Many people use my offer to update this way. I set low price for new product and updating it for money. Or i set price that includes all updates and send updates for free. It is totally my business how to offer products. Many here say me how to adopt to existing feature that LL made but dont want to understand this feature limits freedom of seller. Well I am glad LL is listening and going to work with it.

 

[Reid Parkin]

We've been asking for this for years and years. We didn't ask for a system that was limited to 6 or 12 months. Might as well not bother with it at all, because it really is useless for most purposes. If I update an item the customer might not even realise there was an update for 6 or 12 months. The only good it will be is for those very few items that weren't delivered at time of purchase, and so you might as well limited it to 1 day. For items lost in inventory (which happens very often) and for updates it would have very limited value.

Many people have been asking for this feature for years, and LL listened. But with a time restriction it wouldn't be much use to those people who were asking for it.

The way I run my business is to give lifetime support and updates. This feature was supposed to make that easy.

[RohanaRaven Zerbino]

Jira submission on the subject: https://jira.secondlife.com/browse/BUG-225895?fbclid=IwAR04CmMDAYTsDur0y89OkE7NbLE_LPp_AfvUugdsRSiold7L5xGIsZz60MI

[Callum Meriman]

On 12/1/2018 at 2:42 AM, Fionalein said:

You mean the ones that actually need redeliveries in most cases - most times on non updated items? Where can I file a counter-Jira?

Yes, I'd back your counter-Jira.

Rather then time limit redelivery, an extra checkbox to allow the merchant to make any individual item one-time only. But show this on the MP on the right, we can then decide if we want to buy a low-support product, just like we decide if we want to buy no-copy.

Edited December 2, 2018 by Callum Meriman

[ellestones]

On 12/1/2018 at 6:08 AM, Grumpity Linden said:

I think we should do the more generic case - allow a merchant to disable redelivery for 1) their entire store or 2) on a per-listing basis.   Otherwise, we may get caught up in carving out a variety of exceptions.  Thoughts? (I don't mean from Dakota, I mean from everyone  ).

i wrote earlier that I vote for this

thinking about it a bit more then I think is not a good idea. So I don't vote for it anymore

when look at it from the customer's pov. A customer who has bought a copy permissions enabled product then the intent is to provide the customer with a way to obtain a redelivery by not having to request the vendor for this, and get frustrated when the vendor does not or cannot respond. I think that both vendor and customer would be happy for the customer to have this capability

a temp mod fix has been done so that the vendor can delist a product and turn off redelivery of delisted products. The frustrated customer remains. The customer can't automagically get a redelivery of the product they have

has been noted that sometimes a product has been updated and the vendor prefers that customers obtain the updated version rather than another copy of the earlier version product. In the case of free upgrades then is no issue for either the customer or the vendor

working thru each of these issues then the remaining issue is when upgrades are not free

I think that MP policy should be that upgrades are classified as a new listing. Previous versions can be delisted and the customer can still get a redelivery of the old version and use it  as they would have continued to do so without redelivery

this is an open question? Bbut am not sure its a good idea for vendors to be able to void redelivery thru delisting to secure sales of updated versions. When the new version can be listed as a new product, and the old version be delisted, be no longer on sale to new customers, and the redelivery of old versions is restricted to the earlier customers. Who may very well choose to buy the new updated version anyways rather than take redelivery of the older version

 

 

Edited December 3, 2018 by ellestones
delisted

[Callum Meriman]

On 12/1/2018 at 2:15 AM, Callum Meriman said:

Relisting the improved version - with same name but different description and a higher price - as a new product would seem to be the proper way to do this.

 

On 12/1/2018 at 5:01 AM, Dakota Linden said:

Under SLX/Xstreet, Aphotheus did allow updates that made more than 50% in changes to the item to be listed as a new item. If the changes that Iren did weren't equal to a change of more than half of the item, then they would have been in violation by deleting the original and creating a new listing for the item.

Maybe this is a case where the old rules need to be changed then? Allow relisting if the item changes in contents and price. A way needs to be created to stop this being a way to evade bad reviews - so add a way to spawn the old listing into a new version, it retains all the comments and ratings of the old, but has a larger version number and won't redeliver to previous version purchasers.

 

Edited December 3, 2018 by Callum Meriman

[Dakota Linden]

6 hours ago, Callum Meriman said:

 

Maybe this is a case where the old rules need to be changed then? Allow relisting if the item changes in contents and price. A way needs to be created to stop this being a way to evade bad reviews - so add a way to spawn the old listing into a new version, it retains all the comments and ratings of the old, but has a larger version number and won't redeliver to previous version purchasers.

 

Hi!

At the risk of sounding like a broken record, file a Jira Request. 

The Jira Request should be to implement a change to the buyer side redelivery function so that the item will only be redelivered if the Version number on the listing currently matches the Version number from the buyers order. (If there is no version number, or the version numbers match, then the buyer can ask for redelivery as many times as they want).

Version numbering exists already on product listings. It is the responsibility of the seller to change or update that number when they do any updating to the item itself. 

But your Jira Request would ask to implement version checking before the redelivery of the item to the buyer. 

 

[Love Zhaoying]

52 minutes ago, Dakota Linden said:

Hi!

At the risk of sounding like a broken record, file a Jira Request. 

The Jira Request should be to implement a change to the buyer side redelivery function so that the item will only be redelivered if the Version number on the listing currently matches the Version number from the buyers order. (If there is no version number, or the version numbers match, then the buyer can ask for redelivery as many times as they want).

Version numbering exists already on product listings. It is the responsibility of the seller to change or update that number when they do any updating to the item itself. 

But your Jira Request would ask to implement version checking before the redelivery of the item to the buyer. 

 

Idea: let merchant toggle a choice of either “let customer get newest version” via redelivery, or “only give customer same version”. Wouldn’t free upgrades be made easily by choice #1?