Customer satisfaction is a factor that can make or break a business. Satisfied customers can potentially recommend products and services to others and become repeat customers. On the other hand, dissatisfied customers may never or rarely provide repeat business, and might even tell others about their dissatisfaction. This is why to alleviate things that irritate your customer, one should solicit product feedback.
The need to identify the areas customers may be having a less than satisfying experience is very important. How satisfied customers are with a particular physical characteristics such as functionality, prims, script load, and aesthetics of the product that they purchased? Identify the functionality that the product provides and have customers rate each aspect of its functionality separately on an even-numbered scale so that there is no neutral option available. Some businesses will create a notecard with a series of check-off boxes in it for this purpose, others might use an in-world survey kiosk or a web site.
Soliciting product feedback when the product you require feedback on is not really a physical product, but instead customer service and support offerings, is not quite as straightforward. One must examine sales and service to identify areas where customers may be experiencing a degree of dissatisfaction. It is difficult to ask open ended questions to identify these areas from customers, since most customers will not take the time to answer open ended questions, even though this type of information is the most useful form of feedback for a business.
Functionality testing a new product or service before general release to the public is generally performed in two stages, alpha testing performed by the creator of the product and then beta testing by individuals most likely to use the product in the field. The primary reasons for functionality testing is to ensure that it satisfies the requirements of end users and also to come up with suggestions for future improvements.
Scripted objects are more likely to be functionality tested than non-scripted objects. Such testing requires that the product be utilized over and over again starting with individual testing of minor components (i.e. when odd symbols and excessive characters are submitted into the script does it respond appropriately or result in parsing and memory errors?) working up to the overall major characteristics of the solution such as generating the correct output when provided multiple variations of inputs. If a significant issue is discovered at the early stages these are usually resolved first before proceeding onto a later and larger stage. The testing process can very monotonous, yet is an important requirement.
The platform and viewer used to interact with and view the object is a circumstance that needs to be considered too as many still insist on using older viewers that may not be capable of rezzing sculpt and mesh objects nor respond appropriately to the latest and greatest scripting commands. Textures may not load as quickly as desired on computers with minimum hardware specifications and/or slow internet bandwidth speeds. Such limitations may either be addressed by the creator through either modification of the object or a mention in the notecard instructions that the viewer, hardware, and bandwidth must be meet certain requirements. In the latter case any identified glitches are indicated as “not a bug” and disregarded.
In the absence of external testers the creator can simulate much of the above by having multiple clients installed on multiple computers (i.e. desktop and laptop/netbook) as well as connections both hard-wired as well as wireless to vary the internet connection speeds. Alternate accounts can not only test for correct functionality, but can also be used to ensure the permission of objects and their contents (i.e. textures, notecards, scripts, animations, etc) appropriately protect the creator against theft while also allowing the user to customize or configure as required.