Hello!

Great to hear there is some progress on that topic!

Primarily, we would like to remove as much hurdles as possible from OCI as possible.

So a Setup at bookable service level would be great. (disabling/enabling it by default)

But also let’s look at it from the other way round - when do your really like to ask for a validated credit card? So disabled by default at service level, but required in those cases:

• when there is no card associated with the reservation at all AND a setting at the rate / rate group levels requires it (so some company or group travel rates / rate groups are exempted)
• when a due payment with a card on file failed previously (happens with guest credit cards received from OTAs when the MoTo transaction for prepaid reservations fails, or the card was stolen)
• can anyone think of other possible must have cases ?

By the way, the same applies to kiosk check-ins, also for staff mode kiosk for electronic check in at the front desk. Currently, there is no credit card requirement at all as far as I know … it should be possible to at least remind staff during the check-in process that a credit card is required (as for the above mentioned cases) - but allow to skip it (if the guest has no card, pays cash, whatever ...).

Basically, during OCI be as relaxed as possible regarding credit cards, only ask for it in really important cases where it would lead to more time lost at check in. During on-site Check-In it could be a little more strict, asking for credit card details (for example to be logged into mews via mews terminal) for a broader range of cases (like for when only VCCs are available), or for all reservations without validated cards, depending on individual hotel policy.

Kind regards,

JP.

@Olivia.Dingreville thats awesome. This is gonna remove so much frustration for us and our guests because a lot of system specific problems we have are revolving around credit cards. The possibility to take payment cards completely out of our system until the actual payment is gonna be a huge improvement.

A setting of mandatory, optional or hidden would be neat i think. Granularity wise i don’t have a strong opinion but on service and even rate-level seems to cover many cases.

One problem with the current system we see constantly is that guests not really understand that it is optional to enter a credit card. It would be great if the ui of the new system transported the payment options more clearly.

Another problem i see getting worse with those changes is that it is not possible to view these guests areas … i mean as the guests sees it. I know we can create a reservation and then view the guest portal and online-checkin, but thats just for that reservation. With additional rulesets that change what is shown, there are so much more scenarios were the guests view is different from what our booking looks like.

Just yesterday the support closed a ticket with our online-checkout not working correctly because they cannot comprehend that and requesting further information. Problem is: we can’t give that … because we cannot view the online-checkout of the guest and therefore cannot send any examples or even have a look at that problem.

I can second that! We have no idea if the online check in rate is low because guests are lazy and don’t read our messages, it doesn’t work for them, they stop at credit card request, or whatever .. same for online check out. For Admin level users it would be great to have at least some analytics access - at what step did the process stop, did they even start it ? - although, I guess MEWS does have the analytics! So I hope you guys at MEWS use that insight to assess where there could be some improvements and make us all happy

hi @Olivia.Dingreville, at a rate level yes!

we are still facing a lot of remarks (and drop off in the OCI process) at the step of the payment card, simply because in (some) of my properties the majority of reservations is fully pre-paid using IDEAL, since these guests don’t have a credit card.. hence skipping this step is very benifical for them.

If you seriously consider to set it up at bookable service level, you are asking hotels to completely rethink their operations, as it would change everything we do; we also see guests changing rate plan after a reservation was made (from flex to non-ref), and with such a setup we would be screwing up our entire stats. 

On rate group level could work, but that is - in our organization - how we organize the cancellation policies. That is why we group specific rates at this moment. 

@Kayleigh @dvdb @jeroenmaaneman 

This is a great development, especially when it come to group rates and companies who have already paid the full amount up front etc.!

• Set-it up at the Rate Group level, with an option to request or skip card details as part on OCI. Payment policies are also defined at that level so that seems quite logical.
• Set-it up at the Rate level. This feels like it may be too granular given the number of rates in use? It would take more time to set-up and also be more cumbersome to maintain. 

@Ivo 

Hi Olivia,

What a great feature idea.

We have been struggling with this for a while as a dedicated corporate business. In many situations corporate clients with big portfolios feel reluctant to allow their guests access to our native comms and portals.

This is due to brand retention form their end btu also the Credit/Debit card request which could put a corporate traveller with all expenses paid on the fence of positive review.

I’d opt in for the:

• Rate Group
• and Rate Plan (optional)

The reason for this is that it will bring more cohesive PMS management and configuration. There are quite a lot of settings that are scattered around to serve a common area of control.

Placing charging on OLCI should be linked to Payment/Automatic Settlement logic and these are positioned on a Rate Group level. This is where you have your settings and controls for your Corporate, OTA and leisure guests. 

Locating this control at the R Groups will also serve better than the Service level controls - the later are too broad and provide no further flexibility or diversity.

Looking forward to this development!

Igor

In such scenarios i think the best approach is to create a cascading system just like CSS for formatting websites is. So you have the option to place a “payment” rule at certain levels like: global, property, service, rate group, rate and maybe something even more granular. Each step from top to bottom inherits the rule from above except a rule is placed on that level … then it overwrites to above one.

So if you don’t need complex rules you just define one on the global level. But if there is a certain rate for example that needs a different rule you can overwrite the global rule on this level.

So you have all the granularity you need but i you don’t want that you don’t have really that much complexity. This may seem weird at first glance but once you understand this logic its really intuitive.

This approach would also be useful in other cases settings wise.

Like that very much @jones.eth !

Hi @Olivia.Dingreville ,

thats really a great feature we would also use in some cases,

