![]() |
Using discount code field on viewcart.asp in V4 |
Post Reply ![]() |
Author | |
Guests ![]() Guest ![]() |
![]() ![]() ![]() ![]() ![]() Posted: 01-April-2010 at 11:14pm |
I've a client who would like to have the discount code field on the cart summary page (viewcart.asp).
I'm thinking there are many considerations here such as discounts that only apply to wholesale vs. retail customers when these folks haven't logged in before shopping; shipping based discounts when we don't know the shipping address yet, and possibly other scenario considerations. Looking for some help to think through all of the possible considerations here to see if this is a viable idea. It's pretty typical for online stores to have it this way, esp. as it helps to overcome the psychological trauma of clicking that "check out" button. While that's tongue in cheeks, in all honesty, psychology is a huge consideration -- take "Guest" checkout, and even OPC. |
|
![]() |
|
ProductCart ![]() Admin Group ![]() ProductCart Team Joined: 01-October-2003 Status: Offline Points: 135 |
![]() ![]() ![]() ![]() ![]() |
Hi Sean,
The biggest issues are: (a) Customer type filter may not work (since the customer may not be logged in yet; keep in mind pricing categories as well) (b) Customer filter may not work (since the customer may not be logged in yet) (c) Order amount filter may not work correctly (as the order amount may be lower once you log in and your prices are recalculated based on your customer type) (d) "One-time" restriction may not work correctly (since the customer may not be logged in yet) (e) Free-shipping coupons will not work Edited by earlyimp - 02-April-2010 at 1:06am |
|
![]() |
|
Guests ![]() Guest ![]() |
![]() ![]() ![]() ![]() ![]() |
Thanks. Yep, that's pretty much what I was thinking, though I missed the "one time" filter.
I think the problem is this: In my case, I've a client trying to migrate from a custom built shopping cart. In other cases, the client is looking at high profile custom build carts in their industry, say Gap.com. Either way, those carts are BUILT for that businesses own specific business rules. PC, on the other hand, is an amazingly robust, feature-rich generic shopping cart application -- it's designed to handle a huge variety of possible business rules that may or may not apply to any given merchant. But of course, folks can't help but be myopic in their perspective, so they think this vastly complex application "should" do the little thing they want and don't consider all of the other variations on business models that it must accommodate. It's a double edged sword, or maybe more an Achilles heel: these rules could be "dumbed down" and customized for a customer, but then they loose other advantages such as changing their business rules as they grow or making upgrades much more complicated and expensive to do. Thanks for the feedback here. I wanted to make sure I had a solid understanding of all of the considerations so I and others can make a cost/benefit analysis of whether this is even worth thinking about. |
|
![]() |
|
ProductCart ![]() Admin Group ![]() ProductCart Team Joined: 01-October-2003 Status: Offline Points: 135 |
![]() ![]() ![]() ![]() ![]() |
That's exactly right, and we run into this problem all the time. In fact, there are rather often cases where we start looking at a feature that appears simple to implement at first sight, and then we end up scratching the whole thing when we realize that there are too many conflicts/limitations due to other, complex features that come into play.
Interestingly enough, this is exactly what happened when we reviewed the possibility of moving electronic coupon redemption to the "View shopping cart" page during the development of v4. |
|
![]() |
Post Reply ![]() |
|
Tweet
|
Forum Jump | Forum Permissions ![]() You cannot post new topics in this forum You cannot reply to topics in this forum You cannot delete your posts in this forum You cannot edit your posts in this forum You cannot create polls in this forum You cannot vote in polls in this forum |