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