I decided to sell my products in individual sizes instead, updating my vendor delivery method to let customers choose their preferred size from a menu before payment. This change aimed to please my customers and offer more affordable options. This approach would have yielded quantifiable data on my customers' size preferences, indicating which sizes to continue supporting and which to potentially deprecate.
jkyx [stiletto] - product render in Substance Painter. The first product to experience hiccup in sales due to customer unfamiliarity with vendor menu switch. Featured at the Vault event July 2023.
Customer sharing a screenshot of their difficulty making a purchase of the product after it was moved to the flagship where lag and traffic is much lower and hence not a common obstacle.
Every shop owner's dream customer scenario. Or is it?!
Demonstration of two vendors, Left: using Direct Pay and Right: Left-Clicking to activate robust options menu. Note cursor changing from L$ in circle icon to typical pointing hand icon between the two, which are native Second Life GUI.
Demonstration of a vendor reproducing the "no price" obstacle users faced when attempting to bypass the menu dialog and ignoring local chat by "right-click > pay" behavior, the vendor could not charge them when it didn't know what size is selected.
Portion of HUD UX Survey results regarding unpacking by size and whether to incorporate it into the product delivery pipeline.
Results from subsequent follow-up survey after spike in support requests: type of menu used.
Results from subsequent follow-up survey after spike in support requests: first option.
Results from subsequent follow-up survey after spike in support requests: 2nd option.
Results from subsequent follow-up survey after spike in support requests: direct pay.
Screenshot showing multiple servers approaching capacity. Due to exponential increase in individual product delivery HUDs stored this capacity is overwhelmed at a significantly faster rate requiring more servers to be deployed.
The Multi-Item Vendor Panel that ships with the MD Labs Vendor system as a UI for the Mult-item script version. This is typically not used in Events because of the lag on end users when "flipping" through loading multiple textures to view different products.
Multiple sizes of a product, the corresponding texture change HUD, and the Delivery HUD they will all be packaged into at once assuming this is the full "fatpack". When selling by individual sizes, each size would be packaged in its own Delivery HUD.
Flowchart demonstrating the simplicity of packaging all sizes together.
Flowchart demonstrating the repetitive process to package by size.
Screenshot of neighbor's booth at an event using single-item vendor per size, each button with its own nested script so regardless if a user left-clicked or right-clicked > pay they would directly buy the product with no menu.
Screenshot of instructions provided to customers at another store.
Mainframe, an event I frequently released new products through, notifying me of customer confusion with my vendors.
Messages from customers raising concerns that they are unable to make purchases with my vendors at various events.
More customer complaints and confusion.
Even more.
Lag is the usual suspect when troubleshooting. The broader picture emerged when complaints were for multiple vendors simultaneously both at events and when moved back to the flagship.
Band-aid signage placed quickly over vendors at event booths as there is a setup deadline and revamping the booth was not possible.
Developer of MD Labs, Mattia Delwood, demonstrating no issues found when troubleshooting my vendor at Mainframe event: product works as expected pending the customer selecting the desired size from the menu.
The road to hell is paved with good intentions. Reducing cost on consumers doesn't always mean convenience.
