Email plus addressing / easier login for returning booking guests

[nine007]

Good day

We have increasingly found that when quests come back to the site some time later to make a new booking that they have forgotten their password when they are on the booking page, I know that on the booking page the quests email address are being check to see if their email exists on the site, and if it does they are advise to login or reset their password, and it is right here where they leave and don't make a booking, they are too lazy to do a password reset, and those who do the password reset comes back to the site just to find that they have to make the booking all over again.

I have seen that many other booking sites make use of email plus addressing to overcome this issue, this makes the booking process fast and easy with no interruptions, it will be great if we can do the same.

thank you

[ReneCB]

Yes, I can also confirm that we loose bookings because again booking customers are too lazy to go through the relatively painful password resetting process. I would be great to simplify this.

[jomres]

I'm open to ideas, folks.

[ReneCB]

nine007 - could you maybe change the title of this issue to make maybe more persons take part in this discussion? Maybe something with "easier login for again booking guests". I am not sure if others expect this (from my point of view important) discussion under the current title "Email plus addressing". Thank you in advance, René

[nine007]

I thought about this for a long time and was testing other booking sites and talked to some of their development teams, and they all came back that email plus / sub addressing is what they use, the whole idea is to bypass login or password request and make the booking procedure painless and quick, I also tested email plus addressing on google mail and am using it on a couple of sites for newsletter subscription, a while ago I came across this article on Joomla from JoomlaPolis that they are using it with success (note that I do not use community builder) https://magazine.joomla.org/issues/issue-dec-2012/item/983-trick-to-use-same-email-used-on-multiple-joomla-user-accounts

There might be other ways also, but this is my 2 cents.

thank you

[ReneCB]

Hi nine007,

I like the idea with "email plus / sub addressing". I just read about it in: https://en.wikipedia.org/wiki/Email_address#Subaddressing

I am not sure if this is sufficient to solve the "login problem" for all again booking guests. As it looks on (search for "subaddressing" on that page) https://en.wikipedia.org/wiki/Comparison_of_webmail_providers by far not all email providers support subaddressing.

For me it would be good / important that we could find a solution that would also work with email providers like

• t-online.de
• gmx.de / gmx.net as we have many customers from the German speaking markets, where these email providers are still popular (apart from gmail and outlook.com).

I think it is a good idea to use subaddressing for the users with email addresses that support it (the big players). But I think we also need an easier login solution for those again booking users without email addresses supporting subaddressing...

Any idea for this? What do you think, Vince?

[ReneCB]

This topic is very important and I think we need a solution soon. Yesterday I already had two customers (who had booked already with us before) on the phone again complaining that they cannot book again (at least they called - I do not know how many others just tried to book on a different site). The login process that is required for again booking guests is definitely too complicated and this is a big usability issue.

Also the required login process in order to leave a review leads to a relatively low review numbers. I think this topic also needs to be addressed.

Happy for every +1 for this!

[jomres]

Ok so sub-addressing is out due to it not being an "across the board" solution and anyway anybody who has problems logging in to a site because they don't use a password manager, sub-addressing is just going to be even more confusing.

Any other ideas?

[jomres]

Ok, here's a thought.

Whenever a guest makes a new booking and is registered in Joomla, they are automatically logged in.

Why not simply make the session lifetime last for a year or more?

https://www.interserver.net/tips/kb/change-session-lifetime-joomla/

Make the session lifetime 525960 this many minutes, does that help?

[nine007]

I did thought of lifetime session and I have implemented it, but if the person cleans his browsers cache the session disappear or if the person comes to the site from a new pc or his work pc is windows and the computer at his home is a mac then lifetime session has its limits.

[ReneCB]

Apart from what nine007 menioned the problem is also - as the lifetime sessions have not been set higher on my portal before - that this might help for the future but not for all again booking guests who booked before and where the ("old") session lifetime has expired. Would be good to have a solution that helps not losing them.

[ReneCB]

Also I cannot save a session livetime of more than 16383 minutes as it looks. As this is less than 2 weeks it won't help me as the booking frequency is not that high.

[jomres]

Ok, I think I have an idea on how to solve this problem.

First, let's clearly identify the issue.

Guests come back after X time, and they don't have their login details for the site. Currently, when they use an email address that is already registered in the system we ask them to login again. This, unfortunately is a barrier to making new bookings.

