Project Daisy – Part 6: fixing issues with shopping cart and shipping cost calculations
Project Daisy is over: I have received the final payment and feedback, and the client says that she is happy with the final result.
That’s what I wrote in my last post.
However, it turned out that the project wasn’t over. There were shortcomings in the shopping cart’s settings and its correspondence with the client’s PayPal account that required re-setting and guidance.
Daisy preferred to meet and ‘walk through’ the issues and new settings together, so we met Yesterday in a cafe in the city.
I’ll take it as an opportunity to cover one more aspect of freelance project work: after-service/support – the extra work that comes on (unpaid, usually) to make adjustments, fix issues and provide guidance.
The issues with this project were:
1. Lack of product ID in orders
When Daisy received an order, it told her:
- how many items the customer ordered
- which varieties (choice of product options)
- what the customer paid
- contact and shipping information
… but not precisely which products, so she had to call up customers and ask what they had ordered!
I saw a copy of an order. Like Daisy said, it shows the generic product name without the bit of the name that identifies the product. That doesn’t make sense, because the identifying bit is the middle of the name.
The item code that identify the products (as a back-up) isn’t shown either. Why is there an option to fill in item numbers in Vistaprint’s PayPal-integrated shopping carts, if that information doesn’t go through with the orders? That doesn’t make sense either.
Also, all the info displays on the shopping cart summary when doing a test purchase – it just doesn’t pass on to PayPal. I searched forums and asked Vistaprint’s support (they didn’t come back yet) and still can’t find a logical explanation.
However, the changes (product ID as part of the name rather than just the product description, and item code) were made only a bit over a week ago and the last order is only a bit younger than that, so maybe somehow there is a delay in the impact of changing the settings.
Time will tell if that’s the case. Yesterday we re-published the settings and Daisy will let me know if she doesn’t get the product ID info through with the next order. If that’s the case, then I might have received a response from Vistaprint by then or tips on one of the forums and can take it from there.
2. The shipping cost calculation has silly consequences when customers buy multiple products (that aren’t bundled)
When a customer buys a product, the shipping charge is added during check-out. The shipping charge is the flat rate Daisy chose when I set up the shopping cart.
However, a new shipping charge is added each time the customer ads a new product to his/her shopping basket. The shipping charge is added each time the ‘Buy’ button is clicked. Since Daisy’s products are small, cheap and light weight, and since customers typically buy multiple items at once, the shipping charge becomes a ridiculous amount relative to the volume and value of the products.
That’s my fault. I should have thought of and advised Daisy that the ‘flat rate’ shipping option would work that way. Vistaprint’s shopping cart offers an alternativ shipping option, namely to use shipping calculations specified in one’s PayPal account:
On PayPal, the shipping charge can be calculated based on price ranges. That is the best option in this case.
It was a bit of a puzzle to set up the shipping costs and price ranges in PayPal. It took some time with scenario planning and a calculator to define price ranges that ensured that lightweight products aren’t shipped to dearly, and that heavier products and bundles with volume discounts aren’t shipped to cheap.
It isn’t an option to calculate shipping charges based on weight and/or dimensions in PayPal (or at least not in the Australian version). If Daisy changes her prices, then she’ll need to adjust the shipping calculations accordingly. As for now, the settings are in balance and work.
Support & profitability
Since I was fixing something the customer could reasonably expect to work, I didn’t charge for the additional meeting and research time. The learning is:
After-service/support can soon pull a low priced project into the red because regardless how cheap it is, adjustments will still need to be made, limitations will emerge, work-arounds will be required, and guidance will be needed.
In my case the project didn’t cause a loss, but only because my income is so minuscule that the opportunity cost of spending extra time on anything is very low.
Of course, the time consumption also has to do with inexperience. If I got a new project on the same platform, then I’d know how to avoid the pitfalls and most likely finish the project faster.
The simplicity of providing support by xkcd: