I voted for it.. and I would love to have a cron job that would auto e-mail customers that have outstanding rewards points if they haven't ordered anything in XX number of days. Great tool to bring customers back.
Magpie Don - I totally agree. It's an incredibly strong customer retention tool. Did you already vote (see link above)?
@racingsolution - if cs-cart simply makes this a column we can do with it whatever we want. A.O export to 3rd party tools like Mailchimp.
I voted for it.. and I would love to have a cron job that would auto e-mail customers that have outstanding rewards points if they haven't ordered anything in XX number of days. Great tool to bring customers back.
I could possibly extend my EZ Auto Mailer to do this. Would need to see a little more interest than one or two to justify the investment. But the advantage would be that it would work right along with your other transnational emails.
I could possibly extend my EZ Auto Mailer to do this. Would need to see a little more interest than one or two to justify the investment. But the advantage would be that it would work right along with your other transnational emails.
That's what I was thinking as well. Let me know if others ask you about it.. I'm always available to test.
It's a few hours work so would need it to generate some new sales to make the investment.
Why this playing down ( by the CS-Cart owners ) of the benefits and use
of the Reward Points system ? It's one of the strongest marketing tools
there is. It's used ( in various forms ) by all major credit card companies
and most big traders.
Maybe I am being a little cynical but I feel another deprecation coming.
Sorry guys but your deprecation history is more than a little transparent.
I can't even begin to understand the complexities of php but it seems that
the developers of CS-Cart could more easily modify the code of add ons
to work with future cart versions than 'outsiders', so to speak.
Deprecations and sell backs will result in CS-Cart more closely resembling
the likes of BigCommerce.
Magpie Don - I totally agree. It's an incredibly strong customer retention tool. Did you already vote (see link above)?
I voted for it.
It's a few hours work so would need it to generate some new sales to make the investment.
I'll buy. I'm just getting ready to launch a new build, and I can install your Auto Mailer there. Really, I want it anyway - but adding a Reward Points Notification would really put your addon over the top. :)
I voted for it.
I'll buy. I'm just getting ready to launch a new build, and I can install your Auto Mailer there. Really, I want it anyway - but adding a Reward Points Notification would really put your addon over the top. :)
I've been using the Auto Mailer addon for years.. It has worked very well
I voted for it.
I'll buy. I'm just getting ready to launch a new build, and I can install your Auto Mailer there. Really, I want it anyway - but adding a Reward Points Notification would really put your addon over the top. :)
Tony's AutoMailer addon already has the ability to notify users of reward points..
Just have to know how to use it. and how to have the system pull the users points.
Been using it for years now.
Jay, I was considering something specific to reward points that could be on a different delay than the order/item/category followup email I.e. a separate event so you could set it up to queue emails for orders that have non-zero balance of reward points where the last order was older than N days old. If customer places order and a queued email exists, remove it from the queue so it can be reset for the new order being placed.
Note that in the current product, you could have (for instance) 2 events defined for 'order placed'. One might be a followup requesting a review in 3-5 days (the standard method) and the other might be a more general "please come back" email that emboldened their reward points that would be sent say 14 days after purchase.
The trick is not to hammer them with unwanted emails, especially if they've already come back and used their reward points in the (above) 14 day period.
Jay, I was considering something specific to reward points that could be on a different delay than the order/item/category followup email I.e. a separate event so you could set it up to queue emails for orders that have non-zero balance of reward points where the last order was older than N days old. If customer places order and a queued email exists, remove it from the queue so it can be reset for the new order being placed.
Note that in the current product, you could have (for instance) 2 events defined for 'order placed'. One might be a followup requesting a review in 3-5 days (the standard method) and the other might be a more general "please come back" email that emboldened their reward points that would be sent say 14 days after purchase.
The trick is not to hammer them with unwanted emails, especially if they've already come back and used their reward points in the (above) 14 day period.
I got ya.. The one thing I'd like to see is being able to pull reward point status at the 90 day interval. As of now I set up the 90 day follow up email but the points are pulled at the time the email is queued. It would be nice to pull that data at the time the email is going out.. Hope that makes sense. As you know I already do all of the above mention email types with your addon, just would like the live updated data. Either way its making us money. Even when the points aren't exactly correct. If it come into question we have no problem giving the customer a couple extra points to generate a decent order...
I got ya.. The one thing I'd like to see is being able to pull reward point status at the 90 day interval. As of now I set up the 90 day follow up email but the points are pulled at the time the email is queued. It would be nice to pull that data at the time the email is going out.. Hope that makes sense. As you know I already do all of the above mention email types with your addon, just would like the live updated data. Either way its making us money. Even when the points aren't exactly correct. If it come into question we have no problem giving the customer a couple extra points to generate a decent order...
How about something like this
1) Upon the specified order status (Completed, shipped, etc), if user's reward points > 0 then que a follow email for specified days (15,30, whatever .. user defined)
2) When that email is scheduled to process, verify their reward points are still > 0 and then send. If = 0 then delete the email from the que
That would be the point of making it a separate event. Could then have reward points be the object it's reporting on for a customer versus an order_id. In the queue, the am_trigger_data column is the object_id of the item type of the event. For event orders it's an order_id, for profile stuff it's a user_id, for a form, it's a page_id, etc. So adding a new type for reward points would be similar to the profile methods and would use the user_id as the am_trigger_data.
Note that there is a hook in the auto_mail processing code called 'am_get_order' that has a single parameter of the $order_info. So in theory you could go into your my_changes addon and setup a hook for 'am_order_info' and have it be something like (untested).
fn_my_changes_am_order_info(&$order_info) {
if( !empty($order_info['user_id']) ) {
$current_points = fn_get_user_additional_data(POINTS, $order_info['user_id']);
$order_info['available_reward_points'] = (integer)$current_points;
}
}
Then just use the ($am_order.available_reward_points} in your template. That should then give you the current available points in that element of $am_order,
There's always 100 ways to skin a cat..
How about something like this
1) Upon the specified order status (Completed, shipped, etc), if user's reward points > 0 then que a follow email for specified days (15,30, whatever .. user defined)
2) When that email is scheduled to process, verify their reward points are still > 0 and then send. If = 0 then delete the email from the que
Wouldn't want to add reward point logic to a generic order_place event. That would be really bad form from an architectural point of view.
The easiest and quickest solution is to use the hook I describe above. If you need some help implementing it, just let me know.