Plugging Holes in the Marketplace

October 19, 2011 by
Filed under: Linden Lab and Second Life, New Products 

Since its release toward the latter half of last year, the Second Life Marketplace has been lacking some pretty crucial features. When the Commerce Team made their initial announcement that a “bigger, better, faster Virtual Goods shopping site” was coming out soon, those of us in the more pessimistic camp belted out a resounding “We’ll believe it when we see it.” Here we are more than a year later and … we ain’t seen it yet.

One of the glaring meta-issues with the SL Marketplace is its total lack of consideration for how Merchants want to work (or already do work). In all honesty, I believe it was written by folks that have never done a day of marketing or virtual sales in their lives. (But then again, in all fairness, if we catch them being merchants then we tend to get all bent that they’re using Alts to make unfair profits … so .. *shrugs*) Anyway, today’s post is about a new product coming out soon that will plug one of the more annoying “Holes” in the features offered by the SL Marketplace: Customer Redelivery of Copyable Products.

Copyable vs. Non-Copyable Products

Before I dive into the new product and what it does, I need to lay a little groundwork first. Apologies if this is old news but I think it will help understand things a bit further down. It has to do with “Asset Permissions” and the two general types of products sold in Second Life: Copyable and Non-Copyable.

When a Customer makes a purchase from the Marketplace, the Merchant’s Magic Box delivers a single item … usually a boxed item. The Customer must rez the box, unpack it and copy the contents to their inventory. With the upcoming release of Direct Delivery the exercise of opening and copying will be eliminated for some folks but many of us intend to deliver the same boxes as we do now. (There are lots of reasons, but I won’t dig into those now.)

When a Merchant wants the Customer to be able to make multiple copies of the product (for example my DG Flyer series Teleporters are all copyable allowing my customers to set out as many as they want with only one purchase), the “Asset Permissions” of the delivery box are usually set to allow the Customer to make multiple copies of it. This allows the Customer to rez the box, unpack and copy it to their Inventory … then delete the rezzed copy of the box as the original box is still intact in their Inventory. (I also set the DG Flyer itself to allow copying, but for our purposes the only permissions that count are those of the box, not its contents.)

When a Merchants wants the Customer to have one and only one copy of the item they purchased (as is often done with clothing and personal appearance accessories) then they will set the Asset Permissions of the delivery box to prevent copying … in other words they make it Non-Copyable. (They set the permissions of the item inside the box to prevent copying as well.) If they only set the item’s permissions to prevent copying but leave the delivery box copyable then the Customer can still have as many copies as they want … they simply rez a new copy of the delivery box and copy the contents to their inventory again.

In summary then, if the Customer can make copies of the product they purchased, both the delivery box and the item(s) inside will allow Copying. Otherwise both the delivery box and the item(s) will prevent Copying. Thus if the delivery box allows Copying then the Customer can make copies; if the delivery box prevents copying then the Customer receives one and only one copy per purchase.

Replacing a Lost Product

From time to time people do things that wind up not being what they wanted. Sometimes that means they no longer have access to a product they purchased even though it allowed making copies. Computers sometimes do it to us as well. Many are the stories of people losing things in the dreaded “Inventory Malfunction”. It happens .. meh!

As a Merchant that sells copyable products, I sometimes find myself sending people replacements for products they purchased and subsequently lost. That usually involves me looking up their purchase in my database, verifying their name, logging into Second Life then manually sending them a copy of the delivery box. Of course all that happens after I get their message. Some folks contact me right away, but many either shrug and forget it or take several days (or I don’t get their message for several days … for various reasons).

Power To The People!

What the Marketplace really needs is a way for Customers to request redelivery of copyable products without having to contact anyone. If they had a place where they could just plug in some brief details and automatically request another copy then they would be happier, Merchants would be able to provide a higher level of Customer Service, and the net effect would be good all around. Since Linden Lab didn’t seem interested in providing that feature, I guess it was time someone else did.

The iGlom Redelivery Service (RDS)

I have been testing out a new service called the “iGlom Redelivery Service” for the past few days. The service is still very new and has some rough edges, but it seems to be doing exactly what it promises. It took me about 20 minutes to install and configure, but most folks should be able to complete setup in less time. Basically all I did was drop a single script in each of my Magic Boxes then made some configuration changes on the web … and I was done.

Every time someone purchases one of my products from the Marketplace, a record of that sale is stored in the database used by RDS. When a Customer wants to request redelivery of a product they purchased, they use theĀ iGlom Redelivery System – Customer Request Form, enter the Order number, Item ID number and part of the product name … and in short order another copy is redelivered by one of the Magic Boxes. I get an IM when that happens too, but I have the option of turning those messages off if desired.

RDS Only Redelivers Copyable Boxes

The iGlom Redelivery Service will only redeliver those items that can be copied by the Customer. It does that by checking the permissions of the item in the Magic Boxes’ contents. As discussed above, since if the delivery box is copyable then the entire product is copyable, this means Customers can only redeliver things that allow them to make copies. The best part is … this all happens automatically! I don’t have to hassle setting options for each product. The iGlom RDS does all the decision making itself, actually checking the Asset Permissions just before it redelivers the item. If the product doesn’t have the proper permissions to be redelivered then the iGlom RDS simply will not send it out. Period. End of story.

No More Resynching

