Queued Emails

[heatherbell]

If anyone has ideas for extra Scheduler Modules for the QE system, please let me know as I may be able to take your idea(s) and make something really cool.

Just posting as a matter of interest as we've never had this sort of e-mail before and were impressed.
Was recently browsing on a site where I had purchased and registered before.
Didn't sign-in (maybe didn't sign out on last visit?) or add to cart but a little while later had an e-mail from them, along the lines:
"Can we help? We noticed you've been on a little browsing spree! We just wanted to check if we can help in any way. Please reply to this e-mail if you have any queries. Alternatively, click the product link below to continue where you left off."

[burt]

Was recently browsing on a site where I had purchased and registered before.
Didn't sign-in (maybe didn't sign out on last visit?) or add to cart

I can't think of a (good) way to enable this where customer doesn't sign in.

The only way I can think of is (on create_account, or next time an existing customer logs in);

- create a "customer key" and store it in the customers table

then also

- cookie storage of that same "key"
or
- localstorage of that same "key" (more or less like a cookie)

When a person browsing hits a given page, let's say "product_info"... grab the Cookie stored key & match it to the DB stored key. Schedule the email, based on getting customer data from the matched Keys.

That's all possible, but it's a lot of moving parts.

Putting aside the creation of the email, which is quite easy...can you think of any other way to ascertain which customer is looking at the site (assuming that customer does not log in)...

[heatherbell]

Putting aside the creation of the email, which is quite easy...can you think of any other way to ascertain which customer is looking at the site (assuming that customer does not log in)...

It certainly puzzled me as to how they knew we were on site which is why presumed either not signed out from last visit or that cookie was persisting. Also puzzled how they determined the last product viewed.
I was just impressed as to how close this interaction was to 'old-school real life' shopping, that is, look at a item and a customer service assistant approaches to offer help and close the sale (though can't remember the last time I experienced that level of service in a shop).

[burt]

Putting aside the "not logged in customer"...

I wonder if such a module would be good for logged in customers?
Maybe scheduled for an hour after they looked at a product?

Hi {{FNAME}}

Can we help? We noticed you've been on a little browsing spree! We just wanted to check if we can help in any way.

The last item you looked at was our lovely {{PRODUCT_NAME}}.

Please reply to this e-mail if you have any queries. Alternatively you can click the product link below to continue where you left off.

xyzshop.com/product_info.php?products_id={{PRODUCT_ID}}

[heatherbell]

I wonder if such a module would be good for logged in customers?
Maybe scheduled for an hour after they looked at a product?

Definitely

[burt]

I'm still keen on hearing more ideas for the Queued Emails.

If anyone has ideas, let me know and will see if it can be made a possibility. In the last week or so two new Scheduler modules have been made based on ideas from shopowners.

[heatherbell]

Not sure, maybe this already exists.
https://github.com/CE-PhoenixCart/Phoen ... ns.php#L18
As the core language file suggests: "Subscribe to updates"
Is there an e-mail that does just that, that is, notify customer if the product has been updated?
For example, the product is 'new/improved', it's the latest model or useful/important information has been added to description.
Can only guess this would be indicated by a change to the Product Description or Model/SKU/GTIN?
Though maybe I've conflated what might/could be 2 separate e-mails, Description Updated and Model/SKU/GTIN Updated.
Just a thought.

[heatherbell]

NB - previous post edited.

[burt]

Maybe have a tickbox on catalog > product edit says "send email to queue" so that shopowner could decide if they updated the product in a way that should place emails into the Queue...that tickbox would cover all bases (assuming the shopowner remembered to tick it!)..

If the description update was (eg) a simple spelling mistake correction: no tickbox > no emails
Whereas if it was some new description of some new feature or whatever: yes tickbox > emails

[heatherbell]

If the description update was (eg) a simple spelling mistake correction: no tickbox > no emails
Whereas if it was some new description of some new feature or whatever: yes tickbox > emails

Seems logical and Admin user friendly to me.