Q : Why can't we just automatically re-use their guest details in the booking form when they enter the previously registered email address?

A : Data exposure. Simply pulling their information from the database when they use a previously registered email address would expose their address details to anybody who knows that email address. Naturally this is unacceptable and we can't allow that to happen.

Proposed solution : In the booking form, instead of showing the entire guest details form inputs, I propose that we instead show just the email form input. When a guest enters their email address, the system checks like it currently does, that the email address already exists. If it does, then we'll internally populate the guest details of the booking but we will not expose that information in the form input fields. Instead we will not show the rest of the form fields, and in the confirmation page and after amending the booking we will just replace the outputted data with stars or similar.

During the booking creation phase the booking will still be associated with the existing guest's details, but at no point will that be shown and after the insertion the booking form's temp data will be wiped again.

Your thoughts, folks?

[Nikos-c]

Almost everyone uses Facebook. Why not use Facebook credentials to allow users to login. Or Twitter, Google etc. I think there are already plugins for that.

[jomres]

Indeed, but 1 not everybody uses facebook or twitter and 2 this is about helping the most technically illiterate among us (I'm not criticising, some of my nearest and dearest are functionally incapable of using the internet for anything beyond the simplest of things).

There's nothing stopping you guys from installing fb connection apps, but they're not the most complete solution.

[nine007]

I like Vince idea, I think it can work.

thank you

[Nikos-c]

You are right, but allowing login with social networks will minimize the problem and at the same time it can be used with the solution you are discussing here. And what you proposed I think it's the best it can be done to overcome this problem.

[jomres]

Jomres doesn't "disallow" social network logins, that's the purview of the site owner, not Jomres itself.

[ReneCB]

I like your idea, too, Vince.

BTW: I - on purpose - do not want to have a personal facebook login and I think I won't change my mind on that. Also I automatically use CCleaner (when the browser closes) and therefore are not continously logged in at the "the big" sites and let them collect and connect data. I think there will still be many people who also care about their data and therefore do not believe that the social network login is a solution.

[fabio-n]

Hi All

I think this is an important issue. I think the best approach is as Booking.com handles it.

There are 2 ways of making a booking:

1- if you are not logged in (in their loyalty program "Genius", optional), you can make a booking even if you are re-using the same email from a previous booking. When you finish the booking you get a password in the confirmation email to amend (only) that booking if needed. You can re-use the same email in a future booking, without any password, (just like Jomres behaves with an unknown email), and you will get a new random password in each new booking. You will not be able to see your booking history becasue your bookings are not linked together (even if they are using the same email, but each one has a different password). Each booking can have a different street address and phone number, and it will not update any previous info in any previous booking (all booking info is isolated/duplicated).

2- if you decided to join their loyalty program (to get discounts, etc), then you need to login first, and there in your account you will have your booking history, and you can book logged in, so you get loyalty points and it populates your info in the booking form, and you get discouts.

Some details:

• Even if you have a loyalty account, you can still book as in situation 1 if you don't remember password (you don't get the loyalty benefits and you have to fill in all the required data in the form, but at least you don't have to go thru a password recovery), and you get a new unique password for that booking only in the confirmation email.
• I guess this logic requires that "guests" making a reservation would not become automatically CMS users, and instead go to some [jomres_guests] table (where email duplication would be accepted, and each booking would generate a new row, and one column could link the guest data to a CMS user, in case the guest opted to have an account in the CMS and was logged when the reservation was made)
• In short: guest data should not be stored in CMS user table, but in a Jomres guests-table. Most guests don't want to have a login to our CMS or another password to remember...

Would love to get some feedback about this idea, and if upvoted, I hope it is not too complex to do implement.

Regards

[jomres]

The reason for having the guests registered is to allow you guys and girls to correlate guest details with real people. Because of GDPR you need to be able to be compliant when removing guest details when they request it. Property managers can ONLY remove guest details from the properties that they manage (by design) which means that the guest will need to contact each hotel that they booked at, all on the same site.

By enforcing a login, they can log in themselves and remove their own information if they wish and if they're qualified to do so (e.g. because they haven't got any outstanding bookings).

Without that, you are at risk of not removing all of their PII and being fined by the authorities as a result.

As for guests not wanting another login? It's about time they learned about password managers.