Today I’m sitting in the “Using ATG Scenarios – Driving Customer Loyalty Using ATG Scenario Personalization” training class. I caught the tail-end of “Exploring ATG Technology – Solving Business Problems and Maximizing ROI Using ATG Solutions” and I have to say, it’s quite interesting to be sitting in a class with the different business users. Their questions are moreso of the “can we” nature rather than “how do we”.
Last week I was in the developer training course for setting up content administration, so I was familiar with the interface the class is using. However, I won’t be in Commerce training until next week, so some of the more advanced functionality is new. I will be eager next week to see how we manage to achieve some of what my colleagues requested.
I’m glad I did some additional reading on my own, when some questions arose about affinity selling, I was able to ask if that was related to the ATG purchase of CleverSet. I appreciate that we’re learning everything ATG has to offer, but I’m trying to be particularly conscious of what functionality is related to which version or module. In fact, when there was a question about affinity selling coming from CleverSet integration, the instructor acknowledged that he wasn’t sure in which version of ATG it was incorporated; if it was in 2007.1, or would be coming in the next release.
We looked briefly at promotions and coupons, which I had a personal interest in. The other day I purchased roadId online, and was given a “thank you code” that could be used up to 20 times within the next 30 days. As online coupons become increasingly shared on sites like dealcatcher or even on message boards, I understand the need to limit the number of times a particular discount can be applied. As we were talking about the difference between a promotion and a coupon, I asked if this sort of limitation was supported by default on a promotion. (You can specify limits on a single user’s participation in a given promotion). The instructor said this was not a built-in field, but a scenario could be written to support this business rule. Shortly thereafter we were discussing coupons, and I wondered if perhaps that was a better object on which to enforce this limitation. Some of my colleagues and I were discussing the equivalence in the real world: for a discount, you wouldn’t turn away the 501st person to walk in the door, but on the other hand, you could prevent users from photocopying or reproducing a coupon. I don’t know that that really clarified anything for me in my head, but it was something to think about.
Some of my colleagues had some other intriguing questions: could we ensure that the recipient of the coupon is the one to redeem it? Again, the instructor said it was possible we could build this into a scenario. It sounds as though the redemption rules will be quite involved!
I guess I see the limitations on the usage of a particular promotion (coupons?) as an attribute of that specific element itself, not really part of a scenario (which I associate with user or system behaviour). As I mentioned, my coupon code for buying my RoadId is ThanksAndrea357853. It has particular rules governing its usage. If I do a google search on roadId coupons, I an find other such codes (ThanksKim357919, ThanksDoug330021). The basic rules for the promotion are the same (20 users, 30 days), although the start and end dates are different.
As I write this, I realize I really don’t understand the difference between a coupon and a promotion, unless a coupon is simply a means to a particular instance of a promotion…