COWOA (for ZC v1.5.x)

lindasdd:

Ultimately I had to stop using OPC because 'guests have orders but no accounts' means my sales funnel becomes broken.

The most important part of my sales funnel is a discounted sample pack product. 99% of customers order it as their first item. The discount is a one time use code.

Under OPC, guest checkout doesn't get an account, so there is no way to offer them a one time use code. The solutions are either to not offer guests a code or to not limit the code to one time use. Both have downsides.

Next step in the funnel is a one time use lower tier free shipping discount code. One time use per customer. Again, not possible with OPC.

There are potentially all sorts of work arounds but they would most likely require customers to jump through hoops which will cut conversion rates off at the knees. So not worth it. Even a simple, "check your email for the code" is too much for the first checkout experience of a customer.
Linda,
Thanks for sharing these details!
If you could "wave a wand" and have it work "your way", what would the ideal flow look like with guest checkout?
You talked about wanting them to "have an account", but let's unpack that: do they actually need an account? or do you just want the store to recognize that "hey, you've shopped with this email address before" and "therefore we're offering you the following automatic discount"? (and maybe it would be based on "you've shopped X number of times using this email address"?) ... but would getting them to provide their email address be too much to ask? (It's less than asking them to login with both an email address and a password they've gotta look up in a Welcome email).
Again: how do you envision your funnel's "rules" would get triggered by the customer, assuming the browser doesn't yet know who they are when they first visit the site?
(one idea: would they get auto-logged-in or at least auto-coupon-applied if they click a link in a marketing re-engagement email?)
Again: what do you have in mind in the "perfect system"?

I'm thinking there might be some very simple adjustments that could accommodate it, but it's tough to figure those out without knowing your ideal flow.

What I want for a "perfect system" is too custom to my needs.

Whereas if you are asking for my opinion on an optimal default checkout flow template, it would be very similar to One Page Checkout.

It just needs to be able to handle coupon code usage restrictions

To your specific ideas / questions:

• do they actually need an account? - No. If the coupon restriction programming worked off email address rather than customer ID, an account wouldn't be needed. The down side to that is what happens when email addresses change. Alternatively, for my purposes, if the system offered a different code to each email address user it could work.

• do you just want the store to recognize that "hey, you've shopped with this email address before" - that would potentially be helpful. For example it might ask, "Looks like you have returned. Would you like to use your prior details?"

• and "therefore we're offering you the following automatic discount"? - This doesn't interest me, but probably other people it would. What might interest me is a non-visible "and therefore we are NOT offering you the following automatic discount".

• and maybe it would be based on "you've shopped X number of times using this email address"? - This doesn't interest me, but probably other people it would.

• but would getting them to provide their email address be too much to ask? - No this is not too much of an ask. It is already being asked.

• would they get auto-logged-in or at least auto-coupon-applied if they click a link in a marketing re-engagement email? - That would be awesome. But isn't a requirement.

All of the above though seems like a lot of jumping through hoops for something that is already working as long as guest accounts get an account (at least in the database) like in COWOA.

Your additional questions sort of veered off on a tangent about coupons. At the moment I utilize Mailbeez to generate customer specific coupons for different scenarios - abandoned cart, winback campaigns, rewards, etc.

lindasdd:

All of the above though seems like a lot of jumping through hoops for something that is already working as long as guest accounts get an account (at least in the database) like in COWOA.
It's that generic "account that is really a non-account" that I'm very much trying to avoid, as well as avoiding creating "accounts" for people who haven't actually asked for an account.

I wandered into coupon discussion because that was the driver behind the problem you were reporting.

That said I can see how tracking coupon redemptions to customer-email-address in the absence of knowing a customer_id would be beneficial. Will noodle on that.

One possible solution is that coupons are limited to only full accounts AND in order to do that, but not hurt checkout conversion rate too much, wait till the coupon code box to state 'It looks like you would like to use a coupon. Coupon codes are only available for customers with a customer profile. Check this box to make your already entered customer details a full customer profile.'

It is important that it is presented right at the point that the customer sees the benefit and that it is effortless (just check a box).

The only thing that leaves is setting a password. Either do that on the checkout_success page (similar to how OPC asks guests if they want to make it a full account), or don't do it. And just mention in the customer welcome email that they can always set a password using the password forgotten tool.

If someone created the above flow I would run it through my A/B testing to see the impact on conversion rates.

lindasdd:

One possible solution is that coupons are limited to only full accounts AND in order to do that, but not hurt checkout conversion rate too much, wait till the coupon code box to state 'It looks like you would like to use a coupon. Coupon codes are only available for customers with a customer profile. Check this box to make your already entered customer details a full customer profile.'