• Prepaid Rates
• Reservations / Corporate Rates where we sent an invoice
• Blocks where guests doesnt have t pay by themselves
• Bookings with VCCS
• We use Mews Kiosk in every property and are very happy to get more OCI

Different Topic but:

Regarding VCCS we have the issue that we need to manually charge them at the day of arrival. Mews cannot distinguish between booking with VCC and guest credit card. 

@Daniel.Schleser 

Happy to hear more of it when you have a beta ready

Best

Linus 

Hi @Olivia.Dingreville,

This sounds exciting! We have been struggling with online check in from day 1. I can think of many, many examples that should be excluded from adding creditcard details to complete an online check in. It would be of great help if hotels can decide on their own whom en when to ask for creditcard details. 

I agree with @jones.eth, a cascading structure would be really usefull and easy to use as a hotel. This way, you can include all exceptions and make it fit perfectly to your specific property. You might even think of setting it per market segment as an addition.  

We would definitely benefit of this new feature, looking forward to news on this topic 

Regards, Sanne 

FYI @Jasmin H.

My property’s preference is to offer the option at either the bookable service level or the rate group level, ideally at the bookable service level. We do require a card to be on file, even when booked through an OTA.

Happy to hear more of it when you have a beta ready

Very happy to see this is being worked on!

In my opinion, the following set-up would give the most flexibility, without causing too much extra work:

Rate group level:
This makes the most sense, as it is also where you set up payment and cancellation policies.

Rate group should have these settings:
Credit card during online check-in is: Mandatory/Optional/Hidden
Credit card during kiosk check-in is: Mandatory/Optional/Hidden

Credit card excemptions:
[ ] Pre-paid on OTA *
[ ] Reservation is fully paid *
[ ] When the following travel agencies or companies are attached: [multi-select dropdown] *

* if the credit card is mandatory, checking this box will make it optional. If the credit card is optional, checking this box will make it hidden.

Implementation:
Have a standard setting of Credit card = mandatory, and none of the skip settings ticked. Then nothing changes when you implement it. And then hotels can start making exceptions manually, for the rate groups that require it, if they want.

Note:
Making the credit card optional, gives the guest a clear “skip this step” button in the check-in flow.

Side-note, guest details:
More granular options for guest data collection would also be great!
For example: 

• Car licence plates
• Different settings for owner or companions

Another side-note, optional bookings:
When the guest confirms an optional booking in the guest portal, they should only be able to do so by providing a payment method.
This is now a sort-of backdoor route for a guest to make a booking without giving us any guarantees, and is messing up many hotel’s workflows, or at least ours .
If you start work on payment settings in the guest portal, you might want to include this. 

Team Rate Group level here! An additional option to skip the cc request when the stay is fully payed already (Ideal for example). 

I'm not a fan of per rate settings, it makes it very hard to manage in the long run. And the Rate Group settings already contain payment settings, makes it the most logical place to set this up.

Also some usage insights would be very usefull as mentioned above.

The solution from @jones.eth sounds very nice. It makes sense.

Basically, we ask for guests' credit card details when we really need them during the booking process.

However, as long as we can't query all the data we need from the OCI, it's useless. 
I still don't know how the rest of you implement this when families with children come. How do you do an OCI? I don't get all the relevant data from the guest in the current enquiry.

Best regards

Leif

Another idea that would be interesting for this and other areas (like product rules, cancellation policies or rate restrictions) would be an rule editor for these situations. I think of something like an “condition builder” where you can add some if/else/and/elseif logic that receives an data object (for example and reservation or an companion) where you can build a condition to define if the rule applies. Then you give an priority if you have multiple rules.

For example you can do a general payment card rule without any conditions and priority 1. And then for example one that has a condition like “if reservation.duration > 5” or “if reservation.total_cost > XY” or “reservation.rate is XY” with an higher priority to replace that if the rule/s match. Of course with an nice UI.

That may be a bit more technical and probably not that transparent compared to the cascading idea but pretty mighty in comparison. We have a newsletter tool with a filter builder that comes pretty close to what i mean:

The current mandatory credit card screen makes the OCI very restrictive, thanks for hear the feedbacks and hope you can prepare a mix of previous suggestions, including the option to completely disable OCI credit card collection and have granularity to adjust when needed or required.

A configuration screen for the OCI would be very helpful, marking the check boxes or selecting tags with desired options, texts, fields, etc 

Best Regards

Elter, I fully support making OCI its own configuration screen for all the reasons you mentioned. Asking for an ETA from Guests seems like an obvious miss since a lot of properties have minimal Staff and it’s difficult to know how long someone could be working without having to use another service for communicating with Guests. Not knowing what time Guests are arriving is like operating in the dark.  And with Hurricane Helene on Thursday and Friday last week, operating in the dark was not fun at all. 

This is a most welcome feature!

For us, we would additionally like to be able to remove the online checkin altogether in the guest portal (thus automatically checking people in), as it is very irrelevant to how we run our humble nature resort.

Here, people are able to open their cabins using Zapier automation as soon as they’ve paid, and since the resort is an unmanned collection of cabins in the forest, online checkin does not really add anything (it actually would just confuse people more than be helpful).

So, to be able to 1) get rid of the mandatory payment card during checkin (since they’ve already paid the full amount upon booking) and 2) avoid the entire check-in in the guest portal would be strongly appreciated, as this functionality is obsolete in our customer journey.