We’ve just started using Salto and the Mews Salto Integration and it works fine so far but there are two big questions for us:When the keys are programmed, the authorization automatically expires based on the departure time. Is there a way to adjust this? If we adjust the departure time in the service options, this time is automatically displayed, for example, in the guest portal. However, we want the time to be communicated, for example, departure at 7:00 p.m., but the keys are valid for a little longer, until 7:15 p.m. Same for earlier. Currently, if you program a key for a room, it deactivates all the others. For example, a guest arrives and you program two keys. Later, they come back and want another one (e.g., for a child, or someone else coming into the room a day later). If I then program an additional key, all the others become invalid. That makes sense in principle, but it would be useful to be able to choose whether to program additional keys or replace the old ones. Is that possible?I am not 100% sure but probably @james.taylor know something about that?

RFID Integration Salto

We’ve just started using Salto and the Mews Salto Integration and it works fine so far but there are two big questions for us:

When the keys are programmed, the authorization automatically expires based on the departure time. Is there a way to adjust this? If we adjust the departure time in the service options, this time is automatically displayed, for example, in the guest portal. However, we want the time to be communicated, for example, departure at 7:00 p.m., but the keys are valid for a little longer, until 7:15 p.m. Same for earlier.
Currently, if you program a key for a room, it deactivates all the others. For example, a guest arrives and you program two keys. Later, they come back and want another one (e.g., for a child, or someone else coming into the room a day later). If I then program an additional key, all the others become invalid. That makes sense in principle, but it would be useful to be able to choose whether to program additional keys or replace the old ones. Is that possible?

I am not 100% sure but probably @james.taylor know something about that?

Page 1 / 1

Hi @jones.eth

- As far as I am aware, there is no solution for the expiry time, and Mews will send the end time of the reservation as expiry time without a possibility to intervene.

- For duplicate keys, there is an option in other Mews key interfaces to configure two encoders in Mews, one which creates new keys and one which creates duplicate keys. This is controlled over the JSON entry in the encoder configuration in Mews:
For Duplicate: { "Type": "IndustryStandardProtocol", "DuplicateKeyAllowed": "True"}
For New: { "Type": "IndustryStandardProtocol", "DuplicateKeyAllowed": "False"}
see here for more details: https://help.mews.com/s/article/salto-for-mews-pms?language=en_US

But again, this is not documented for Salto (but for Assa f.e.), so it would need to be tested if it works.

Best, Marc

@marc agilotel thanks for the feedback. The solution with the additional encoder is a clever workaround but better seems to me if there is a option in the key creation dialog to set duplicate to true … @james.taylor any chance thats gets added like that?

The arrival and departure times are visible in the portal and the e-mails … is there something planned in the integration to set some buffer times @james.taylor ?

Hi @jones.eth! Thank you for your queries, My name is Dani from the Support Team and I wanted to jump in briefly while @james.taylor is out of office .

I believe it is not possible with the current functionalities to choose on the same encoder whether to create new keys or duplicate. The workaround provided with the two encoders is the solution at this time, but James can confirm whether there are plans to update this in the future.

As for the timeframe validity of the keys, the timeframe that is communicated via Salto Key cutter is based on the default service reception arrival and departure times configured in your Service Settings, not the ones from the reservation themselves. Making keys for outside of these times to service exemptions would need to be made through the Salto key cutter itself, rather than Mews.

For both of the above answers, James will be able to confirm the information once he is back :)

@dani.molina thanks for your feedback. A confirmation if the solution that @marc agilotel suggested would be great.

I'm pretty sure it's currently not possible to control whether a copy is created or the old keys are replaced in the key creation dialog. I also don't think adjusting the buffer times is possible.

I would suggest setting the buffer in the JSON flags and creating a checkbox in the key creation dialog to control the DuplicateKeyAllowed flag individually. Depending on what's set in the JSON flags, the checkbox can be selected or not, which would make it fully compatible.

Hi @jones.eth, thank you for raising this question and for your patience for me to reply.

The above responses are correct that it is currently not possible from Mews to choose if a keycard is a duplicate or new. We also don’t have a way to add a buffer for the times.

For the key creation, the cautionary approach was taken to always replace the key instead of always create joiner keys. I believe you can still create a joiner key directly from Salto, but we would of course like to make this possible directly from Mews.

There are no specific plans right now to work on this, but I’ve captured this feedback as we do want to improve the key experience in future.

Hey @james.taylor thanks for the feedback.

As already mentioned, it would probably be useful to adjust the key expiration times in some way. Aligning them with the reservation times, as is currently the case, makes sense, so I think an offset in minutes, positive or negative, would be a sensible approach.

I'm aware that we can copy cards in Salto itself. The advantage of your integration is that the staff at our reception don't have to learn an additional tool. We already have quite a few different services, and I try to keep it as clear as possible for them. Especially when a new employee is being trained, it's not good if there are 12 different services they have to learn, for example: emails, keys, hotel program, checkout, newsletters, offers, bookings ... it quickly becomes quite a lot, so I would only move the keys in this team with Mews.

I think there's a lot of movement in this component at the moment, and as soon as new services are integrated, these features could be integrated. Possibly first as flags and later possibly as a proper UI in the integration. I look forward to any improvements in this area.

Thank you @jones.eth and I completely agree with your insight about staff overload with different systems and tools to jump between. We want to reduce the need to go to another system as much as possible and keep everything clean and simple for you teams in a single interface.

@james.taylor here's a little more information regarding the validity of keys.

Currently, keys are valid for the time of the reservation. Now it often happens that guests arrive because they were late for departure and can no longer access their rooms (we've already discussed buffer times for this).

Our idea was to postpone the departure time of the reservation (Reservation -> Properties -> Departure) and recode the keys so that guests have a little more time...

However, it seems that the valid times are not based on the reservation times (e.g., adjusted times with delayed departure) but only on the standard service settings. This, and of course the lack of an option to set buffer times, is really inconvenient for us.

I may be wrong but it doesn't seem to be logical to handle it this way.

Reply

Join the Mews Community!

Login to the community

Scanning file for viruses.

This file cannot be downloaded