It is important that it is presented right at the point that the customer sees the benefit and that it is effortless (just check a box).

The only thing that leaves is setting a password. Either do that on the checkout_success page (similar to how OPC asks guests if they want to make it a full account), or don't do it. And just mention in the customer welcome email that they can always set a password using the password forgotten tool.

If someone created the above flow I would run it through my A/B testing to see the impact on conversion rates.
The highlighted bit above is already handled by OPC, you'd just define ot_coupon as an order total that doesn't apply to guest checkout. The messaging could be done via a messageStack output on OPC's data-gathering page that kicks in if the customer is in guest-checkout.

lat9:

The highlighted bit above is already handled by OPC,

Yes, which is awesome.

But without "Check this box to make your already entered customer details a full customer profile." it isn't solving my problem.

One solution might be to state at the login page "Guest Checkout customers can not use coupons." - except good luck doing that in a way that customers notice without it being overly intrusive. So either you have a login page that yells the info to everyone, or you have a guest customer who is now frustrated because they already put their info in, but now can't use a code.

lindasdd:

Yes, which is awesome.

But without "Check this box to make your already entered customer details a full customer profile." it isn't solving my problem.

One solution might be to state at the login page "Guest Checkout customers can not use coupons." - except good luck doing that in a way that customers notice without it being overly intrusive. So either you have a login page that yells the info to everyone, or you have a guest customer who is now frustrated because they already put their info in, but now can't use a code.
There's also a constant definition (present in /includes/languages/english/checkout_one.php):

    // -----
    // This constant defines the instructions you want displayed at the very top of the "checkout_one" page, before the form entry.
    //
    define ('TEXT_CHECKOUT_ONE_TOP_INSTRUCTIONS', '');  //-Displayed within a set of <p>...</p> tags if not empty.

If that language constant isn't an empty string (as distributed), then that information displays at the top of the checkout_one page's rendering. You could modify that to indicate the "guests can't use coupons" text.

Yes, but again, not an ideal solution from a user experience and conversion rate perspective.

I have found a problem with the version of COWOA that I use with my clients (as I upgrade, it gets deleted). In the meantime, I believe the version I'm using has an issue with discount coupons and sales tax. I have checked everything I can think of but if one uses a discount coupon to check out, it does not add sales tax. I checked to make sure that the order total order had discount coupon before sales tax and there's nothing else there except shipping. But if I check out without a coupon, it charges sales tax. The question becomes what version of COWOA and where did I get it from last? I think it was the last posted on github but I don't have a clue which one - I just see I downloaded 2016 - at some point I may have done some upgrading of it for 1.5.5. I've advised my client that removal is the best way to go forward.

I do like the way this one works by the way as opposed to any of the others I've tried. The only thing I didn't like was the confusion created by customers who don't realize they used it before and get frustrated when they can't log in on their next visit. And then converting a site back to normal means a discussion with the site owner to see if they want to change all accounts to non guest, possibly setting up a problem with duplicate accounts.

delia:

I do like the way this one works by the way as opposed to any of the others I've tried.
... in what regard?

simple in reality - blends well in checkout - I'm not a fan of the one page checkout solutions I've seen and worked with in the past. (haven't looked at the present options in a long time) What was never simple is the coding of course. Definitely would prefer the ability to make customers into full accounts in admin and some sort of fix for the duplicate email addresses - that was a good idea at the time but definitely doesn't work well at this point. But I would kept with it if someone had continued to support it.

So, yes, thanks for soliciting feedback on this topic - there's got to be a good solution possible!

I did rewrite bits of the pages - simply changing some default zen cart text with zen to make it more logical and I kept that progress bar - feel like that visual is most important. All of the steps have to be there, coding wise and process wise so why not make it more obvious? I packaged it up as a mod at one point - screenshots here: https://www.zencartdelia.com/zen-cart-store/index.php?main_page=product_info&cPath=3&products_id=23 (please folks, dont' criticize that site - it's out of date and I'm in the process and deciding where to put it since I now operate under the wiztech name.

So, yes, thanks for soliciting feedback on this topic - there's got to be a good solution possible!

delia:

The only thing I didn't like was the confusion created by customers who don't realize they used it before and get frustrated when they can't log in on their next visit.

I haven't done so yet, but I have considered playing with the password forgotten tool so that if a COWOA account puts through a password forgotten request the email they receive states, "Your last checkout only created an order, not an account with a password. To place a new order, either use one of the New Customer paths or click here to turn your prior order details into a customer account."

That's great solution to that problem!

... or click here to turn your prior order details into a customer account.

Would this action simply set COWOA_account to 0 (in addition to resetting the password)?
I was thinking about ways to make COWOA accounts into regular accounts if the customer wished and wondering if this was all that was needed.