| When you hire a service provider to design | | | | of products. |
| your e-commerce website, you need to be | | | | |
| involved in the implementation strategy in | | | | 4. Vendor support and commitments: Review the |
| order to ensure that the final product will | | | | vendor's service obligations to ensure what |
| be what you want and that your forthcoming | | | | is included in the implementation. Contact |
| costs and complexities are not | | | | other businesses for feedback about the |
| inappropriately higher than they should be. | | | | vendor. See samples of final shopping carts |
| | | | having been implemented by the the same |
| If you wait until the system has been | | | | software you are considering purchasing. |
| completely implemented, it can be too late. | | | | |
| The cost to reconfigure a system is | | | | 5. Documentation: Make sure you receive the |
| prohibitive. As you add more products to your | | | | list of passwords, directory names, features, |
| product line, it gets harder to change the | | | | add-on products used for the implementation |
| design and internal setup. You are risking | | | | so that if you need to change service |
| missed sales opportunities if it takes too | | | | providers, you will have all the required |
| long to update your product line or if your | | | | information. You will save yourself big |
| shopping cart is too complex for the | | | | losses if you do this. Documentation should |
| end-user. The design has to consider not only | | | | also be provided. To ensure this gets done |
| ease of use, but also the 'back-end' setup | | | | most effectively, you should receive |
| since the ease of use is dependent on the | | | | documentation updates throughout the project |
| internal setup. | | | | planning and implementation. Don't wait until |
| | | | the end to ask for this. Part of the |
| You can reduce your costs and frustration if | | | | documentation should include what you need to |
| you raise certain issues with your designer | | | | do on an ongoing basis. For example, how to |
| before they start designing. For example, | | | | upload, download, export, import, re-index, |
| | | | etc. |
| 1. Simplification: How many levels of | | | | |
| products do you really need? How complex is | | | | 6. Naming conventions: What a difference the |
| the pricing structure? The more levels and/or | | | | name makes! If your products were kitchen |
| options (attributes), the more clicks a user | | | | products such as: home kitchen utensils 1 = |
| would have to do and the more confusion it | | | | one of your utensils home kitchen appliances |
| may cause. You could lose your prospective | | | | 1 = one of your appliances. then naming your |
| buyer this way. Your maintenance costs are | | | | products 1HKU and 1HKA, respectively, would |
| proportional to the complexities, i.e., the | | | | not be the best way to name them. You |
| more complex, the higher the costs. | | | | wouldn't easily be able to list all home |
| | | | kitchen products. A better way might be HKU1 |
| 2. Design approach: Review the maintenance | | | | and HKA1; then searching for all home kitchen |
| plans and strategy to ensure the best | | | | products with the code 'HK' would give you |
| approach is taken for your business strategy. | | | | all utensils and appliances. Adding new |
| | | | products to your product list would take less |
| 3. Test run a few different products in | | | | time. Remember that a computer search works |
| different categories (adding, changing, | | | | from left to right. |
| attributes) to understand the maintenance | | | | |
| impact of your implementation. It would be | | | | By reviewing these sample issues, you can |
| more cost-effective to overhaul at the | | | | ensure a better, more cost-effective |
| beginning of implementation rather than later | | | | implementation. |
| down the road. Don't just test one category | | | | |