One of the most annoying parts of the Marketplace interface to its Magic Boxes is the whole issue of synchronizing them with its database. That’s just plain dumb (IMO). To it’s advantage, the iGlom RDS uses some sort of “Dynamic” method to keep track of the items in each Magic Box. I can change items around, add items, remove items … and never once have to touch the iGlom RDS website.

The Magic is in the HUD

As a matter of fact, there really isn’t a web interface for the iGlom RDS other than the Redelivery Request Form page. Everything I need to control as a Merchant is handled through a simple HUD. The options are the types of things I need to set once and leave set forever, so I just put the HUD on, set things and took the HUD back off.

The HUD also has two Magic Box related functions. One lists the Magic Boxes that RDS knows about (meaning those that have the RDS Plugin script inside) and reports their status (“Okay” or “Down”). The other function is called “Test Magic Boxes” but what it does is have each Magic Box send me an IM. (That’s a test, right? LOL) One interesting thing about the test function is … it really points out when a Magic Box is lagged badly; its IM will arrive much later than any others. If I have concerns about a Magic Box, I just put on the HUD and “Test” them then look to see if everyone checks in.

Drumroll Please . . . . . . The Downside Is?

The one bad thing about the RDS system is .. it can only redeliver products that are purchased after installation. That means the 2+ years of product sales data I have from before installing RDS is … well, it’s useless to me for RDS purposes. I’m still negotiating with the developer to provide some sort of data import service, so I’ll let you know how that goes.

RDS and DD and ANS … Ole!

When the Marketplace was first released, there was an initial belief that the Automated Notification System (ANS) would not be supported. ANS is the system that sends a copy of each sale transaction to an outside website (or an In-World Object). However it quickly became evident that leaving out ANS was not an acceptable conclusion; far too many Merchants depend on it. Now that Direct Delivery (DD) is on the horizon, again it is expected that ANS will continue to be supported. Since the iGlom Redelivery System (RDS) depends on ANS, and there’s a good belief that ANS will continue to live, I’m comfortable betting on RDS as well.

More Future Stuff

As I mentioned, the RDS system is still pretty new and rough, but it has lots of promise too. The developer talks about providing sales reports and graphs in the future as well as offering other value-added services.

Still In Testing

The developer is looking for a few Merchants willing to test the system in exchange for a favored subscription period. (He intends to sell it as a subscription service in 1-month, 3-month, 6-month and 12-month time periods.) If you are interested in testing it out, use the “Contact Us” link on the Customer Request Form to write the developer.


Visit the DGP4SL Store on SL Marketplace

Comments

2 Comments on Plugging Holes in the Marketplace

  1. Toysoldier Thor on Sun, 23rd Oct 2011 11:09 AM
  2. This is smart idea. I totally shake my head how smart simple ideas like this are not thought of by the the LL Team that runs the MP and should know best the needs of the Merchant’s on the site. You are right though, the LL Commerce Team has not real experience on how to create and sell in SL. If they did they would have come up with ideas like this. Unfortunately not only do they not have the real experience but they also refuse to actually listen to their customers – the merchant community – of what we need to sell effectively to the SL community.

    Anyway, I think its a great idea. Question I have is where does a customer find this Redelivery web form? Would you be expecting this to be a link off the actual MP product page? If it were in an “in your face” location that customers fully would expect it – like the page they bought it at – the this would avoid the Customers IMing merchants anyway to request re-delivery.

    I suspect regardless of the location, until LL put this as a well known MP function, customers will continue to approach the merchant directly. At least the merchant can then pass the link to the customer. BUT of course then the customer will tell the merchant “since I have you now anyway can you just send me the pack – I dont want to go through the hassle of filling out the form” and we will be forced to honor their wish in order to provide awesome hassle-free service.

    The other thing I wasnt sure on is where is this database maintained? Is this service a PER MERCHANT controlled and managed service or maintained centrally – i.e. are all the Merchant’s transactions by tracked and maintained by some outside source. Not sure what exactly my concerns are but ghosts of RedZone external DB come to mind if you know what I mean. I am always paranoid of exposing my transactions and activities into a DB that I dont have control or say in. Not that I wouldnt do it but more due diligence is needed to ease my fears.

    For my business personally, this service is cool and I do fit the model to leverage it as I do sell and plan to continue to sell BOXED items – even with DD. And I do sell Copyable products. Where the service loses value for me is that I rarely get re-delivery request. Likely because I have a very small inventory of MP products which seems to keep the Magicboxes running well. So I only get maybe 1 redelivery request from a customer every couple months if that. As such, any service that fixes this problem for me is one that is solving a low-importance problem.

    I totally see how this helps fellow merchants with much larger inventory and much larger sales volumes. Its a very important service – just not for my operations.

  3. Iamanaltof Glom on Sun, 23rd Oct 2011 1:46 PM
  4. @Toy – Thank you for your feedback and compliments. I thought this idea over a long time before doing anything about it.

    The database is kept in a central location for all merchants but it is a private database and I’ve done my best to lock it up tight. Eventually I hope to use it to provide more accurate sales reports and other important data. But I do understand your concerns about RZ. That’s one of the big reasons I delayed this.

    When a customer purchases one of your products they will get an IM from the iGlom system that gives them a URL to click to reorder. The link has all the info already, they just have to enter a security code from one of those CAPTCHA things. (scrambled looking letters you have to recognize and type in) You can turn that option off if you want, but it’s probably useful to most customers.